Hi Andreas,

as said earlier I understand your argument, and now I can also appreciate  
the figures you extracted from a Croquet image. I have something similiar  
(in terms of extracted figures :) from Squeak 3.9 running morpic. I assume  
that all morphs are used in the World's steps and looked at what is there  
most often (expression's code is below). As can be seen I concentrate just  
on the "collective" aspect, i.e. when #submorphs are fetched. There are  
290 senders of #submorph (and 307 accessors of the corresponding iVar,  
</phew>) and I collect possible call-sites where the PIC's size must be >=  
3 (counting that as non-trivial case and to be for sure on distance to  
your figures).

I so found 1034 non-trivial elements (sum of distinct types [when >= 3]  
over the 846 morphs [objects which respond to #submorphs]) in my running  
image (strange things these morphs :) But these figures are not used in  
the next computation, just for selecting a single subject:

AlignmentMorph (which here has 159 instances and 161 users) looks to be  
max. Using your (as always excellent!) piece of code, that shows that  
roughly 33% of them have non-trivial #submorphs. So much for your "noise"  
 from the morphic side ;-)

	97 (61.0%): 1
	50 (31.44%): 3
	6 (3.77%): 0
	3 (1.88%): 2
	3 (1.88%): 4

/Klaus

P.S. please note that in your post you compared all collections with  
distribution of omega types to my smaller collection with distribution of  
8 types. We already remarked (have we?) that it makes no sense to compare  
[for example] the collection of all classes (b/o 100% distinct types).  
Same goes with the other dimension, IINM.

---------
Figures produced with:
---------
  | bag max | bag := Bag new.
  AlignmentMorph allInstances asArray collect: [:each |
   bag add: (each submorphs collect: [:object | object class])  
asIdentitySet size].
	"Andreas' code follows"
  max := bag size.
  bag sortedCounts do:[:assoc|
  	Transcript crtab; show: assoc key.
  	Transcript show: ' (', ((100.0 * assoc key / max) truncateTo: 0.01)  
asString,'%): '.
  	Transcript show: assoc value]
---------
AlignmentMorph seems to be max:
---------
  | morphInstances subtypeMorphs distinctTypes submorphs minTypes maxTypes  
outliners |
  morphInstances := subtypeMorphs := 0.
  minTypes := Smalltalk size. maxTypes := 0.
  distinctTypes := IdentitySet new: 1000.
  outliners := IdentitySet new: 100.
  Smalltalk garbageCollect; garbageCollect.
  "count # of submorphs containers and their distinct submorphs' type(s)"
  SystemNavigation default allObjectsDo: [:object |
	((object respondsTo: #submorphs)
		and: [(submorphs := object submorphs) notNil and: [
				submorphs isEmpty not]]) ifTrue: [
		distinctTypes do: [:key | distinctTypes remove: key].
		submorphs do: [:each | distinctTypes add: each class name].
		morphInstances := morphInstances + 1.
		subtypeMorphs := subtypeMorphs + (submorphs := distinctTypes size).
		minTypes := minTypes min: submorphs.
		maxTypes := maxTypes max: submorphs.
		submorphs >= 3
			ifTrue: [outliners add: object class name].
		]].
  "determine the popularity of morphs with most # of distinct submorphs"
  outliners := outliners asArray collect: [:each |
	each -> (SystemNavigation default allCallsOn: (distinctTypes := Smalltalk  
associationAt: each)) size
			-> distinctTypes value instanceCount].
  ^ {morphInstances. subtypeMorphs. minTypes. maxTypes} , outliners asArray
---------

On Sun, 17 Dec 2006 20:32:51 +0100, Andreas Raab wrote:
> Klaus D. Witzel wrote:
>>> The claim is about "Smalltalk code", not about "Klaus Witzel  
>>> Benchmarks" (the difference between the two should be obvious).
>>  Not that I see any difference, I posted Smalltalk code (perhaps you  
>> meant something else?)
>
> Yes, clearly you don't see the difference and this seems to be at the  
> heart of the problem. You are running a micro-benchmark with specific  
> performance characteristics, that are not typical for Smalltalk code in  
> the large. Of course, you are free to make up your own performance  
> characteristics and measure these but that's what I call "Klaus Witzel  
> Benchmarks" - code that has been chosen because it has performance  
> characteristics that you want to measure not the performance  
> characteristics that "Smalltalk code" *typically* has.
>
> The Strongtalk claims are about *typical* Smalltalk performance  
> characteristics, nobody has ever claimed that Strongtalk would run any  
> code with any performance characteristic that anyone could ever come up  
> with faster than other Smalltalks. In particular, there is no claim  
> about "faster polymorphic send performance than any other Smalltalk".
>
> Nevertheless, solely based on this benchmark (which, again, do not  
> reflect typical Smalltalk performance characteristics) you are making  
> outrageous claims like: "I'm sorry to tell that Strongtalk is NOT that  
> fast." or "I'm disappointed, Strongtalk was always advertised as being  
> the fastest Smalltalk available "...executes Smalltalk much faster than  
> any other Smalltalk implementation...", and now it shows to be in almost  
> the same class as Squeak is".
>
> That's what I object to. Your benchmark is absolutely no basis for such  
> far-reaching and (once you do some real benchmarking) obviously false  
> claims. A single micro-benchmark is simply not enough to judge overall  
> performance.
>
>>> And as I am saying in the above the *actual* code has "Smalltalk  
>>> performance characteristics" whereas your made-up micro-benchmark  
>>> doesn't.
>>  C'mon. Sending messages to elements of collections _is_ characteristic  
>> for the Smalltalks.
>
> Yes, sending messages to elements of collections is characteristic. But  
> sending messages to elements of *highly polymorphic* collections (which  
> you specifically constructed for the benchmark) is not.
>
> Fortunately, it is very easy to show just how non-characteristic your  
> choice of collection is by looking at an actual image:
>
> 	lastObj := Object new.
> 	nextObj := nil someObject.
> 	bag := Bag new.
> 	[nextObj == lastObj] whileFalse:[
> 		nextObj isCollection ifTrue:[
> 			set := Set new.
> 			nextObj do:[:each| set add: each class].
> 			bag add: set size.
> 		].
> 		nextObj := nextObj nextObject.
> 	].
> 	max := bag size.
> 	bag sortedCounts do:[:assoc|
> 		Transcript crtab; show: assoc key.
> 		Transcript show: ' (', ((100.0 * assoc key / max) truncateTo: 0.01)  
> asString,'%): '.
> 		Transcript show: assoc value.
> 	].
>
> The result of which is (in a Croquet image I'm doing my work in):
>
> 	306384 (85.12%): 1
> 	31278 (8.69%): 2
> 	19377 (5.38%): 0
> 	2487 (0.69%): 3
> 	178 (0.04%): 4
> 	51 (0.01%): 5
> 	38 (0.01%): 6
> 	18 (0.0%): 10
> 	17 (0.0%): 7
> 	14 (0.0%): 8
> 	8 (0.0%): 9
> 	[...etc...]
>
> In other words, more than 90% of all the collections (some 350,000 so  
> it's a nice big sample) have at most a single receiver type. 8% have two  
> receiver types. Everything else is noise. If you keep in mind that good  
> amount of the 8% are due to monomorphic collections using Arrays  
> utilizing nil to indicate empty slots the practical percentage of  
> monomorphic collections is probably somewhere between 95-98%.
>
> So no, your benchmark is not characteristic for Smalltalk code.
>
> Cheers,
>    - Andreas
>
>