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.