Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emscripten, an LLVM-to-JavaScript compiler

github.com

Post reply on HN
Print view View original

11–14 of 14 posts

Re: Emscripten, an LLVM-to-JavaScript compiler

#11

Post by DanWaterworth »

equark wrote: post #5

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. Presuma…

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.

Re: Emscripten, an LLVM-to-JavaScript compiler

#13

Post by ootachi »

equark wrote: post #9
ootachi wrote: post #8

Earlier quoted context omitted.

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…

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.

Re: Emscripten, an LLVM-to-JavaScript compiler

#14

Post by azakai »

equark wrote: post #9
ootachi wrote: post #8

Earlier quoted context omitted.

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…

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

Post reply on HN