Date: Thu, 1 Aug 2013 00:33:18 +0200 From: Katja Malvoni <kmalvoni@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Parallella: bcrypt On Thu, Aug 1, 2013 at 12:22 AM, Solar Designer <solar@...nwall.com> wrote: > > I'm using two > > structs but both are still in the same struct called shared_buffer. And I > > have an interesting situation - I have a code which isn't reliable > > (sometimes fails self test), but when it works I get very weird speed: > > 497619 c/s (it's not constant but it's 49xxxx, both real and virtual). I > am > > testing bcrypt-parallella format, I only changed how data is transferred > > and how result is read (separated structs for input and output, I still > > haven't implemented savings when salt or keys aren't changed). I don't > > understand this speed. If I measure time with transfers it's around 0.05 > > ms. But with unoptimized bcrypt, speed of computing the hash without > > transfers was around 16.5 ms. If I read whole outputs struct and than use > > memcpy to have result in parallella_BF_out speed is 1204 c/s. Code which > > gives this very high speed is committed. > > I guess this line: > > buff.out.core_done[corenum] = 0; > > is not executing or does not take effect (as far as the host is aware) > soon enough. You appear to have a race condition here, and it appears > to be triggered 100% of the time now. I guess you need to be resetting > core_done[corenum] to 0 from the host, not from Epiphany. > Actually, that line works, that's why if I do second read after while loop code works. But I made a stupid mistake - when changing how data is transferred I changed variable used as condition in polling while loop and I wasn't resetting it to zero. And it was passing self test because old data remained in shared dram. Speed is 1204 c/s. Katja Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.