Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130717162734.GA21211@openwall.com>
Date: Wed, 17 Jul 2013 20:27:34 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Parallella: bcrypt

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?

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 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?

> 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?

Thanks,

Alexander

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.