Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141225021459.GA17355@openwall.com>
Date: Thu, 25 Dec 2014 05:14:59 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: bcrypt BF_X2=3 is not always best

Hi,

This is not really news.  The 3x interleaving works significantly better
than 2x for Intel x86-64 CPUs without Hyperthreading (such as Core 2
Duo/Quad), but is usually of little help or sometimes even hurts speeds
on CPUs that are capable of running 2 threads/core.

Here's an example, off Twitter:

<@will_sargent> @solardiz "--test --format=bcrypt" BF_X2=1 is 8625,8784,8640,8928,8856,8784.  BF_X2=3 is 8208,8233,8208,8424,8424,8424,8340,8233,8233,8258.

This is on i7-5820K, 3.3+ GHz, running 12 threads on 6 cores, JtR built
with gcc 4.8.2-19ubuntu1 per @will_sargent's entry on:

http://openwall.info/wiki/john/benchmarks

I don't know how/whether we can reasonably detect which BF_X2 setting is
best.  Running benchmarks at build- or run-time is unstable or slow,
given the variance seen under light unrelated load.  And these would have
to be full OpenMP benchmarks, because relative speeds are different when
running only 1 thread.

On our "super" machine, which also runs 2 threads/core, BF_X2=3 provides
slight speedup (~16000 c/s to 16800+ c/s) with "gcc 4.8.1 20130715
(Red Hat 4.8.1-4)", which is a close enough gcc version that I think
it's more of a CPU than gcc difference here.  So we probably can't fix
it by checking gcc version.

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.