[Vm-dev] Interpreter>>isContextHeader: optimization

[bryce at kampjes.demon.co.uk]

Eliot Miranda writes:
 >  On Sun, Feb 22, 2009 at 12:54 PM, <bryce at kampjes.demon.co.uk> wrote:
 > > All you need is the optimiser to run early in compilation for it to be
 > > portable.
 > 
 > 
 > ...and for it to be untimely.  An adaptive optimizer by definition needs to
 > be running intermittently all the time.  It optimizes what is happening now,
 > not what happened at start-up.

Exupery runs as a Smalltalk background thread, it already uses dynamic
feed back to inline some primitives including #at: and #at:put. 

 > > I see only one sixth of the time going into context creation for the
 > > send benchmark which is about as send heavy as you can get. That's
 > > running native code at about twice Squeak's speed. Also there's still
 > > plenty of inefficiency in Exupery's call return sequences.
 > 
 > 
 > So you could get a 17% speedup if you could remove the context overhead.
 >  That's quite a tidy gain.  I see a 26% increase in benchFib performance
 > between base Squeak and the StackVM with no native code at all.
 > 
 > What are the inefficiences in Exupery's call return sequences?

Exupery uses a C call sequence so it's easy to enter from the
interpreter, that C call frame is torn down when exiting each
compiled method then re-created when reentering native code. That's
a complete waste when going from one native method to another.

Also the send/return sequence isn't yet that optimised, there's still
plenty of inefficiencies due to lack of addressing modes etc and because
it's fairly naive translation of the interpreters send code.

17% would be rather optimistic, some of the work required to set up a
context will always be required. Temporaries will still need to be
nilled out etc.

Bryce