What should be in the next release.

[Bryce Kampjes]

Tony Garnock-Jones writes:
 > Bert Freudenberg wrote:
 > > Or are you proposing to have Exupery inline blocks? This would certainly
 > > be possible in precisely the cases where the current compiler issues a
 > > jump byte code instead of full block
 > 
 > Yes, this is what I'm hoping Exupery will do.

What you want for that is full method inlining. That's not what I'm
talking about doing next. It's a very good optimisation for Smalltalk
like languages. It will bring enough code and loops into one big
inlined method to give a classical optimiser something to optimise.

There are two separate questions here: 
 1) Should Exupery optimise sends sufficiently so the interpreters 
    inlining isn't needed?  
 2) Should we remove the interpreter's inlining?

My plans are to optimise normal sends enough eventually. There are
many loops that use do: or other constructs that can not be optimised
by the interpreter but could be optimised by dynamic inlining. Dynamic
inlining is also the best way to make common sends nearly free
excluding the type test (which isn't needed for self or super sends).

But I don't think we should remove the interpreter's ifTrue:
optimisation even when Exupery's inlining is good enough. Exupery will
always add more work to porting, being portable is important.  Also
while it's possible to dynamically inline ifTrue: like Self did, it'll
mean the system runs slower until all critical ifTrue:s have been
dynamically inlined, initial speed may be important sometimes.

The ifTrue: inlining is ugly but it provides a lot of speed with a
simple implementation which doesn't cause practical problems. That's
still valuable. In time, Exupery will inline any ifTrue:s that are
left but having good performance without Exupery will still be
important.

Bryce