[Enh][VM] primitiveApplyToFromTo for the heart of the enumeration of collections?

Bryce Kampjes bryce at kampjes.demon.co.uk
Sun Sep 17 16:22:25 UTC 2006


Klaus D. Witzel writes:
 > 
 > Heh, t'was the first dialog without the E...y word (since our first  
 > meeting in the #squeak channel ;-)

Exupery is not a swear word. If you're planning for something to be
added with a 4.0 then Exupery should definitely be considered. It does
exist. It does beat VisualWorks for the bytecode benchmark. It is
probably as fast as Strongtalk for bytecode performance as well now
(based on comparing the numbers Dan gave with the ones I got. Not
apples to apples on the same hardware). Exupery is relevant if we're
talking about Squeak's performance over the next few years. Exupery is
Squeak's and Smalltalk's best current hope of beating both Strongtalk
and Selfs pioneering work on high performance implementation's.

The cost to Exupery should not be ignored if the community does want
Exupery. I have not argued against your change because of this cost
though I to object to your statement earlier that Exupery should be
ignored for now. You ask that this change be given a chance. I have
invested over 2 days into analysing it and discussing it. You then
claim that something I have worked on for about 4 years should be
ignored is not pleasant. My investment in your change is not that much
less than yours.

I have not argued that your change should be discounted solely because
it will negatively effect performance when running with Exupery. I've
even told you how the shadow can be implemented so it will not
negatively impact performance on either the interpreter or with
Exupery. Just use bytecodes to assign to the argument not tempAt:put:,
neither Exupery nor the interpreter know the difference between an
argument and a temporary. This distinction, while a language one, is
made at a higher level.

If you want to discuss where there are opportunities to speed up
Squeak that will not mess up the language or it's implementation.

Anthony Hannan's send performance work was rejected even though it
did speed up sends and came with proper block closures. Proper block
closures are something we really should have.

My work on Exupery provided me with the knowledge, and also the
experience of evaluating optimisations but it is my experience with
GemStone, VisualWorks, and IBM Smalltalk that provide my dislike of
the costs of living with such optimisations and cleverness.


Bryce



More information about the Squeak-dev mailing list