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

Bryce Kampjes bryce at kampjes.demon.co.uk
Sat Sep 16 22:10:00 UTC 2006


Klaus D. Witzel writes:
 > Hi Bryce,
 > 
 > I hope we both are now tired enough from your comparision of Exupery to  
 > the proposed primitiveApplyToFromTo.

I am tired of this argument but I would appreciate it if you would
try respond to my arguments.

My main issue is your change makes the system more complex in a
visible way to everybody. Both normal programmers looking at their
calls to do: in walk backs and to people working in the VM. 

I am not comparing your primitiveApplyToFromTo primitive to
Exupery. 1% to 15% extra cost to sends was calculated against the
interpreter now, not Exupery now, and definitely not what I think it
could be. I did not provide the numbers for how much those additions
to common send would provide for Exupery now, or potentially in the
future but they should be easy to work out (hint multiply by 2 to 4).
I even told you what it would take to avoid both Exupery and an
unpatched VM from incurring a performance cost when executing your
shadow over a standard shadow.

That cost is a language change. The code change is trivial, just find
the check that stops the byte code compiler from compiling an
assignment to an argument and delete it. The restriction against
changing an argument is not in either the VM or in Exupery. It is a
language choice implemented at a higher level.

Yes, I do end up chasing bugs across both commonSend and commonReturn
code too regularly. Yes, I have found a few of my own bugs due to
subtleties in it involving both GCs and Squeak interrupts. The
additions to commonSend and commonReturn adds extra complexity to an
already dangerously complex area.
 
 > You have not shown a convincing argument, in the sense that any other  
 > primitive has to be (and always was) treated the same way by the VM and  
 > undergoes the same performance penalties under the various CPUs. When we  
 > would believe you, only primitiveApplyToFromTo would slow down the CPU,  
 > the existing primitives wouldn't do that.

Do you feel that simplicity and personal mastery are not important for
a system like Squeak? Your change reduces both.

I am asking you to justify loss of clarity and simplicity inside the
the image that will be seen to normal non VM programmers.

I am also asking you to provide a case for an optimisation. An
optimisation that adds overhead to a critical part of the system:
message sends and all returns. To justify the optimisation you need to
prove that it gains more than it looses. 

Now, may be, you consider the request that you provide a proof that your
optimisation does not lead to a loss of performance for real programs
as unreasonable. I however feel that optimisations must lead to a net
improvement that is worth more than their ongoing costs. Proving that
an optimisation will not lead to a net loss in real use, without
Exupery, can not be an unreasonable request.

I am not asking you prove that this primitive is worth the cost of
development. Merely that it provides enough of a speed improvement to
cover the costs of living with it.

 > Of course you are absolutely correct by pointing with your finger to the  
 > additional instructions performed in #commonSend and #commonReturn and to  
 > the apparent incompatibility of proposed primitiveApplyToFromTo with  
 > Exupery's compiling technique (I took your words for granted, I'm not  
 > working with Exupery but with the standard VMMaker classes to which  
 > primitiveApplyToFromTo is not incompatible).

Exupery will survive in a system with primitiveApplyToFromTo. It will
just not compile your shadow method. But this is irrelevant for why
this primitive is inappropriate to be added to the VM.

The numbers I chose to use were for interpreted code, not native
compiled code. OK, I did give Exupery's numbers as well and the
figures for VisualWorks.

 > Your arguing for the status quo is way too conservative for a living  
 > community, there was a reason why people asked for speeding up enumeration  
 > of collections and also why it was suggested to consider the IBM approach  
 > #apply:from:to:.

It was an idle discussion asking for reasons. A newbie rightfully
wanted to know why it was implemented as it was. At the moment we
don't know. We don't know that a count: implementation of
occurencesOf: would be too slow. 

There are very good reasons for being conservative with the VM. Many
people depend on it who are not VM hackers. It has an awkward release
schedule. VM bugs are a right pain.

Bryce

P.S. And yes, I could outline where Exupery is weak for executing
do:. But improving Exupery's do performance does not look like it will
improve either of the large benchmarks I'm working with. Improving #do
performance does not look currently like it will improve Exupery's
practicality.

P.P.S If non-VM hackers would like to contribute either to Exupery's
development or to Squeak's performance then working on developing a
better benchmark suite would be useful. Both benchmarks and the
argument for why they matter are important.



More information about the Squeak-dev mailing list