Emscripten, an LLVM-to-JavaScript compiler
1–10 of 14 posts
Re: Emscripten, an LLVM-to-JavaScript compiler
#2is this what the repl.it uses?
Re: Emscripten, an LLVM-to-JavaScript compiler
#3is this what the repl.it uses?
yes, I believe so. curious now about whether they could compile clang/llvm itself using emscripten and then pull the whole compilation stack for C into the browser...
Re: Emscripten, an LLVM-to-JavaScript compiler
#4Re: Emscripten, an LLVM-to-JavaScript compiler
#5Is 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.
Re: Emscripten, an LLVM-to-JavaScript compiler
#6Description of how LLVM works from The Architecture of Open Source Applications: http://www.aosabook.org/en/llvm.html
Re: Emscripten, an LLVM-to-JavaScript compiler
#7is this what the repl.it uses?
repl.it uses Emscripten for Python, Ruby and Lua. The other languages are not compiled into JS (they are handwritten).
Re: Emscripten, an LLVM-to-JavaScript compiler
#8Is 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. Presuma…
Are you talking about C++ overloading? That's static, so tracing won't buy you anything.
Re: Emscripten, an LLVM-to-JavaScript compiler
#9Is 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. Presuma…
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.
Re: Emscripten, an LLVM-to-JavaScript compiler
#10GHC 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.