On Tue, 2010-07-06 at 19:02 +0200, Mathieu Suen wrote:

On Jul 5, 2010, at 11:35 PM, Bryce Kampjes wrote:

...

On Mon, 2010-07-05 at 21:15 +0200, Mathieu Suen wrote:

...

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.

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

Link of your papers seems broken.

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

...

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.

...

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.

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.

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.

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.

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?

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