Emscripten, an LLVM-to-JavaScript compiler | Hacker News Reader

Emscripten, an LLVM-to-JavaScript compiler

github.com

81 pointsfredoliveira13 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.

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.

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.

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.

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! :)

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.

If emscripten could run in the browser, we'd have a js-only alternative to PNaCl.

is 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...

repl.it uses Emscripten for Python, Ruby and Lua. The other languages are not compiled into JS (they are handwritten).

Reply on news.ycombinator.com