On Thu, 2007-08-16 at 11:05 -0700, Taras Glek wrote:

> > The question is: why would you do this? Why not just generate
> > C (or C++ as Felix does) and compile it to a shared library,
> > then link and execute it? 
> >   
> Because that would be bloody slow and depend on having a toolchain 
> installed? For a JIT you want a fast compiler that only compiles as 
> little as is needed.

Yes, it does depend on having a tool. Slow? No, not really:
[AMD64 2300 1G]:

(includes parsing the file)
skaller@rosella:/work/felix/svn/felix/felix/trunk$ time f hello
Hello World

real    0m2.073s
user    0m1.972s
sys     0m0.084s

(using cached parse)
skaller@rosella:/work/felix/svn/felix/felix/trunk$ time f hello
Hello World

real    0m1.026s
user    0m0.908s
sys     0m0.100s


(using cached binary)
skaller@rosella:/work/felix/svn/felix/felix/trunk$ time flx hello
Hello World

real    0m0.039s
user    0m0.016s
sys     0m0.012s

I suspect this is actually faster than any JIT, and there's
no question it is faster if the program is reused.

Don't forget: a program has to be compiled one way or the other.
Even Python is compiled to bytecode.  The tool above (Felix)
is better than a JIT because it does whole program optimisation,
generates machine binaries.

So I don't buy 'slow' as an argument: the technique is much
FASTER than any JIT system in all aspects, in fact it IS
a JIT compiler -- it just compiles the whole program all the
way from source with disk based caching which persists over
invocations.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net