[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <02e301cd5cf3$8b40f1f0$a1c2d5d0$@net>
Date: Sun, 8 Jul 2012 05:22:14 -0500
From: "jfoug" <jfoug@....net>
To: <john-dev@...ts.openwall.com>
Subject: RE: MD5 timings (x96-32)
>From: Solar Designer [mailto:solar@...nwall.com]
>
>On Sat, Jul 07, 2012 at 04:57:08PM -0500, jfoug wrote:
>> Also, I think we should make changes in the x86-mmx.h and x86-sse.h,
>> to have these build types use MD5_X2 and not asm.
>
>We'll need to combine this with a gcc version check like I do for BF_X2,
>but with different gcc versions. Here's what I get on Core i7 920 (best
>of several runs since the machine is a server with some light load):
>
>gcc 3.4.5, x1 - 8100 c/s (asm code, reference speed) gcc 3.4.5, x2 -
>5500 c/s gcc 4.0.0, x2 - 8250 c/s gcc 4.1.0, x2 - 8200 c/s gcc 4.2.0, x2
>- 7940 c/s gcc 4.5.0, x2 - 8750 c/s
Interesting. So this is more compiler version dependant, than the 'newest'
CPU dependant.
NOTE, I did do some builds with MD5_ASM 0 MD5_X2 1, and ran into a problem
(multiple MD5_body in linke).
I had to do this to get around it. I am NOT sure this was the proper place,
or proper fix:
In x86.S, I added this, after the UNSERSCORES block:
#if MD5_ASM == 0
#undef MD5_body
#define MD5_body MD5_body_unused
#endif
It is likely, this compilation 'path' had never been tried before, under the
assumption that the ASM pathway would always be superior.
The one thing that really puzzles me, is the 10% speed change to the CRC
format. I just do not understand HOW that format is being affected by the
change away from x86 asm, to x86-c-X2 code. But it happens every time. The
crc format, uses a simple #define into a pre-computed CRC table (in the
pkzip.h header). It should have zero impact by the change in the md5 asm vs
C. A head scratcher for me, but not a serious format.
Jim.
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.
