LLV8 – An experimental top-tier compiler for V8 | Hacker News Reader

LLV8 – An experimental top-tier compiler for V8

github.com

96 pointsJarlakxen19 comments

Am I reading this right? This seems to be an alternate V8 with a slower JIT startup but faster JITted results for situations like running a Node server for weeks at a time as opposed to popping around between web sites in Chrome.

Yes that's what it looks like.

Any execution or compilation time benchmarks? I'd expect LLV8 to be much slower than TurboFan for native codegen, but if the runtime benefits are greater, this might be a good fit for server side JS applications

Or for long-running JavaScript components. V8 doesn't optimize code with TurboFan right away; it does it for hotspot functions that look optimizable.

This would especially make sense along with an "optimized cocde cache": cache pre-compiled optimized versions of JavaScript, such as common JavaScript libraries, based on hash.

We've got a couple of positive (execution time wise) results here: https://github.com/ispras/llv8/wiki/Current%20state. Relative to Crankshaft rather than TurboFan, though. Compilation indeed takes much longer at the moment (compared both with TF and CS).

Isn't this kind of like what WebKit was doing with FTLJIT before phasing it out in favor of B3?

Yep: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/

It would be interesting to see JavaScript bindings to the LLVM back-end so people could write new compiler front-ends in JavaScript. I see now that JavaScript bindings do exist but are not maintained:

https://github.com/kevinmehall/node-llvm (2013)

https://github.com/dirk/llvm2 (2015)

> I see now that JavaScript bindings do exist but are not maintained

That's partially because the amount of API churn for LLVM and for native Node.js bindings is high. It's actually a lot of work to keep up with LLVM in particular.

Since JavaScript is largely considered a terrible language by anyone who's spent enough time with various languages, I'm mostly looking forward to the impact this might have on other arguably better languages that "compile to JS" such as Elm.

Well this will be interesting. When are we going to see native binaries written in JS? After that will we see Operating Systems?

There are experiments in this area: https://node-os.com/

The code shown in this project's readme wouldn't work statically - can you see all the deoptimisation points in the generated code? It can only be made so fast because it has the option to bail out to the interpreter at any point.

V8 doesn't have an interpreter, so it doesn't bail out to one. It certainly bails out to its baseline compiler, though!

FYI http://v8project.blogspot.com/2016/08/firing-up-ignition-int...

Right—there's one coming, but it's not there yet.

Can you elaborate at what you mean here? I don't see where this interpreter is implemented.

As gsnedders pointed out it is actually a template compiler rather than an interpreter at the moment.

I'm not sure how I fell about this. Part of me wants to think it's terrible, but I want to stay objective.

Reply on news.ycombinator.com