On Fri, 14 Nov 2014, Chris Muller wrote:
Anyway, something to be aware of -- anywhere we have true, false or nil used in a hash calculation, now has a different hash in Spur vs. Cog. Maybe we should think about separating those objects' logical "value" hash from their identityHash in trunk..? That could be useful when we move to 64-bit someday..
Remember that Spur has a common header format for both 32-bit and 64-bit versions, so in both there is a 22-bit identityHash and hence the identityHashes of all objects in a 64-bit Spur image bootstrapped from a 32-bit Spur image will be _unchanged_. Convenient. So no need to worry. And it should be the case that a freshly bootstrapped 64-bit Spur image does not need to be rehashed to function properly.
Suprising that their identityHash needs to change for Spur but not to go to 64-bit..
Wait, I thought one of the benefits of 64-bit was to finally increase that small identityHash?
22 is already a lot more than the current 12. Current hashed collections should give excellent performance up to 4 million elements with a 22-bit identity hash. Insertion and lookup performance should be good up to 60 million elements, and removal performance should be good up to 20 million. And you'll still be able to use hashed collections optimized for large sizes[1][2] if you want to store more objects. Levente [1] http://leves.web.elte.hu/LargeIdentityDictionary/ [2] http://leves.web.elte.hu/LargeIdentityDictionary/LargeIdentityDictionary2.pn... P.S.: With a primitive I suggested long ago, the blue line on the picture (#at:) could be as flat as the red (#includesKey:).