Messages in this thread | | | From | Hannes Frederic Sowa <> | Subject | Re: Where exactly will arch_fast_hash be used | Date | Mon, 08 Dec 2014 17:32:09 +0100 |
| |
On Mon, Dec 8, 2014, at 17:19, George Spelvin wrote: > >>> In case of openvswitch it shows a performance improvment. The seed > >>> parameter could be used as an initial biasing of the crc32 function, but > >>> in case of openvswitch it is only set to 0. > > >> NACK. [...] > > > Sorry for being unclear, I understood that and didn't bother patching > > that '0' with a random seed exactly because of this. > > And I'm sorry for delivering a long lecture on a subject you already > understood perfectly well.
I learned something, so your time wasn't completely wasted. ;)
> I'd just been thinking about it because of Herbert's comments, so it was > conveniently at hand. :-) > > Out of curiousity, what *were* you referring to when you talked > about biasing the crc32 function? "Biasing" is a good term becuase > it just applies an offset, but what do you gain from doing that?
Actually, I don't know why the seed parameter was added. I just wanted to mention that there is a way to bias the crc32 function which fits into the style of the other hashing functions, like jhash with its initval parameter.
I just kept it around during the rewrite.
The only use case I can imagine would be if one would like to calculate a crc32c over a non-contiguous array, thus feeding the result of one crc operation into the next one.
> There are nifty things one can do with the CRC32 instruction, however. > A lot of ciphers these days use an ARX (add, rotate, XOR) kernel. > A crc32 instruction, although linear, does some very powerful rotate & > xor operations, and could replace the XOR and rotate.
Yes, I have seen it being used in cityhash.
There is also a proposal by Intel, but the hash seems too weak, too: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/hash-method-performance-paper.pdf
Bye, Hannes
| |