Mathias Panzenböck wrote:

However, there still could be a collision so you have to compare the key by value anyway, so the performance might not by that much better. And pythons strings are immutable so the hash code is cached anyway and has not be calculated every time. But this instruction could only calculate a hash of a sequence of bytes (like a string), not of a complex object which has some fields that form the key (and ohters that dont). So it's pretty useless in my opinion. (But I'm so tired I can hardly think, maybe I'm missing something.)

Yes, and that's that most language identifiers are "interned" strings: just a pointer to them is sufficient for equality comparison. (Ruby and every Lisp dialect on the planet call these "symbols".) Python is so very close to using nothing but interned strings for all namespace dicts that it wouldn't be that difficult to change it.

It's entirely possible that a hash of the string pointer would be sufficient, so it wouldn't even be necessary to hash the string and send it along.

Neil Toronto schrieb:

...

Full-on associative memory wouldn't be necessary. If there were a machine-level instruction in current chips that did a dict-style lookup almost as fast as a base+index*size, Python could *scream*. It might work like 80x86's lea (load effective address):

 hashaddr   base, recsize, dictsize, value, destreg

It would be very CISCy, and there are a whole host of practical problems dealing with hashing functions, good collision resolution, etc. But any pointer/index-based (e.g. interned string) lookup could go almost as fast as C++'s "this->". Mainstream is moving toward dynamic languages, and it makes sense to support that in hardware.

Heck, I hear routers and switches already have things like this. Does anybody have the ear of an Intel chip designer?

Neil