by andreyvit on 2/12/14, 3:36 PM with 58 comments
by cliffbean on 2/12/14, 5:14 PM
"Consistent performance. (not like the V8 engine pausing the whole application for GC)"
Static complication doesn't get you out of having to worry about memory management. What's the alternative here? Reference counting? Leaking everything? Using a subset of JS that doesn't allocate anything? All of these things come with considerable costs.
by a-priori on 2/12/14, 4:59 PM
The next step would be to swap out the existing Javascript runtimes with this frontend plus a sandboxed backend for the native platform so they can compile Javascript to LLVM bytecode, then to native code.
Finally, you add an extension to the <script> tag to allow loading arbitrary LLVM bytecode, something like <script src="http://some/url/code.llvm" type="text/llvm">.
Once that's in place then you'd be able to execute any language that has an LLVM front end inside the browser environment. Javascript is no longer the sole language of the web, and things like Emscripten and asm.js become obsolete.
by jvilk on 2/12/14, 5:24 PM
> - Consistent performance.
> (not like the V8 engine pausing the whole application for GC)
But... you're still going to need garbage collection, unless you are only planning on supporting something like ASM.js. So there will still be application pauses for GC.
Also, you mention that you have support for JavaScript OO, but I notice the benchmarks don't exercise programmer-defined JavaScript objects/prototypes. Do you have numbers on its OO performance, or is that still something you're working on?
Finally, how do you handle type inference at the LLVM level? I assume you implemented some form of JIT compilation? I'd be interested to hear more!
by pjmlp on 2/12/14, 4:37 PM
by jmgrosen on 2/12/14, 5:04 PM
by azakai on 2/12/14, 7:27 PM
This is not accurate, and shows a lack of respect for the JS VM developers at other browser vendors.
Very close to the time v8 was launched, SquirrelFish Extreme from Apple and TraceMonkey from Mozilla were also launched, each far faster than previous JS VMs, beat v8 on various benchmarks while losing on others, etc.
Since then v8 has generally been in the lead, certainly, but not always, and it would depend on the benchmark and platform.
So it is not fair to say - and this is not the first time I see it, or else I would not write this comment - that v8 is single-handedly responsible for JS being fast today.
by cpeterso on 2/12/14, 7:15 PM
by TheMakeA on 2/12/14, 5:52 PM
by andreyvit on 2/12/14, 3:38 PM
by ahoge on 2/12/14, 4:12 PM
by moisy on 2/12/14, 4:34 PM
by conanobre on 2/12/14, 5:51 PM