[squeak-dev] Re: The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Bryce Kampjes bryce at kampjes.demon.co.uk
Wed Jul 1 20:26:36 UTC 2009


On Wed, 2009-07-01 at 13:57 +0200, Göran Krampe wrote:
> Hi Bryce!
> 
> Bryce Kampjes wrote:
> > On Tue, 2009-06-30 at 00:59 +0200, Göran Krampe wrote:
> >>>     Press at least one good JIT design through to completion
> >>>     document it, and keep it alive on every platform.
> >> I presume Cog is our hope? The latest "news" in this area is that Eliot 
> >> mentioned he is looking closer at the JIT in Factor (factorcode.org) and 
> >> even considers porting it! And lots of JIT libs around these days, 
> >> Nanojit in Tracemonkey, libJIT etc etc.
> >>
> >> But one thing is true - performance *kicks ass*. We may go on and on 
> >> about how "unimportant" performance is but darnit, it really is a killer 
> >> feature if we had a REAL fast VM whupping the Pyhon/Rubys. ;)
> > 
> > Exupery development is still continuing though the rest of this year is
> > likely to be slow but speeding up as the months go by. The current task
> > is dynamically inlining methods.
> 
> I deliberately didn't mention your work because I didn't want to put 
> pressure and since Cog was slated for this summer (I think) I guess Cog 
> may deliver before Exupery starts to deliver in earnest.
> 
> But inlining of methods sounds like it could be a booster, right?

It should be a major gain but more urgently it'll allow me to decide
whether Eliot's stack VMs make sense with Exupery. Dynamic inlining may
remove enough sends so that the extra complexity of the stack VM isn't
justified. Dynamic inlining may also create de-optimisation problems
that are well solved by using the stack VM's context caching.

Implementing dynamic inlining will allow that decision to be informed by
running code. 

Also the last bug fixes have improved reliability enough that starting
work on dynamic inlining is sensible.

Bryce




More information about the Squeak-dev mailing list