Andreas Raab writes:
 > J J wrote:
 > >> No. First, Exupery is not a JIT.
 > > 
 > > I had been told it was.  In this list actually.
 > 
 > Yeah, it's quite confusing actually. I found the statement that 
 > "[Exupery is] a "JIT" for Squeak that doesn't compile just in time" 
 > which (to me) makes no sense as "JIT" stands for "just in time" so how 
 > could a JIT not compile just in time? ;-)

When Exupery is running in a background thread a user shouldn't
notice that it's not a "real" JIT. So calling it a JIT is fair.

It does not stop execution to compile like the VisualWorks VM does.
This means it must fall back to the interpreter if compiled code
doesn't exist. It can't compile "just" in time. It can compile just
afterwards though.


I'll write an up to date overview of what Exupery is, what it plans to
be, and what it does now soon. Either before or just after the next
release.

All that's left to do before releasing is implement the two primitives
#new and #@ then fix some bugs. The two primitives are required for
the largeExplorers benchmark.

Here's the current benchmarks.

  arithmaticLoopBenchmark 1395 compiled   91 ratio: 15.330
  bytecodeBenchmark       2132 compiled  456 ratio:  4.675
  sendBenchmark           1588 compiled  684 ratio:  2.322
  doLoopsBenchmark        1086 compiled  649 ratio:  1.673
  largeExplorers           337 compiled  366 ratio:  0.921
  compilerBenchmark        794 compiled  767 ratio:  1.035
  Cumulative Time         4241 compiled 1389 ratio   3.053

The most interesting benchmarks now are largeExplores (opening a very
large explorer) and compilerBenchmark (compiling a large method into
bytecodes). Both are real uses. Both use a profiler to choose methods
to compile then PIC based type feedback to inline primitives.

largeExplorers needs a faster #@. The interpreter inlines this into a
bytecode while Exupery is currently doing a full message send. Once
it's implemented as a compiled primitive it will then get inlined
automatically.

compilerBenchmark is spending 5% of it's time in compiled code and
support routines. That provides a 3.5% gain. Better profiling may help
by compiling more methods. I haven't looked at the profiler since the
last optimisation.  So would a little tuning, 1% of the time (out of
5% in compiled code) is spent building the new context during a
message send, most of that time could be saved.  It is however
producing a performance gain. Which is enough to make bug fixing the
priority again.

The list of things to do before a 1.0 is here:

 http://minnow.cc.gatech.edu/squeak/5793

Nothing on it is hard or risks destabilising things.

Bryce