[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 22 Jul 2015 17:01:42 +0200
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: my yescrypt and lyra2 benchmarks
Hi Agnieszka,
On Wed, Jul 22, 2015 at 03:49:14AM +0200, Agnieszka Bielec wrote:
> hi, http://www.openwall.com/lists/john-dev/2015/07/05/9
>
> I couldn't set pomelo to ~4330 c/s on well: I was getting 1932 for
> m_cost=8 and 8364 for m_cost=7 so I postponed
>
> Parallel doesn't support costs like t_cost and m_cost
Please don't spend any more time on Parallel, POMELO, Pufferfish.
(I guess you tried tuning POMELO like this before the PHC announcement.)
> I did benchmarks only for lyra2 and yescrypt for my implementations
That's right.
> (but maybe it's possible yescrypt make faster)
You'll need to try.
> Lyra2
>
> well - 4264
> GeForce GTX 960M - 522
> AMD Radeon HD 7900 Series - 3385
> GeForce GTX TITAN - 1735
>
> yescrypt
>
> well - 4688
> GeForce GTX 960M - 206
> AMD Radeon HD 7900 Series - 319
> GeForce GTX TITAN - 326
OK. These are using the same memory (de)allocation approach, out of the
loop, correct? I mean on CPU.
> I was testing using my modified file bench.c and added option
> --skip-self-test in lyra2 because I modified by hand only costs in
> generated previously hash for another costs, was testing various LWS
> for AMD Radeon HD 7900 Series and GeForce GTX TITAN and only one
> LWS=64 for GeForce GTX 960M, but I set my get_default_workgroup() to
> return 64 and was setting LWS manually
When we finalize the settings to use for these cross-benchmarks, you'll
need to generate proper test vectors for them (using reference
implementations), so that you won't need to skip self tests.
> output (not everything):
>
> lyra2
>
> a@...l:~/m/run$ ./john --test --format=lyra2 --skip-self-test
> Will run 8 OpenMP threads
> Benchmarking: Lyra2 [Blake2 AVX2]... (8xOMP) DONE
> Speed for cost 1 (t) of 1, cost 2 (m) of 62, cost 3 (c) of 256, cost 4 (p) of 1
> Raw: 4264 c/s real, 534 c/s virtual
I think m=62 is too much fine-tuning. I suggest that you use 64 here.
It will also bring Lyra2 to almost the same memory usage per hash as you
have for yescrypt at r=6. So we'd have both at ~1.5 MB.
As a separate set of benchmarks, please also configure both for ~2 MB.
Please use m=80 for Lyra2 (giving 1920 KiB?) and r=8 for yescrypt
(giving a little over 2 MiB).
> memory per hash : 1.45 MB
Please add this kind of reporting to your CPU formats as well (for
Lyra2, yescrypt, and future ones).
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.
