|
|
|
|
|
|
by bcantrill
5002 days ago
|
|
|
Brendan, I appreciate the thoughtful reply. I think the only reason for my criticism (and the word "disrespectful" was too harsh -- I should have left it at "annoying") was that your last slide ("Always bet on JS") implies (to me, anyway) that JavaScript's high performance is its manifest destiny. And that, to me, understates the contribution of V8: the high performance of JavaScript was not a foregone conclusion; it required guts, innovation and hard work. As for the assertion that a trace-based JIT beat V8 to market, a trace-based JIT also has well-known failings, so it's not a terribly meaningful data point -- other than that it speaks to the aspirations perhaps for a higher performing JavaScript. But we clearly agree that Lars and team developed a terrific VM in V8, and that V8 was important in the history of JavaScript -- which was my only point. |
|
|
The chosen measure of these new VMs was a set of benchmarks, SunSpider from Apple and the V8 Benchmarks from Google. While V8 had the best GC and most optimizations, on these suites at least, for about two weeks for TraceMonkey (and longer for SFX), V8 was not that far ahead.
You can find the charts via Google still.
V8 had the longest lead time, not just working on what was released with Chrome but trying other approaches first, learning from them, and starting over. That's huge and it has paid off well.
But I don't agree that any architectural failing of one VM counts more than public, reproducible benchmark scores. Even V8 had to do Crankshaft.
Architectures evolve and supersede one another, but the developer and user benefit -- the public benefit -- comes from the competition. V8 was not alone in driving competition.