[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: State of JIT compiler
From: |
leledumbo |
Subject: |
Re: State of JIT compiler |
Date: |
Tue, 22 Feb 2011 19:05:44 -0800 (PST) |
> But it's great you're interested in implementing this. Notice I'm replying
on the maintainers' mailing list. What help can we
> offer to get you started?
List of files containing the tree-walker code, that's all for a starting
point. We'll see what I need in the future.
> If I was attacking this project I'd look at the SVN of freemat in
> sourceforge and see what code can be stolen from there.
> Freemat includes a c++ wrapper for llvm to create some classes useful to
> jit the matlab language and then some more code
> for the glue to the parser. We can probably steal the first but would have
> to rewrite the second
Why not? Is FreeMat's license incompatible with Octave or what?
> Almost all of the previous discussion has been focused on going the LLVM
> route; that is, tackling the monster that is static
> type inference. However, a couple of the threads touch on a newer method
> without actually giving the name: tracing JIT (or
> trace-based JIT). As far as I understand it, the idea is to allow the
> interpreter to run as normal until it finds a block of code
> that is run multiple times on the same path, compiling that chunk, and
> using that to speed up execution. When it exits the
> block -- whether it's the end of the loop or just a conditional jump that
> doesn't usually occur -- it goes back to the interpreter.
> No type inference would be needed because the interpreter would *tell* the
> compiler what the types are.
Hmm...I never heard of trace-based JIT, but instead of half-JIT like this,
I'd rather choose full JIT.
--
View this message in context:
http://octave.1599824.n4.nabble.com/State-of-JIT-compiler-tp3319772p3320449.html
Sent from the Octave - General mailing list archive at Nabble.com.