Paul G

It's a bit late, so my apologies if I'm not making any sense. That particular fork of smhasher uses a different statistical technique for avalanche tests (compared to the appleby...

Ah, that explains it. The appleby version is far behind the times, unfortunately, and there are lots of hashes that pass it but still have non-negligible flaws. People essentially over-optimize...

> Making a hash function faster is a lot of fun. It would be interesting to see your Skylake-X > optimizations. All my tries to vectorize mum-hash about 2 years...

> Making a hash function faster is a lot of fun. .. and yes, completely agree with you there. Although, in practical terms, mum, fanom and t1ha2_atonce are already 'good...

... and it becomes clear from reading the code that \@with_cmp makes .__hash__() behave in the exact way needed to satisfy this use case. Perhaps a mention of this in...

Thanks for the pointer, I'll be using attrs from now on. It's got a number of small improvements, but there are so many that it adds up to a big...

Not connected with the development, but if you are correct that it requires ATAPI PIO Mode 4, it will not be in RASCSI. RASCSI emulates, unsurprisingly, SCSI. ATA (PATA aka...

The really valuable things in Yves' fork are: 1. Configurable seed, state and hash sizes up to 128 bits (and beyond, presumably) 2. (Optional) state-generation stage for hash funcs with...

Massive amount of work, that, and probably best done by someone familiar with the internals. Much as I'd like to say otherwise, my comment was a response to the 'evaluate'...

It makes sense conceptually to have the init state generation and the actual run be separate. When people contribute their hashes, they follow the structure that SMHasher requires of them....