Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 12 Nov 2011 13:26:21 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: more targets using sse-intrinsics.S

2011-11-11 21:45, jfoug wrote:
> These 2 also need looked at:
> 
> SSE2 mmx-md5.S
> Benchmarking: Netscape LDAP SSHA [4x]... DONE
> Many salts:	10398K c/s
> Only one salt:	6919K c/s
> Benchmarking: Netscape LDAP SHA [4x]... DONE
> Raw:	7860K c/s
> 
> SSE2 sse-intrisic-32.S  (simply reverts back to 'any')
> Benchmarking: Netscape LDAP SSHA [8x]... DONE
> Many salts:	3133K c/s
> Only one salt:	2954K c/s
> Benchmarking: Netscape LDAP SHA [8x]... DONE
> Raw:	3173K c/s
> 
> I am not sure about these.  I do not know what the [8x] is, or where it comes from.

I had a look at OPENLDAPS_fmt_plug.c and it is a mess. There are
shammx() calls in there but the code is not complete - so there are
simply a couple of #undefs that disables mmx/sse completely!

Furthermore, there was bogus use of sse-intrinsics macro SHA1_N_STR
(though intrinsics functions are not used) which lead to this bogus "8x"
output. This last thing is the case for the two above too (though they
do have working, but non-intrinsics, sse/mmx support).

I will submit a patch that just fixes this bogus use of SHA1_N_STR
though we should eventually enable use of intrinsics in all three.

magnum

Powered by blists - more mailing lists

Your e-mail address:

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