Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 25 Apr 2013 20:20:21 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: ICC performance regression

$ git grep SSESHA1body *.S
sse-intrinsics-32.S:#define SSESHA1body     _SSESHA1body
sse-intrinsics-32.S:# -- Begin  SSESHA1body
sse-intrinsics-32.S:    .globl SSESHA1body
sse-intrinsics-32.S:SSESHA1body:

Well there is something, but I can't test it here. Please elaborate. You should be able to build the same file using the sse-intrinsics-32.S make target, and perhaps check if the perl script does something wrong? Although from git history it looks like the exact same script was used last time.

magnum


On 25 Apr, 2013, at 19:52 , "jfoug" <jfoug@....net> wrote:

> SSESHA1body is no longer appearing in the .S file ???  Whats up with that?
> 
> -----Original Message-----
> From: magnum [mailto:john.magnum@...hmail.com] 
> Sent: Thursday, April 25, 2013 2:10
> To: john-dev@...ts.openwall.com
> Subject: Re: [john-dev] ICC performance regression
> 
> On 25 Apr, 2013, at 1:30 , Solar Designer <solar@...nwall.com> wrote:
>> On Thu, Apr 25, 2013 at 01:12:19AM +0200, magnum wrote:
>>> Old pre-built files, icc 12.1.4:
>> [...]
>>> Benchmarking: FreeBSD MD5 [128/128 SSE2 intrinsics 12x]... DONE
>>> Raw:	39204 c/s real, 39204 c/s virtual
>> [...]
>>> gcc 4.7.2, -native target:
>> [...]
>>> Benchmarking: crypt-MD5 [128/128 AVX intrinsics 12x]... DONE
>>> Raw:	36936 c/s real, 36936 c/s virtual
>> 
>> This is pretty significant difference in favor of old icc, and not all 
>> CPUs have AVX, so I think we should simply continue to use old icc to 
>> prebuild the files.
> 
> This requires someone having an older version. I haven't found one yet.
> 
> Until now we have compared icc using -O3 (25 *minutes* compile time per
> file), to gcc using just -O2 (compiling in 3 seconds). I will try some
> different versions of icc as well as MD5_PARA values (very time consuming),
> but also different sets of options to gcc and see where we end up.
> 
>> Why the name discrepancy, though?  There was no intent to rename this 
>> format to crypt-MD5, was there?  If I rename it, I'll use md5crypt, 
>> including in the printed name.
> 
> I changed label now but not the name so it's just cosmetical. I found it
> misleading when loading an AIX {smd5} hash and it answered
> 
> Loaded 1 password hash (FreeBSD MD5 [128/128 AVX intrinsics 12x])
> 
> ...as if that was specifically what's been loaded. We can use md5crypt
> instead though.
> 
> magnum
> 
> 
> 


Powered by blists - more mailing lists

Your e-mail address:

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