Stef,
I'm trying to think freshly, since this is very weird: I have measured with a fresh 3.8alpha...
My results for the IdentitySet variant have been *much* worser than yours, with or without the cs (which is expected, since the behavior of IdentitySet won't be affected by the cs). For this reason, the idea of the cs has been to introduce Behavior>>hash - using String>>hash - to avoid the default Object>>hash which itself calls ProtoObject>>identityHash. This is also the reason, why the IdentitySet variant remains worse for my system (it just continues to use >>identityHash). But the cs doesn't seem to have a relevant effect in your system, because *your* >>identityHash seems to work much better than mine!
Now the question: why?
ProtoObject>>identityHash calls a prim: which VM are you using?
It would be nice, if some other person would doIt the following expression and post the result together with the VM version (squeak -version) and processor version to get some more data.
DoIt ----
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
For me the result is
#(3112 3166 3108)
for
sr@karl:~/DepS/Tmp$ squeak -version 3.7b-5 #1 Mon Jun 14 18:05:35 CEST 2004 gcc 3.3.3 Squeak3.7beta of '1 April 2004' [latest update: #5954] Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-5/*.so
at a 366MHz Pentium.
Any additional ideas for the huge difference between mine and Stefs results are also welcome.
Greetings Stephan
stéphane ducasse wrote:
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asSet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}
one before #(27 27 25) one after #(31 35 32)
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
two before #(19 19 19) two after #(37 19 22)
I hope this helps. This was with 6273
Stef
PS: My Squeak3.8alpha#6285 stems from upgrading a Squeak3.6 image: could this be the reason for the hassle? Is there a difference between an actual image and upgrading a 3.6 one?
Stephan Rudlof wrote:
Stef,
I'm trying to think freshly, since this is very weird: I have measured with a fresh 3.8alpha...
My results for the IdentitySet variant have been *much* worser than yours, with or without the cs (which is expected, since the behavior of IdentitySet won't be affected by the cs). For this reason, the idea of the cs has been to introduce Behavior>>hash
- using String>>hash - to avoid the default Object>>hash which itself
calls ProtoObject>>identityHash. This is also the reason, why the IdentitySet variant remains worse for my system (it just continues to use >>identityHash). But the cs doesn't seem to have a relevant effect in your system, because *your* >>identityHash seems to work much better than mine!
Now the question: why?
ProtoObject>>identityHash calls a prim: which VM are you using?
It would be nice, if some other person would doIt the following expression and post the result together with the VM version (squeak -version) and processor version to get some more data.
DoIt
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
For me the result is
#(3112 3166 3108)
for
sr@karl:~/DepS/Tmp$ squeak -version 3.7b-5 #1 Mon Jun 14 18:05:35 CEST 2004 gcc 3.3.3 Squeak3.7beta of '1 April 2004' [latest update: #5954] Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-5/*.so
at a 366MHz Pentium.
Any additional ideas for the huge difference between mine and Stefs results are also welcome.
Greetings Stephan
stéphane ducasse wrote:
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asSet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}
one before #(27 27 25) one after #(31 35 32)
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
two before #(19 19 19) two after #(37 19 22)
I hope this helps. This was with 6273
Stef
Dear All,
I have the tail of the snake:
Stephan Rudlof wrote:
PS: My Squeak3.8alpha#6285 stems from upgrading a Squeak3.6 image: could this be the reason for the hassle? Is there a difference between an actual image and upgrading a 3.6 one?
There is! With the one from ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.8alpha/Squeak3.8a-6285-unstable.zip I have times like Stef (same magnitude, I have a slower processor)!
Why is there this difference?
Conclusions: - The BehaviorHashEnh cs is *not* needed for an *actual* image *not* being reached by incremental upgrading. - This result could be relevant for people just incrementally upgrading their images!
Greetings Stephan
Stephan Rudlof wrote:
Stef,
I'm trying to think freshly, since this is very weird: I have measured with a fresh 3.8alpha...
My results for the IdentitySet variant have been *much* worser than yours, with or without the cs (which is expected, since the behavior of IdentitySet won't be affected by the cs). For this reason, the idea of the cs has been to introduce Behavior>>hash
- using String>>hash - to avoid the default Object>>hash which itself
calls ProtoObject>>identityHash. This is also the reason, why the IdentitySet variant remains worse for my system (it just continues to use >>identityHash). But the cs doesn't seem to have a relevant effect in your system, because *your* >>identityHash seems to work much better than mine!
Now the question: why?
ProtoObject>>identityHash calls a prim: which VM are you using?
It would be nice, if some other person would doIt the following expression and post the result together with the VM version (squeak -version) and processor version to get some more data.
DoIt
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
For me the result is
#(3112 3166 3108)
for
sr@karl:~/DepS/Tmp$ squeak -version 3.7b-5 #1 Mon Jun 14 18:05:35 CEST 2004 gcc 3.3.3 Squeak3.7beta of '1 April 2004' [latest update: #5954] Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-5/*.so
at a 366MHz Pentium.
Any additional ideas for the huge difference between mine and Stefs results are also welcome.
Greetings Stephan
stéphane ducasse wrote:
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asSet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}
one before #(27 27 25) one after #(31 35 32)
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
two before #(19 19 19) two after #(37 19 22)
I hope this helps. This was with 6273
Stef
Now I have more than the tail of the snake:
Stephan Rudlof wrote:
Dear All,
I have the tail of the snake:
Stephan Rudlof wrote:
PS: My Squeak3.8alpha#6285 stems from upgrading a Squeak3.6 image: could this be the reason for the hassle? Is there a difference between an actual image and upgrading a 3.6 one?
There is! With the one from ftp://st.cs.uiuc.edu/pub/Smalltalk/Squeak/3.8alpha/Squeak3.8a-6285-unstable.zip I have times like Stef (same magnitude, I have a slower processor)!
Why is there this difference?
The difference is, that the fresh image has fewer classes! For me it is Smalltalk allClasses size -> 2136 for the incrementally generated 3.8, and -> 1683 for the fresh one.
Making some tests with sets of symbols: --------------------------------------- | symbols symbolsSet block | numOfSymbols _ 1500. symbols := (1 to: numOfSymbols) collect: [:num | num asString asSymbol]. block _ [symbolsSet _ symbols asIdentitySet. [symbols do: [:sym | symbolsSet remove: sym]] timeToRun]. {block value. block value. block value}.
#(11660 11558 11832) #(11627 11553 11744) #(11629 11568 11521) "numOfSymbols _ 2500."
#(311 310 317) #(318 327 314) #(309 331 312) "numOfSymbols _ 2000."
#(63 67 59) #(81 74 70) #(52 56 54) "numOfSymbols _ 1500." --------------------------------------
gives a big change in performance just between these values!
The conclusions are changing:
Conclusions:
- The BehaviorHashEnh cs is *not* needed for an *actual* image *not*
being reached by incremental upgrading.
This is not true: the BehaviorHashEnh cs makes sense, if there are some more classes in the image (e.g. by loading some packages from SM).
- This result could be relevant for people just incrementally upgrading
their images!
Without this changeset: indeed!
Like I've written in the cs comment: === Future: Best would probably be a better identityHash with more bits (possibly in V4?). ===
Suggestion: it could make sense to mark the changed methods for to be reworked after having more identityHash bits.
Greetings Stephan
Greetings Stephan
Stephan Rudlof wrote:
Stef,
I'm trying to think freshly, since this is very weird: I have measured with a fresh 3.8alpha...
My results for the IdentitySet variant have been *much* worser than yours, with or without the cs (which is expected, since the behavior of IdentitySet won't be affected by the cs). For this reason, the idea of the cs has been to introduce Behavior>>hash
- using String>>hash - to avoid the default Object>>hash which itself
calls ProtoObject>>identityHash. This is also the reason, why the IdentitySet variant remains worse for my system (it just continues to use >>identityHash). But the cs doesn't seem to have a relevant effect in your system, because *your* >>identityHash seems to work much better than mine!
Now the question: why?
ProtoObject>>identityHash calls a prim: which VM are you using?
It would be nice, if some other person would doIt the following expression and post the result together with the VM version (squeak -version) and processor version to get some more data.
DoIt
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
For me the result is
#(3112 3166 3108)
for
sr@karl:~/DepS/Tmp$ squeak -version 3.7b-5 #1 Mon Jun 14 18:05:35 CEST 2004 gcc 3.3.3 Squeak3.7beta of '1 April 2004' [latest update: #5954] Linux karl 2.4.26sr #1 Sun May 23 19:28:24 CEST 2004 i686 GNU/Linux default plugin location: /usr/local/lib/squeak/3.7b-5/*.so
at a 366MHz Pentium.
Any additional ideas for the huge difference between mine and Stefs results are also welcome.
Greetings Stephan
stéphane ducasse wrote:
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asSet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}
one before #(27 27 25) one after #(31 35 32)
| allClasses allClassesSet block | allClasses := Smalltalk allClasses. block _ [allClassesSet _ allClasses asIdentitySet. [allClasses do: [:class | allClassesSet remove: class]] timeToRun]. {block value. block value. block value}.
two before #(19 19 19) two after #(37 19 22)
I hope this helps. This was with 6273
Stef
squeak-dev@lists.squeakfoundation.org