gmane.comp.lang.smalltalk.exupery

Re: Papers that inspire Exupery

Bryce Kampjes — 2010-07-06T21:34:44

Hmm, it is. I'll need to investigate.


Bytecode dispatch performance changes depending on what CPU you're
using. The Pentium 4's were the worst given how fast they were and how
badly they suffered from branch misspredicts. Later CPUs optimize for
branch prediction much more and so will suffer from the dispatch
overhead less.

Also stack bytecode is likely to be more compact with a decent encoding
which will reduce the amount of time spent fetching bytecode into the
CPU's caches.

I've noticed that the difference in performance of Exupery compared with
the bytecode interpreter changes wildly depending on the CPU. Exupery is
fasted compared with the bytecode interpreter on the P4 but it's never
been tuned for that CPU because I never owned a machine that used it.


If you can perform an optimization as a simple tree walk then that's
very fast. Exupery does many optimizations that way.

Exupery also does some analysis that's more sophisticated than simple
tree walks. 

Bryce

Re: Papers that inspire Exupery

Mathieu Suen — 2010-07-06T17:02:44


Link of your papers seems broken.



Thanks for your answer I agree that for the point of view of Jit there is no big deal.
But if you stay on the bytecode level then having some #sendArgTemp0: can avoid dispatching the #pushTemp:0  bytecode.

Also have you an idea on what is faster: 
 - Make a small optimization but work throw the tree many time.
 - Make a big optimization and avoiding tree walk

I guess you have some optimization that can't be done in several tree walk?

Re: Papers that inspire Exupery

Bryce Kampjes — 2010-07-05T21:35:22

http://wiki.squeak.org/squeak/5792

The short answer is it's an attempt build on the insights from Holzle's
work on Self compilation and allow type feedback to be used with solid
optimization.

Good inlining and type information through type feedback opens the door
to serious optimization but standard type feedback VMs rely on very fast
compilers which don't have time to optimize well.


My view is the bytecode should be stack based but the JIT register
based. It's easy to do very good register allocation across trees (i.e.
stack based). 

Trees are a convenient structure to work with and a stack based bytecode
is just a linear representation of a tree.

If you're optimizing heavily it doesn't matter too much what
representation you choose as you'll transform it through several
representations during compilation. If you're optimizing quickly and
simply trees are convenient.

Bryce

Papers that inspire Exupery

Mathieu Suen — 2010-07-05T19:15:09

Hi Bryce,

I would like to know if you can provide us a list a papers on Jit.
Anything that inspire/explain what your doing in Exupery.

And also what do you think of stack base VM vs. register base VM?
I am asking because in smalltalk I am wondering if it worth register base VM.

Thanks

Mth









___________________________________________________________________________ 
Yahoo! Mail r

Update on inlining

Bryce Kampjes — 2010-02-07T17:12:08

There's been some progress on Exupery. The current task is inlining
methods that don't create blocks.

The last commit includes the ability to inline methods with arguments.

The remaining tasks are:
 * Accessing the literal frame from an inlined method
 * inlined self references
 * inlined super calls
 * inlined methods with temporaries
 * deoptimising inlined methods
 * updating the profilers to automatically inline methods.

After that it's time to add closure support to Exupery then inline
blocks.

Bryce