Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ