Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-31 Thread Stéphane Ducasse
Yes this is my gut feeling too. If the authors knew about the limited range of #identityHash, that is entirely possible. I tend to think it more likely that in most cases these implementations are just the simplest way to follow the dictate that 'a=b - a hash = b hash', and that they didn't

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-31 Thread Stéphane Ducasse
What I can tell you is that I ***loves*** this discussion. It illustrates the spirit of pharo that we want to push. Let's make a better and cooler smalltalk :) And people are even learning nice knowledge. Thanks On Oct 29, 2009, at 3:14 AM, Andres Valloud wrote: Martin, One of the

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-31 Thread Stéphane Ducasse
We agree, mod I wouldn't want to impose version maintenance homework on maintainers of large packages. For the sake of illustration only, and using Magma without knowing if it would be affected, I wouldn't want whoever is maintaining Magma to maintain two branches... one for Pharo 1.xyz,

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-28 Thread Stéphane Ducasse
Martin so what you are saying is that we can gain speed. And that these changes are beneficial for simple default. The test code, a variant of the test from the HashTable SqueakSource wiki, is at the bottom of this message. Basically, it adds a bunch of instances of Object to a

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-28 Thread Andres Valloud
Stephane et al, Martin and I discussed this yesterday night at the PDX Smalltalk user group meeting. Mostly we agree, with perhaps one small exception. In order to make hashed collections simpler and identity hash handling more straightforward, hashed collections should get a small integer

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-28 Thread Martin McClure
Andres Valloud wrote: Stephane et al, Martin and I discussed this yesterday night at the PDX Smalltalk user group meeting. Mostly we agree, with perhaps one small exception. In order to make hashed collections simpler and identity hash handling more straightforward, hashed collections

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-28 Thread John McIntosh
I looked at the squeak identityHash in squeak a few years back (a) how efficient was the algorithm? Attempted at one time to replace with a fixed array of numbers. There was some benefit on slow machines. (b) only calculate the identity hash when required, but then how do you mark the oops with

Re: [Pharo-project] Hashed collection changes, the performance graphs

2009-10-24 Thread Martin McClure
Martin McClure wrote: Gotta go see my wife in a play now; will comment on these graphs later. The play was fun :-) Now about the graphs: The test code, a variant of the test from the HashTable SqueakSource wiki, is at the bottom of this message. Basically, it adds a bunch of instances of

[Pharo-project] Hashed collection changes, the performance graphs

2009-10-23 Thread Martin McClure
Gotta go see my wife in a play now; will comment on these graphs later. -Martin inline: DictPerformanceGraphs.png___ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project