Date: Wed, 19 Sep 2012 12:31:17 -0500 From: "jfoug" <jfoug@....net> To: <john-dev@...ts.openwall.com> Subject: RE: 1.7.9-jumbo-7 Ok, I see what you were doing. I thought it was picking up a #define from the sha lib being used. But even though this is not the bug, changing things like this to be 'JOHN_SHA_BUF_SIZE' (or JTR_... ) will firmly document that it is a JTR constant, and it also avoids collisions between JTR and system/3rd party library code. Btw, any idea on why the code which uses the circular temp buffer was slower on this system? The code I wrote does use just a touch more CPU to roll the temp vars through a circular buffer, but I would think the memory savings would more than make up for that, especially (IIRC), since the last few loops do not write back to memory since it will never be accessed. Possibly this system simply has a very tiny L1 cache or something, where the memory stall reduction does not offset the CPU overhead. Jim. >From: magnum [mailto:john.magnum@...hmail.com] > >What you write is true in general, but the bug in question was not about >that: The SHA_BUF_SIZ I'm talking about only exist in JtR's own sse- >intrinsics.c code. It's set to 80 for Simon's original 80x4 buffer SSE2 >SHA-1, and 16 for your later 16x4 code that use buffers similar to MD4 >and MD5 (except for endianness). Your code is faster on every platform I >have tried except OSX w/ llvm. So I modifed x86-64.h to use 80 for these >builds - and that triggered the bug!
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ