Actually it will

Posted Jan 23, 2012 12:30 UTC (Mon) by khim (subscriber, #9252)
In reply to: About Future CPUs by ekj
Parent article: Denial of service via hash collisions

Putting the thing in hardware wouldn't really change that.

But it would! Good hash functions are pretty hard to implement in software because you basically need to randomly shuffle bits around - and it's hard to do that in software. In hardware it's trivial.

AES-NI instructions have sustained speed of about 1byte/tick (of course small strings are slower). It'll be interesting to see how large of a hit it'll produce in python, for example. It will probably be slower then current hash, but difference may be small enough for real usage.

Actually it will

Posted Jan 23, 2012 12:40 UTC (Mon) by ekj (guest, #1524) [Link]

I guess I was being unclear.

What I meant is that in typical use, producing hashes to use for inserting and/or looking things up in dictionaries is not a major performance-impact for Python.

I don't doubt that hashes can be produces quicker by dedicated hardware, but if you're using a small fraction of your time for that purpose to start with, then the gains from reducing it, are modest.

It'd be interesting benchmarking a variety of workloads in a variety of languages to see what fraction of time is used for hashing though, because I'm really just guessing here, and I could be wrong.