

Emscripten, an LLVM-to-JavaScript compiler - fredoliveira
https://github.com/kripken/emscripten

======
Xuzz
Previous discussions: <http://news.ycombinator.com/item?id=1644192>
<http://news.ycombinator.com/item?id=2428723>
<http://news.ycombinator.com/item?id=2600890>

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

------
Mvandenbergh
Description of how LLVM works from The Architecture of Open Source
Applications: <http://www.aosabook.org/en/llvm.html>

------
equark
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
Are you talking about C++ overloading? That's static, so tracing won't buy you
anything.

~~~
equark
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.

~~~
azakai
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
If emscripten could run in the browser, we'd have a js-only alternative to
PNaCl.

------
veyron
is this what the repl.it uses?

~~~
cyrus_
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...

