On 15.11.2012 04:32, Kevin Kofler wrote:
Unlike the others, it generates the native code at runtime (Just In Time), so there is a performance penalty (especially for nontrivial programs) for the (JIT) compilation which gcc and ocamlopt won't have. The quality of the generated code could also be a problem (for nonempty programs): Optimized compilation takes time! So there's a tradeoff between the time of the JIT compilation and the time of the actual execution, a very fast JIT is not necessarily optimal because it may be missing important optimizations of the compiled code.
All above is correct, with the small nuance that all practically significant slowdowns are always result of repeatable code paths (loops, recursions, etc) but these lands to near optimal native code after the first few iterations with this concrete implementation (Mike Pall is well known with his in-depth theoretical background).
In other words: Try nontrivial benchmarks before claiming victory.
I am. Check GSL shell for example. Nobody claims any victories (especially against gcc). The point is, that this concrete JIT is probably the fastest existing one and brings bunch of advantages at the cost of negligible footprint (compared with v8 for example).
Have you played with LuaJIT apps already ... or speaking from common sense POV ?
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
