Hi Chris,
interesting! On Wed, Nov 12, 2014 at 1:40 PM, Chris Muller <[hidden email]> wrote: I finally tracked down why the keys of the #knownEnvironments 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. But while we're on the subject, one thing we could do is arrange that Symbols have an identityHash based on their value. So when interning a string we'd compute its string hash and derive and assign the identityHash of the Symbol from the string hash. That would mean that when unpickling classes in e.g. Fuel we would not have to rehash method dictionaries, which would be very nice indeed.
best,
Eliot |
>> 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? |
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.png P.S.: With a primitive I suggested long ago, the blue line on the picture (#at:) could be as flat as the red (#includesKey:). |
Free forum by Nabble | Edit this page |