[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+EaD-bUN8OQKp2juDbg2e8xNs7D-ByNR59k-BAwnXH3qZmXcA@mail.gmail.com>
Date: Wed, 17 Jul 2013 19:17:37 +0200
From: Katja Malvoni <kmalvoni@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt
On Wed, Jul 17, 2013 at 6:27 PM, Solar Designer <solar@...nwall.com> wrote:
> Hi Katja,
>
> On Wed, Jul 17, 2013 at 06:14:51PM +0200, Katja Malvoni wrote:
> > I did some execution time measuring and BF_crypt() call takes between
> 19.41
> > and 19.43 ms (19.419 in average). Whole crypt_all call takes from 19.445
> ms
> > to 19.557 ms (19.457 in average). Most costly loop takes 16.74 ms.
> > BF_crypt() code before most costly loop takes between 2.56 ms and 2.58 ms
> > (average 2.572 ms) and code after the loop around 0.1 ms. Numbers are
> taken
> > from one execution of self test and measured on my code without applying
> > your patches. In part of BF_crypt() which has execution time of 2.5 ms
> salt
> > and key are set. I moved this computation to host and I get 827 c/s
> without
> > applying your patch (this code is in my GitHub repo). After that, I
> > modified code I got after applying your patch. In that case speed is 830
> > c/s.
>
> This is good news, but I suspect there was some error in your
> measurements, or if no error then we don't know why the computation
> prior to the main loop is taking 2.5 ms. This 2.5 ms is excessive
> (should be several times less than that). I suspect that you measured
> communication time as part of it, or maybe it's so slow because it
> involves reads from off-chip memory?
>
I was surprised by that as well, I measured it again, 2.5 ms. I'm measuring
clock ticks with Epiphany timers (assuming 600 MHz), I start timer after
declarations in BF_crypt and I stop it before entering do{ ...
}while(--count);
I was passing pointers to shared buffer when calling BF_crypt(), I tried
copying data from shared buffer into local variables, it's even slower -
809 c/s
> Can you try reducing the amount of data transferred to Epiphany each
> time - e.g., temporarily (as a test) limit password length to e.g. 20
> (instead of bcrypt's hard maximum of 72)? Does this speed things up
> much? If so, you could look into optimizing these data transfers (make
> them variable size? make them faster by other means? make them async?
> implement several/all of these optimizations at once?)
I changed PLAINTEXT_LENGTH to 20 instead of 72 and until it fails on self
test, execution time of crypt_all() is 19.54 ms (measured from after
variable declarations to before return).
> > I left typedef BF_word BF_binary[6] on Epiphany side. if I change it
> > to typedef BF_word BF_binary[2] than output buffer doesn't look the same
> on
> > host and Epiphany side (this code is in
> > ~kmalvoni/integration/JohnTheRipper/).
>
> In the patches I posted, I made the BF_binary size change on both host
> and Epiphany side, and everything worked fine. Why don't you do that?
>
Sorry, I have no idea how I managed to see 2 on one side, 6 on the other.
>
> > I also ported BF_fmt implementation to Epiphany, it's much slower, 732
> c/s
> > (in ~kmalvoni/JohnTheRipper/).
>
> I'm sure the answer is in your code, but can you please describe what
> you did in plain English in more detail?
>
Not much, I moved BF_std_crypt(), BF_body() and BF_std_crypt_exact() (if
I'm not mistaken this one should be on host side, not on Epiphany) to
Epiphany side and added host Epiphany communication in crypt_all(). I
transfer BF_init_key, BF_exp_key and saved_salt (+ start signal) to
Epiphany and call BF_std_crypt() from Epiphany. Host waits for result. In
this case crypt_all() call takes around 21.7 ms. I don't use BF_exp_key and
BF_init_key from shared buffer, I copy them to local variable first.
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.
