[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <002701cd968c$938de430$baa9ac90$@net>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
