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.
So there could be some difference between the original code in both, and some benefit from compiling to js (e.g. they could use crazy tricks similar to asm.js to generate faster code perhaps based on type hints present in Dart but not the JS)
Which shouldn't really come as much of a surprise since dart is a higher-level language. That way the higher-level code can be optimised, and then the output JS can be optimised.
Yeah, and in that sense it's unsurprising - witness how v8 is still typically much, much slower than native C - but emscriptem does surprisingly well.
Essentially, no human word use unhandy, verbose, hard to read syntax whereas a compiler might. Thus in practice the JS subset that handwritten code uses is different from that of compiler generated code.
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.
Exactly. The DartVM isn't in Chrome yet and may not be for a while. When you ask people on the Dart team when the DartVM will be integrated into Chrome, you don't get any kind of real answer. The best I've seen them say is that once Dart hits 1.0 (scheduled for this summer), they will start worrying about getting the DartVM into Chrome. But no promises or timelines.
The Dart team has realized that selling people on the DartVM will be hard, so they are putting a lot of effort into dart2js.
(note: yes yes, there are chromium builds that include the DartVM, but it is not officially part of Chrome yet).
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"
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.