String hashing was: Thou shalt have no other gods before the ANSI C standard 1540
String hashing was: Thou shalt have no other gods before the ANSI C standard 1541
Agreed. That's why I mentioned it above. I think most (if not all) of the notebook vendors play games with the CPU speed to try and win battery life contests. I need to...
Hmmm! So what do you know about that ... the P4 can actually do 16-bit accesses will reasonably performance! Still beat by my Athlon at a lower clock rate, but I was really expecting my code to suck eggs on the P4. Of course the poor performance of the FNV hash is not good news for anyone wanting to do public-key crypto on the P4.
Dude, something is *really* wrong. Even if you take any of the other hash functions as baseline, that mobile Athlon 64 3200+ is running slower than my Athlon XP "1900".
Uh ... this really isn't a test of 64 bit capabilities. If it makes any difference at all on the Athlon 64-Opterons I would be surprised, and from what I have heard about Intel's EM64t, if anything the performance will go down.
No, no. A coppermine 700 would be based on the P6 architecture and therefore has the crappiest 16 bit support in the universe. You could try to force the loop to use the portable code path or try a different compiler (but it would not be too unlikely that my code just can never do well on a P6 core).
"SuperFastHash" does not need any cache (look at the code, man). It needs good "byte" or "short" array speed. In fact I was expecting it to be really bad on RISC architectures, but this is not that case at least on the Power4 (and therefore most likely the PPC architecture in general).
-- Paul Hsieh
Michael Amling Yes. :) Yes. :) Sorry for posting this in sci.crypt, but my hash function is specifically *NOT* recommended for any kind of signature or data integrity check. Its better than xoring the...