Similarly, the dart2js numbers are generated by compiling the benchmarks and harness to JavaScript and then running the generated code in V8.
Finally, the V8 numbers are generated using the same benchmarks written in JavaScript and with exactly the same harness rewritten in JavaScript.
From what I'm reading, this appears to suggest that Dart2js isn't faster than V8, but is instead faster than a handwritten code. Still a good achievement!
The reason I bring this up is because I was confused at how javascript (even compiled from Dart) could be faster than the engine that is running it.
Right, they're basically saying that v8(dart2js(code)) is faster than v8(transliterate(code)), i.e. that dart2js is becoming better at optimizing the code for V8 than V8 is by itself.
I can see that Dart definitely has the potential to be faster than Javascript, but at the moment the difficulty of measuring the speed of its implementation is the lack of representative benchmarks. Richards and DeltaBlue aren't exactly ideal.[1]
But it's still encouraging to see such results from its Javascript backend. Ideally we'd be able to experience the productivity gains of Dart without having to introduce an entirely new browser VM.
Surely Richards and DeltaBlue are not ideal. Honestly I don't think there is such thing as an ideal benchmark. However both Richards and DeltaBlue capture performance aspects of language features that are used by absolutely any object oriented program: cost of method calls, polymorphism, field accesses, etc.
We are definitely looking into publishing more benchmarks on this page. In the meantime feel free to benchmark Dart yourself and report any performance issues.
On the server-side, a few people on the Dart mailing list have started messing around with competing in some server-side benchmarks done by the Debian [1]. Dart isn't exactly doing well so far, but the submission have been written by people that aren't as familiar with Dart yet and how to get apps running quickly on the DartVM. I'm still working on improving my submission to see how much faster I can get it.
• "dart" means "handwritten Dart running in the Dart VM"
• "v8" means "handwritten JavaScript running in V8"
• "dart2js" means "dart2js-generated JavaScript running in V8"
I can't find any link to the actual handwritten JavaScript (or the handwritten Dart) that these benchmarks are based on. Without this, it's impossible to know the value of these numbers.
Maybe the handwritten JavaScript is written really badly. Maybe the procedure performed by the respective languages is something that dart2js is particularly good at optimising. Who knows.
It seems disappointing that the Dart VM is slower than both JS and dart2js, when Google justifications for creating Dart instead of working to extend JS was that Dart could be faster than JS could be.
Dart VM is the fastest, followed by dart2js then V8. The key thing to remember is that this is a time-series chart. So you have to look at the right hand side where dart2js just overtook V8.
Those graphs show the opposite. DartVM is the fastest among the three "dart, js, dart2js", then comes Dart2js due to highly optimizable generated code, then handwritten javascript
It's interesting to some of the reasons Dart can be faster http://highscalability.com/blog/2013/3/20/dart-is-it-the-fut... However, this is a welcome side effect to me. Rather, I am more productive in writing working code in Dart because of the higher level nature of the tool set. Less pain, more gain.
None of the other browsers have any plans of implementing support for Dart. I don't see any point in getting excited about yet another language which compiles to javascript.
Everyone wants to replace Javascript, but this seems to be another opportunity for reposting the worse is better article.
You're missing the point, which is about the speed of JavaScript. No one in the Dart community I read is even talking about getting the Dart VM on other browsers. As far as I'm concerned, it's a development platform. The "Yeah but no other vendors are going to implement the Dart VM" might not be an accurate prediction and has become a hackneyed way to dismiss Dart.
Getting a dart VM implemented in browsers is a bonus, not the end goal. The fact that dart2js is being improved should indicate this.
Dart isn't "yet another" compile-to-js solution. It's the most fully fledged one. Coffeescript is just a loose set of macros that still looks and smells like javascript. Typescript is just statically typed javascript. Dart is a fully-fledged language with its own complete IDE and a lot of new trendy features.
I love the idea of Dart, and was hoping for this to happen (makes sense it would). My biggest problem with Dart today is it's lacking support for Internet Explorer 7.
dart2js currently targets IE9 and above but I'm thinking that a shim could be written for older browsers. I've haven't investigated this because I haven't needed it, but it should be possible.
you're free to do any choice you want... but this reasoning seems flawed to me:
Go and Dart are open source and written by Google
V8 is open source and written by Google
maybe you meant: "I don't know if Dart will be maintained in the long term, so I'll avoid it for now"
[+] [-] testing12341234|13 years ago|reply
Similarly, the dart2js numbers are generated by compiling the benchmarks and harness to JavaScript and then running the generated code in V8.
Finally, the V8 numbers are generated using the same benchmarks written in JavaScript and with exactly the same harness rewritten in JavaScript.
From what I'm reading, this appears to suggest that Dart2js isn't faster than V8, but is instead faster than a handwritten code. Still a good achievement!
The reason I bring this up is because I was confused at how javascript (even compiled from Dart) could be faster than the engine that is running it.
[+] [-] drostie|13 years ago|reply
[+] [-] lvivski|13 years ago|reply
[+] [-] kibwen|13 years ago|reply
But it's still encouraging to see such results from its Javascript backend. Ideally we'd be able to experience the productivity gains of Dart without having to introduce an entirely new browser VM.
[1] https://blog.mozilla.org/nnethercote/2012/08/24/octane-minus...
[+] [-] mraleph|13 years ago|reply
Surely Richards and DeltaBlue are not ideal. Honestly I don't think there is such thing as an ideal benchmark. However both Richards and DeltaBlue capture performance aspects of language features that are used by absolutely any object oriented program: cost of method calls, polymorphism, field accesses, etc.
We are definitely looking into publishing more benchmarks on this page. In the meantime feel free to benchmark Dart yourself and report any performance issues.
[+] [-] kyrra|13 years ago|reply
[1] http://benchmarksgame.alioth.debian.org/u64q/performance.php...
[+] [-] igouy|13 years ago|reply
I didn't find anything on the blog page you linked to that talks about why Richards or DeltaBlue are or are not ideal.
[+] [-] callum85|13 years ago|reply
• "dart" means "handwritten Dart running in the Dart VM"
• "v8" means "handwritten JavaScript running in V8"
• "dart2js" means "dart2js-generated JavaScript running in V8"
I can't find any link to the actual handwritten JavaScript (or the handwritten Dart) that these benchmarks are based on. Without this, it's impossible to know the value of these numbers.
Maybe the handwritten JavaScript is written really badly. Maybe the procedure performed by the respective languages is something that dart2js is particularly good at optimising. Who knows.
[+] [-] timothya|13 years ago|reply
The JavaScript version is part of the Octane Web Benchmark. The DeltaBlue component is here: https://code.google.com/p/octane-benchmark/source/browse/lat...
The Dart version of DeltaBlue is here: https://github.com/dart-lang/benchmark_harness/blob/master/e...
[+] [-] simonster|13 years ago|reply
[+] [-] rayiner|13 years ago|reply
[+] [-] robmcm|13 years ago|reply
DartVM is almost twice as fast :)
dart(20315)512.24
dart2js(20315)334.67
v8(14027)321.00
[+] [-] lvivski|13 years ago|reply
[+] [-] michaelwww|13 years ago|reply
[+] [-] Expez|13 years ago|reply
Everyone wants to replace Javascript, but this seems to be another opportunity for reposting the worse is better article.
[+] [-] michaelwww|13 years ago|reply
[+] [-] ryeguy|13 years ago|reply
Dart isn't "yet another" compile-to-js solution. It's the most fully fledged one. Coffeescript is just a loose set of macros that still looks and smells like javascript. Typescript is just statically typed javascript. Dart is a fully-fledged language with its own complete IDE and a lot of new trendy features.
[+] [-] Raphael_Amiard|13 years ago|reply
"The score is essentially runs/second: the number of times you can run the benchmark in one second. For all scores, bigger is better"
So, no, dart2js is actually slower than hand written javascript code, which is in turn slower than dart code running on the dart VM.
EDIT : I got it all wrong, sorry, didn't see the far end of the graph.
[+] [-] berdario|13 years ago|reply
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] unknown|13 years ago|reply
[deleted]
[+] [-] nixarn|13 years ago|reply
[+] [-] michaelwww|13 years ago|reply
[+] [-] johnx123-up|13 years ago|reply
[+] [-] mraleph|13 years ago|reply
[+] [-] Jaitls|13 years ago|reply
[+] [-] unhe|13 years ago|reply
[+] [-] EvanYou|13 years ago|reply
[+] [-] berdario|13 years ago|reply
maybe you meant: "I don't know if Dart will be maintained in the long term, so I'll avoid it for now"
[+] [-] beatgammit|13 years ago|reply
Also, on some of my benchmarks, Go is faster than some other compiled languages (like D) and can be more memory efficient than Java: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
It's certainly not being "left behind", it's just new.
[+] [-] lgunsch|13 years ago|reply