Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 1 Sep 2015 19:29:53 -0500
From: JimF <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: 23% performance regression for brypt (Intel i5-4570
 CPU)


On 9/1/2015 7:00 PM, magnum wrote:
> If only well had a regression, perhaps decrease to X2 only for 
> __AVX2__? Or maybe this is also about gcc version?

Umm, no. The improvement seems to be even better on AVX2.  I really 
think this

#if __AVX__
BF_X2=1
#else
BF_X2=3
#endif

seems to be almost universally wrong.  Possibly there is some system 
which regressed to a slower speed (or like you mention a gcc version), 
but I have tested Intel-AVX, AMD-XOP and Intel-AVX2 systems. All get 
good gains going from BX_X2=1 to BF_X2=3   A 25-30% gain is NOT 
something trivial.  Losing that 30% gain because there is some system 
somewhere which lost 5% seems truly wasteful.

I still say if we can not get this static set variable changed to a 
better value that we simply ignore it within arch.h, and probe the 
system to find out what IS the best option for the machine at 
./configure time.  This certainly would be a 'fat' probe, but would get 
the value correct for the build, which MAY change based upon things like 
gOMP, compiler version, CPU, even the memory speed may change the 
optimal value.  If we put it into configure, then we will probably want 
to do it with an --enable-bcrypt-probe since it may be pretty darn time 
consuming, finding the best value.  We may have to build a minimal JtR 2 
(or 3?) times, running -test to find proper best speed.  The compile 
could be made minimal by ripping out all *_plug.c files, BUT it still is 
a compile that would have to be done.

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ