Date: Tue, 30 Jul 2013 22:39:14 +0200 From: Katja Malvoni <kmalvoni@...il.com> To: john-dev@...ts.openwall.com Subject: Re: Parallella: bcrypt Hi Alexander, On Tue, Jul 30, 2013 at 4:19 PM, Solar Designer <solar@...nwall.com> wrote: > On Thu, Jul 25, 2013 at 08:06:48AM +0400, Solar Designer wrote: > > Maybe you'll come up with another clever/crazy idea on how to do right > > shifts with Epiphany's FPU instructions (like I mentioned, replacing one > > right shift with multiple FPU instructions is OK). > > Here's another idea: replace the AND, not the right shift. You can > replace one AND with two IMULs - e.g., to extract the byte at bit offset > 16, you can IMUL by 0x100, then right shift by 24, then IMUL by 4 (to > get the 8 data bits into bit offsets 2 to 9 as we need for a load). Can > you have both IMULs for free with 2x interleave, or would you have to go > for 3x? In the latter case, you wouldn't be able to preload one of > three P arrays, which would defeat the purpose of this new trick for one > of two byte extracts - but we'd nevertheless potentially save a cycle on > the other byte extract. > At first look, I think I can't have both for free. Mostly because result is used with other FPU instructions so gaps become too big. In case of 3x interleave I will be able to fully preload only one P array. I'll need more tmp registers (in worst case 4), 2 registers for L2 and R2, pointer to ctx3, 5 pointers to P and S arrays and one ptr for 3rd instance. On Tue, Jul 30, 2013 at 4:33 PM, Solar Designer <solar@...nwall.com> wrote: > On Tue, Jul 30, 2013 at 02:18:04PM +0200, Katja Malvoni wrote: > > On Tue, Jul 30, 2013 at 2:47 AM, Solar Designer <solar@...nwall.com> > wrote: > > > > > Perhaps you should change your code to transferring just one struct? > > > I wouldn't be surprised if this gives us a few c/s extra. > > > > Done. > > Any change in c/s rate? > Not really, it's still either 1175 or 1177 c/s. So it may be more optimal to have exactly two structs: one for the salt > and one for the candidate passwords - and transfer only those of them > that have changed since the previous transfer. You set the > keys_changed flag in set_key() and the salt_changed flag in set_salt(), > and you reset both in crypt_all(). > I have one question - when transferring only one struct, I'm not relying on order in which e_write() calls are executed (I'm assuming that data is written to SDRAM sequentially and since my code doesn't work if start array is not last variable in sturct, I believe my assumption is correct). I still haven't tested it enough times to conclude that occasional stall doesn't happen but so far I haven't seen it. With two structs I'd rely on order or I'd have to check that data is transferred before transferring start. I think that making sure data is transferred is less costly than unnecessary transfers, but I'd like your opinion on this before I start (normally I'd just start and see what happens but my first approach was to use struct with keys and salt inside the "data" struct but it didn't worked and I need to debug it (I checked offsets, equal on both sides) and I want to be sure I won't waste time). > When I do test with BF_tst.in speed is 727 c/s. It seems that interleaving > > is not used (but even without interleaving it shouldn't be this slow). > > Your code can't magically turn into a non-interleaved version. Rather, > when there are too few inputs to fully use the 32 "slots", fewer of the > slots will be made effective use of (and counted for c/s), so a speed > worse than you had without interleaving is to be expected for the last > set of candidate passwords to be tested (as long as the number of > candidate passwords is not a multiple of 32). This does mean that > increasing interleaving hurts performance for very short runs of the > program, while improving performance for long runs. > > How many candidate passwords are you testing? > I'm testing 20, that explains it, I used same test as for version without interleaving. 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.