Date: Sat, 5 Sep 2015 07:17:49 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: MD5 on XOP, NEON, AltiVec On Sat, Sep 05, 2015 at 05:25:16AM +0300, Solar Designer wrote: > Here's what we had last year: > > Benchmarking: md5crypt, crypt(3) $1$ [MD5 128/128 XOP 8x]... (8xOMP) DONE > Raw: 201472 c/s real, 25152 c/s virtual > > Here's what we have now: > > Benchmarking: md5crypt, crypt(3) $1$ [MD5 128/128 XOP 4x2]... (8xOMP) DONE > Raw: 150272 c/s real, 18784 c/s virtual I sort of found it: somehow the code handling SSEi_FLAT_OUT, when compiled in, changes the stack frame layout in such a way that performance drops. I wasn't yet able to tell why it drops. The offsets look properly aligned to me either way. With SSEi_FLAT_OUT support #if 0'ed out, I get: Benchmarking: md5crypt, crypt(3) $1$ [MD5 128/128 XOP 4x2]... (8xOMP) DONE Raw: 223232 c/s real, 27869 c/s virtual And that's not even with the MD5_I change yet (haven't tried it yet). For raw-md5, performance stays the same. For raw-md4, commenting out its SSEi_FLAT_OUT results in very slight regression, and its speed is unexpectedly low either way (about the same as raw-md5's, whereas it should be faster). So there's yet another performance issue for us to investigate for raw-md4 (and maybe other MD4-based formats). As to commenting out SSEi_FLAT_OUT support for both of these, as far as I can tell we are not using it currently. (We're using it for SHA*.) Alexander
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.