Date: Mon, 7 Dec 2015 15:54:49 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: scrypt regression (was Re: hashcat CPU vs. JtR) On Mon, Dec 07, 2015 at 12:58:32AM +0100, magnum wrote: > On 2015-12-06 15:53, Solar Designer wrote: > >>[solar@...er src]$ GOMP_CPU_AFFINITY=0-31 ../run/john -test -form=scrypt > >>Will run 32 OpenMP threads > >>Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 128/128 AVX]... (32xOMP) > >>DONE > >>Speed for cost 1 (N) of 16384, cost 2 (r) of 8, cost 3 (p) of 1 > >>Raw: 878 c/s real, 27.6 c/s virtual > >> > >>(BTW, I think this used to be ~960 c/s. Looks like we got a performance > >>regression we need to look into, or just get the latest yescrypt code in > >>first and then see.) > > When was that? I see no regression comparing to Jumbo-1. I probably recall incorrectly. I guess we never integrated the faster code into jumbo - it still uses pretty ancient escrypt-lite. We should update to latest yescrypt code (although I have yet to finalize the string encoding for yescrypt native hashes). I've just tested yescrypt-0.7.1 and yescrypt-0.8.1 by editing their userom.c to use "#define YESCRYPT_FLAGS 0" (requests classic scrypt) and running "GOMP_CPU_AFFINITY=0-31 ./userom 0 16". Both reported 926 c/s with gcc 4.9.1. Going back to RHEL6's default gcc 4.4.7 gives 945 c/s. Availability of huge pages may also make a difference (yescrypt-platform.c currently has HUGEPAGE_THRESHOLD at 12 MiB), but I've just tried allocating them with sysctl and it didn't change the numbers above on this machine. I think I saw 960 c/s for some other revision, but I can't find it now. 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.