Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Apr 2015 18:03:05 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] JtR SIMD support enhancements

On 2015-04-23 17:35, Lei Zhang wrote:
>> On Apr 23, 2015, at 6:37 PM, Solar Designer <solar@...nwall.com> wrote:
>> Have you tried tuning the interleave factors already?
>
> I'm not sure of the "interleave factors". Could you be more specific?

It's these lines in mic.h:

#define MD5_SSE_PARA		1
#define MD5_N_STR			"16x"
#define MD4_SSE_PARA		1
#define MD4_N_STR			"16x"
#define SHA1_SSE_PARA		1
#define SHA1_N_STR			"16x"

See them in use in sse-intrinsics.h. They control interleaving of the 
primary hash functions to hide latencies. When >1 they will turn your 
"16x" for AVX-512 into "16x2" or "16x3" and hopefully with a net gain.

See the #if..#elif..#else..#endif's in x86-64.h for how we pick them on 
a normal CPU (we benchmarked all combinations to come up with this). The 
figures depend on things like CPU type, compiler brand and version. In 
your case you don't have a lot of compilers to test but it might be a 
good idea to just add a comment stating what exact version of icc and 
what exact MIC model was used to find the figures.

So try bumping these values, rebuild and benchmark eg. md5crypt for MD5 
and wpapsk for SHA1 to see what happens. For MD4 I'm not sure we have 
any looped format, so just benchmark raw-md4.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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