Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 03 Sep 2015 21:29:37 +0200
From: magnum <>
Subject: Re: SHA-1 H()

On 2015-09-03 20:40, Solar Designer wrote:
> On Thu, Sep 03, 2015 at 11:52:47AM +0200, magnum wrote:
>> On 2015-09-03 06:56, Solar Designer wrote:
>>> On Wed, Sep 02, 2015 at 09:31:34PM +0200, magnum wrote:
>>>> #define Ch(x, y, z) (z ^ (x & (y ^ z)))
>>>> #define Ch(x, y, z) ((x & y) ^ ( (~x) & z))
>>>> This is 3 vs. 4 ops, right?
>>> On archs without AND-NOT, yes.  So it's a good find, and I'm happy you
>>> patched these.

>> Apparently GCN has ANDN and NAND.
> I need to take a fresh look at the arch manual, but in the generated
> code I only see scalar ANDN, and never vector ANDN (nor NAND).  They
> defined scalar ANDN presumably because it's so useful for exec masks.
> I see you've committed this:
> +#if cpu(DEVICE_INFO) || amd_gcn(DEVICE_INFO)
> +#define HAVE_ANDNOT 1
> +#endif
> but I think the check for amd_gcn(DEVICE_INFO) is wrong.

We currently never run vectorized on GCN anyway, unless forced by user - 
if format supports it at all. But perhaps it should be 
(amd_gcn(DEVICE_INFO) && (V_WIDTH < 2)) then?

> And why this change? -
> -#if !gpu_nvidia(DEVICE_INFO) || nvidia_sm_5x(DEVICE_INFO)
> +#if !gpu_nvidia(DEVICE_INFO)
>   #define USE_BITSELECT 1
>   #elif gpu_nvidia(DEVICE_INFO)
>   #define OLD_NVIDIA 1
>   #endif

I saw definite speedup for PBKDF2 and RAR iirc, and perhaps md5crypt. 
But later I saw contradicting figures for other formats so I'm not sure 
about this and things are in a state of flux. It might be that we should 
revert to initially setting it (for Maxwell) in opencl_misc.h, and later 
conditionally undefine it in certain formats.

Is bitselect() expected to always generate a LOP3.LUT? Even if it is, I 
figure the optimizer just might be able to do better when given 
bitselect-free code.

Besides all this, I see I introduced a bug: Now OLD_NVIDIA is defined 
for Maxwell and that was not the intention. I'll fix that right away.

>> BTW early tests indicate that 5916a57 made SHA-512 very slightly worse
>> (but almost hidden by normal variations).
> On what hardware?

AVX and AVX2. My overall feeling is SHA256 got a slight boost while 
SHA512 did not and sometimes the latter got a very slight regression. 
But I haven't really gone systematic yet. All my tests are very 
inconclusive as of yet, the fluctuations are larger than the 


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.