phc-discussions - Re: [PHC] Lyra2 initial review

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 17 Apr 2014 14:40:15 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Lyra2 initial review

On Thu, Apr 17, 2014 at 12:39 PM, Solar Designer <solar@...nwall.com> wrote:

> Bill,
>
> How did you convert the "time" output to peak GiB/s?  I tried
> double-checking your results, and I am getting different numbers.
>
> Did you include the memory allocation overhead time or not?  I guess you
> did, which is a reason why faster schemes (those filling 2 GiB sooner)
> would appear to use less bandwidth (they'd spend _relatively_ more time
> on memory allocation overhead).  Anyhow, I failed to confirm your
> results, whether with this assumption or not.


In theory I meant to simply divide the memory (2GiB) by the total runtime
(including memory allocation).  D'oh!  Somehow I'm unable to use a
calculator properly...  your numbers below are correct, though on my
development machine, I do not trust the split between users and sys time.
 I see it vary randomly all over the place, while the total runtime remains
fairly constant.  That's why I don't try to factor out the memory
allocation overhead.


> On Thu, Apr 17, 2014 at 11:08:25AM -0400, Bill Cox wrote:
> > *********** Lyra2 - no modifications, hashing 2GiB of memory
> [...]
> > real    0m1.320s
> > user    0m1.200s
> > sys     0m0.110s
>
> 2/1.320 = 1.52 GiB/s
> 2/1.200 = 1.67 GiB/s
>
> > *********** Yescript - 5 of 6 calls to PWXFORM_ROUND commented out, and 3
> > of 4 calls to SALSA20_2ROUNDS
> [...]
> > real    0m0.709s
> > user    0m0.560s
> > sys     0m0.140s
>
> 2/0.709 = 2.82 GiB/s
> 2/0.560 = 3.57 GiB/s
>
> > *********** TwoCats - multiples was set to 1, and #threads set to 1
> [...]
> > real    0m0.431s
> > user    0m0.330s
> > sys     0m0.080s
>
> 2/0.431 = 4.64 GiB/s
> 2/0.330 = 6.06 GiB/s
> These don't match any of the above, as you can see.  Oh, I think I
> figured it out: you meant GB/s, but mistyped GiB/s.  Right?  e.g.:
>
> 2/0.431*2^30/10^9 = 4.98 GB/s
>

Guilty as charged.


> And the memory allocation overhead is a reason why Lyra2, with its
> higher number of r/w per location, appears faster in terms of memory
> bandwidth usage.  (Not necessarily the only reason.)
>
> Alexander
>

Yes.  Since Lyra2 does more accesses, the allocation overhead is a smaller
percentage of the total runtime.

Bill

Content of type "text/html" skipped