Ergus <spacibba@aol.com> writes:
More importantly, the libJIT build failed to show any significant
speed-up wrt byte code, so it sounds like maybe the whole idea was
either wrong or its design couldn't possibly provide any gains. Or
maybe we just measured the speed-up in wrong scenarios.
This is not surprising. My work is 80% performance measurement and
benchmarking and the real improvements with JIT compilation (in my
experience) and specially with libJIT is not as good as many people
expect in most of the common scenarios. That's because the generated
code is usually very generic (so it does not take advantage of
architecture specific features), and strategies like vectorization and
branch prediction are very difficult to hint (most of the times
impossible). So the only real difference with a bytecode interpreter is
the bytecode parsing part, but not too much more.
On Emacs case, I'm pretty sure whatever advantages comes from good
architecture-specific code, accurate branch prediction, etc are below
the noise level. As you pointed out below, Elisp is a dynamic language
and for turning this
(let ((acc 0))
(dotimes (i 10)
(setq acc (+ acc (foo i)))))
into this
int acc = 0;
for(int i = 0; i < 10; ++i) {
acc += foo(i);
}
you need either sophisticated analysis (that, in practice, only works
for the "easy" cases) or annotate the code with type declarations (and
enforce then).
Because otherwise handling variables as containers for generic values is
incompatible with "C-like" performance.
And an Elisp -> C translator does not magically solve this.