[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-ajc39Qi+YdqDO4-hgHpgKAPVBZgri-EE5W2+e=Cgrbvw@mail.gmail.com>
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.
