Emscripten, an LLVM-to-JavaScript compiler(github.com)
github.com
Emscripten, an LLVM-to-JavaScript compiler
https://github.com/kripken/emscripten
6 comments
Previous discussions: http://news.ycombinator.com/item?id=1644192 http://news.ycombinator.com/item?id=2428723 http://news.ycombinator.com/item?id=2600890
GHC 7 can use LLVM as a backend. That might allow generation of JavaScript code from Haskell. There's already ghcjs (https://github.com/sviperll/ghcjs), but the output from that is quite verbose from what I've seen so far.
Update: For OS X you need GHC 7.2 to use the LLVM backend. Otherwise GHC just ignores the -fllvm flag. The Haskell Platform only uses version 7.0.4.
Update: For OS X you need GHC 7.2 to use the LLVM backend. Otherwise GHC just ignores the -fllvm flag. The Haskell Platform only uses version 7.0.4.
Description of how LLVM works from The Architecture of Open Source Applications: http://www.aosabook.org/en/llvm.html
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.
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.
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/ , but I wouldn't expect great performance.
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/ , but I wouldn't expect great performance.
Are you talking about C++ overloading? That's static, so tracing won't buy you anything.
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
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.
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.
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! :)
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! :)
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.
If emscripten could run in the browser, we'd have a js-only alternative to PNaCl.
is this what the repl.it uses?