[squeak-dev] Thoughts about Cog and "tracing" etc

Hi folks!

This post is a just a "heads up" based on some websurfing around VMs and
JITs. I am itching badly to hear Eliot announce some kind of Cog-thingy
- so consider this rambling post to be a symptom of that itch. :)

There are a few things going on in the VM world that most of us have no
clues about. We know about V8 but most may not know about
TraceMonkey/Tamarin and its use of a new technique called "tracing" and
a backing library for it - nanojit.

Evidently TraceMonkey is giving V8 a real run for its money, and AFAICT
this is mainly due to work of Andreas Gal (really interesting long article):

        http://andreasgal.com/2008/08/22/tracing-the-web

And some other:

        http://www.bailopan.net/blog/?p=72

Hot off the press (yesterday):

        http://www.bailopan.net/blog/?p=430

After having read that Eliot does not think LLVM is suitable mainly due
to lack of large basic blocks in Smalltalk code - and he seems to be
looking hard at Factor and its JIT - I just wanted to mention the above
as Yet Another Interesting Bit. I also think that the latest work on Lua
(LuaJIT) includes tracing, not sure though.

So Eliot, how is your work progressing? No pressure, just LOTS of
interest! :)

regards, Göran

PS. Being bored hacking C#...

Hi!

Just dug up their paper on TraceMonkey for PLDI 2009:

        http://blog.mozilla.com/dmandelin/tracemonkey-paper-pldi-2009/

Seemingly a really nice detailed paper!

regards, Göran

2009/6/24 Göran Krampe <[hidden email]>:
> Hi!
>
> Just dug up their paper on TraceMonkey for PLDI 2009:
>
>        http://blog.mozilla.com/dmandelin/tracemonkey-paper-pldi-2009/
>
> Seemingly a really nice detailed paper!
>

Lets wait till they add the resursion & tail call handling. Because
without it, their JIT really sucks on recursive benchs  :)

Or, better, replace a 'loop' as a cornerstone of design, with tail-call :

whileTrue: aBlock
  [ self value ] whileTrue: [ aBlockValue]


;)

> regards, Göran
>



--
Best regards,
Igor Stasenko AKA sig.

Am 25.06.2009 um 10:44 schrieb Igor Stasenko:
> Or, better, replace a 'loop' as a cornerstone of design, with tail-
> call :
>
> whileTrue: aBlock
>  [ self value ] whileTrue: [ aBlockValue]


You mean

whileTrue: aBlock
        self value ifTrue: [
                aBlock value.
                self whileTrue: aBlock]

- Bert -

2009/6/25 Bert Freudenberg <[hidden email]>:
Yes.

> - Bert -
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reading through their papers, while I didn't spend a lot of time studying the matter, I got the sense that the optimization strategies that Self employed would effectively accomplish similar types of optimizations, but arrive at them in a simpler and more general manner.  As for a comparison with v8, I think v8, largely by eliminating bytecode, is a much simpler design and they are very well aware of the Self style optimizations that can be employed to make things go much faster than they do today.  In other words, it's a simple design that already performs well (relative to other JS engines) and has lots of room for improvement.  I only wish they had built the engine itself in a better language than C++.  I'm not sure JavaScript would be a great language for building a VM, but I can think of at least one other language that would have been quite nice. ;)

On Thu, 2009-06-25 at 07:57 -0400, Stephen Pair wrote:
One big advantage of a trace compiler is it doesn't compile whole
methods so may be able to get by with a smaller code cache. While this
probably doesn't matter so much on the desktop or server on some
embedded devices it still will.

Implementing a trace compiler is likely to involve more frequent hooks
than implementing a whole method compiler. With a whole method compiler
only sends and returns need hooks, with a trace compiler at least every
backward jump needs hooks for native code.

I've read some papers on a Java trace compiler that was slower than
their whole method compiler but used much less memory.

It's an interesting way of getting type feedback with different trade
offs to entire method compilers.

Bryce