5 ms·

Is there a tracing JIT that has been compiled on top of this? It would be interesting if inherent problems with Javascript as a target language could be partia

by equark 15y ago

Is there a tracing JIT that has been compiled on top of this? It would be interesting if inherent problems with Javascript as a target language could be partially avoided by implementing a tracing Javascript JIT on top of Javascript. For instance, the simplest source-to-source transformation for operator overloading is to use function calls for all operators. But this degrades performance for the Number type. Presumably a tracing JIT could switch to native Javascript operators after observing hotspots that only use Numbers.

ootachi 15y ago
Are you talking about C++ overloading? That's static, so tracing won't buy you anything.
- 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 ago
    In 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 ago
    I 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! :)
DanWaterworth 15y ago
No, and there couldn't realistically be one either. JITs compile to native machine code, but this is transforming LLVM IR, a typed assembly language. It might be possible with http://bellard.org/jslinux/ http://bellard.org/jslinux/ , but I wouldn't expect great performance.

by equark 15y ago

ootachi 15y ago

Are you talking about C++ overloading? That's static, so tracing won't buy you anything.

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 ago
  In 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 ago
  I 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! :)

DanWaterworth 15y ago

No, and there couldn't realistically be one either. JITs compile to native machine code, but this is transforming LLVM IR, a typed assembly language. It might be possible with http://bellard.org/jslinux/ http://bellard.org/jslinux/ , but I wouldn't expect great performance.