4 ms·
I'm talking about dynamic languages. This performance penalty is a reason why CoffeeScript has rejected adding an operator overloading mechanism: https://gith
by equark 15y ago
I'm talking about dynamic languages. This performance penalty is a reason why CoffeeScript has rejected adding an operator overloading mechanism:
https://github.com/jashkenas/coffee-script/issues/846 https://github.com/jashkenas/coffee-script/issues/846
But the question is whether a tracing JIT could largely eliminate this bottleneck by noticing if inner loops are really Numeric types. I was wondering if there were any LLVM examples that show potential performance of a JIT on a JIT.
- ootachi 15y agoIn theory yes, but LLVM isn't the answer. LLVM knows nothing about the semantics of the language you're compiling on that level. What you're talking about is eliminating boxing and type guards, which require a higher-level optimization framework than what LLVM provides.
- azakai 15y agoI am not aware of any work of JITs on JITs. But I agree there is a lot of potential there. One thing I would like to see done is to take PyPy or LuaJIT, and get their tracing JITs to generate JS, either directly or more likely indirectly by emitting LLVM which Emscripten then compiles to JS. In theory that could let PyPy and LuaJIT run on the web with speed similar to what they have natively. If anyone familiar with PyPy or LuaJIT wants to work on this with me (I wrote Emscripten), let me know! :)