[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ED03E3B.1070103@hushmail.com>
Date: Sat, 26 Nov 2011 02:17:47 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: mdfourmmx
I'm taking this to the list instead just in case anyone else have an
opinion. This started out with the question "why was mdfourmmx never
added to JtR?"
Simon answered:
>> The best way to do it is probably with intrinsics now. It never was
>> incorporated because solar viewed my code with a mixed feeling of
>> disdain and horror (with reasons!).
JimF wrote:
> I agree with Simon here. I really think we should transition away
from the sha1-mmx.S and md5-mmx.S files if we possibly can, for all
builds. That is as long as we can get 'fast' properly built intrisic .S
files. Yes, building the sse-intrisics.c with gcc (or VC) 'works', but
comes no where near the speed of the 32bit .S files. However, with
properly pre-compiled intrisics, it is a wash, or better. Along with
that, the intrisics are thread safe, which would be a very hard thing to
do with the older 32 bit asm.
The reason I was considering it is that it's like 3-4 extra lines of
code in each format (bar the #ifdefs) once the .S file is there, given
you already have SSExxxbody implemented in a format.
> NOTE, there likely are still a few formats which are faster with the
32bit .S files, and likely are some systems where the 32 bit .S files
will be faster for most formats. I will see what can be done to
minimize these performance differences in the coming weeks.
>
> Jim.
I have patches pending that will boost all GETPOS-type formats, but that
boost will apply to the "legacy" mmx/sse builds too. If we can get just
a little more power out of sse-intrinsics.c itself, then we're talking.
magnum
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.
