6 ms·
LLV8 – An experimental top-tier compiler for V8
- hackcasual 10y agoAny 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
- JoshTriplett 10y agoOr 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.
- ivladak 10y agoWe've got a couple of positive (execution time wise) results here: https://github.com/ispras/llv8/wiki/Current%20state 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).
- corysama 10y agoAm 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.
- chrisseaton 10y agoYes that's what it looks like.
- djsumdog 10y agoI'm not sure how I fell about this. Part of me wants to think it's terrible, but I want to stay objective.
- gravypod 10y agoWell this will be interesting. When are we going to see native binaries written in JS? After that will we see Operating Systems?
- tiles 10y agoThere are experiments in this area: https://node-os.com/ https://node-os.com/
- PeCaN 10y ago“node-os is the first operating system powered by npm” Good God man, this is satire… right? RIGHT?
- chrisseaton 10y agoThe 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.
- bobajeff 10y agoIsn't this kind of like what WebKit was doing with FTLJIT before phasing it out in favor of B3?
- panic 10y agoYep: https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
- cpeterso 10y agoIt 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 https://github.com/kevinmehall/node-llvm (2013) https://github.com/dirk/llvm2 https://github.com/dirk/llvm2 (2015)
- erichocean 10y ago> 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.
- pmarreck 10y agoSince 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.