phc-discussions - Re: [PHC] RIG vs. scrypt performance comparison

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]

Message-ID: <CAB1Qo9q7BS5U+9r3SmKhU0-0AxTJCvcem9yhq62SLPmcXvMh1Q@mail.gmail.com>
Date: Tue, 10 Feb 2015 18:22:37 +0530
From: Arpan Jati <arpanj@...td.ac.in>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] RIG vs. scrypt performance comparison

Hi Alexander,

Thanks for your observations.

1) Well, this is just a matter of interpretation of the sentence "Intel
Core i7-4770CPU with 16GB RAM at 2400 MHz" from page 14 of RIG-v2.pdf.
English can sometimes be ambiguous, and a sentence can have multiple
possible interpretations. We have mentioned the setup in a more detailed
way in code: https://github.com/arpanj/Rig/blob/master/Rig_v2-opt/main.c

GCC v4.9.1 (CFLAGS=-std=c99 -mavx2 -O3 -funroll-loops)
CPU: Intel Core i7 4770 (Turbo Boost: ON)
RAM: Double Channel DDR3 16 GB (2400 MHz)

So, the CPU was working at normal Turbo-Boost frequency of 3.9 GHz, without
throttling during the experiments. The memory speed was specified as it was
higher than normal of 1366/1600 MHz, albeit having higher latency.

2) Regarding the benchmarks we did use the reference code initially,
because in the first version of our submission, we were not using SSE/AVX.
Secondly, for smaller block sizes, the SSE/AVX implementations tend to
yield much lesser performance benefits, because of memory
latency/allocation overheads.

It would have been better to include optimized / SSE benchmarks for scrypt
too.

The best thing would be to have two graphs with multiple candidates from
PHC with both the optimized and reference versions as some CPU's especially
mobile ones may not have SSE/AVX and would need to fallback on the
reference implementations.

That may be done in a future revision of the document.

regards,

Arpan

On Tue, Feb 10, 2015 at 6:50 AM, Solar Designer <solar@...nwall.com> wrote:

> On Mon, Feb 09, 2015 at 10:25:29PM +0300, Solar Designer wrote:
> > Even at the mysterious "2400 MHz" (probably
> > just a typo), this would be 2.2 to 2.5 seconds.  That's 6 times faster
> > than the 12 seconds.
>
> More like 5 times, sorry.  I make errors too.
>
> > (And ~7.5 to ~8.5+ times faster if the CPU was
> > also running at 3.9 GHz in the RIG benchmarks, which it might have been
> > unless under-clocked.)
>
> Alexander
>

Content of type "text/html" skipped