|
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.