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  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: Wed, 1 Apr 2015 12:40:15 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] OMG we have benchmarks

On Wed, Apr 01, 2015 at 11:01:36AM +0200, Milan Broz wrote:
> Graph for t_min is here (but is somehow strange)
> https://raw.githubusercontent.com/mbroz/PHCtest/master/output/round2_Lenovo_X230_i5_16G/m_cost/memory_time.png

This the more useful one, and it doesn't look strange to me.  There's
some noise, but if the number of samples was small that's to be
expected.  Thank you!

It's puzzling that the Lyra2 lines don't reach 512 MB and that several
others don't have a final point at 1 GB, though.

When you benchmark -SSE versions, what exactly are those built for?
SSE2, SSSE3, SSE4.1, AVX, AVX2?

(FWIW, yescrypt's pwxform is such that it can be as optimal with SSE2 as
with AVX, but compilers tend to produce better code for it when SSE4.1
or AVX is enabled.  We may introduce a hand-written assembly version in
plain SSE2 eventually, which I expect to be same speed as AVX.  Luckily,
the performance difference between these different SIMD builds of
yescrypt is small, though.  Only AVX2 and beyond should differ more,
once such intrinsics are added to yescrypt-simd.c.)

While this is not relevant to your use case, I'd like to also see a
request rate capacity vs. memory usage per hash graph for the 128 KB to
128 MB range.  Note that I say "request rate capacity" rather than "run
time", because the relevant use case - password hashing on a server -
will have multiple concurrent requests, so that's what we should
benchmark (and this is what yescrypt's "userom" program simulates).

BTW, 128 KB is what UFC-crypt in glibc has been using/wasting for ages.

Alexander

Powered by blists - more mailing lists