[issue5169] Default hash not equal to id on AMD Sempron

Terry J. Reedy added the comment: Chema, thank you for bringing this semi-conscious assumption to light. Intentionally breaking it significantly speeds up set and dict creation. -- nosy: +tjreedy resolution: -> invalid status: open -> closed superseder: -> Reduce hash collisions for

[issue5169] Default hash not equal to id on AMD Sempron

Raymond Hettinger added the comment: Tim, any thoughts? -- assignee: -> tim_one nosy: +tim_one ___ Python tracker ___ ___ Python-bugs

[issue5169] Default hash not equal to id on AMD Sempron

Mark Dickinson added the comment: See issue 5186 for using id()/8 for the hash. ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue5169] Default hash not equal to id on AMD Sempron

Jesús Cea Avión added the comment: Marc, please post the bugid for the "hash>>3" issue. It is interesting enough to pursue it. -- resolution: invalid -> status: closed -> open ___ Python tracker __

[issue5169] Default hash not equal to id on AMD Sempron

Chema Cortés added the comment: I also agree to close this bug as invalid. Indeed, there is not any reason to make equal id(a) and hash(a), but the description of "hashable" object from the documentation (but this is a different issue). 'hash' and 'id' returns the same-wordsize integer (32bit):

[issue5169] Default hash not equal to id on AMD Sempron

Jesús Cea Avión added the comment: The issue is trivially reproductible in any 32 bits platform, simply allocating objects until you go up the 2GB mark. Since __hash__() wants to take advantage of every bit in a 32 bit platform, and we don't have unsigned integers in python, I vote for "invalid

[issue5169] Default hash not equal to id on AMD Sempron

Mark Dickinson added the comment: Some preliminary timings indicate that it may well be worth replacing 'return (long)p' with 'return (long)p >> 3' in _Py_HashPointer (in Objects/object.c): I'm getting a 10% speedup in dict-building and dict-lookup for dicts of plain objects. I'll open a se

[issue5169] Default hash not equal to id on AMD Sempron

Mark Dickinson added the comment: Hah. Good point. I'd forgotten about the taking-the-low-order-bits thing. Should probably do some timings (and possibly also number-of- collisions measurements) to find out whether using id() >> 3 actually makes any significant difference (either way) for d

[issue5169] Default hash not equal to id on AMD Sempron

Antoine Pitrou added the comment: Because with hash() == id() == address of the PyObject, the hash is always a multiple of 4 or 8 (I think it's 8), so (hash() % dict_or_set_table_size) is non-uniformly distributed in most cases. ___ Python tracker

[issue5169] Default hash not equal to id on AMD Sempron

Mark Dickinson added the comment: It looks like this is a platform with sizeof(long) == 4 and sizeof(void *) == 8. Is that right? As Antoine says, I can't see any problem here. Why do you think that hash(a) should be equal to id(a) in this case? Antoine, in what way would id()/4 be better

[issue5169] Default hash not equal to id on AMD Sempron

Antoine Pitrou added the comment: I wouldn't qualify this as a bug. hash() doesn't need to be equal to the id() even in the default case. Actually, it may be better for hash() to be equal to id()/4 or id()/8, depending on the standard alignment of the memory allocator. -- nosy: +pitrou,

[issue5169] Default hash not equal to id on AMD Sempron

New submission from Chema Cortés : Sometimes, the default hash for user-defined object is not equal to the id of the object: In [1]: class A: ...: pass In [2]: a=A() In [3]: id(a),hash(a) Out[3]: (3082955212L, -1212012084) The test box has an AMD Sempron, a 64bit CPU archictecture emulati