Where is the "Works better on Google Chrome" badge?
I haven't seen anything about Dart (the big win would be eliminating the really slow DOM "GC" cycles on the webkit/blink side of things), but it would be interesting if this opened the way for easier VM integration. My understanding was that post-webkit they were tying v8 deeper into blink, though, not allowing more flexibility...
When Google starts shipping the Dart VM, then it will be a different story, of course. It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything (which would not be the case if Google shipped the Dart VM, as it would then be possible, and convenient, to write pages that only worked in Chrome).
> It will still not be comparable to asm.js, because asm.js runs in all browsers without the site author having to do anything
Dart web apps will continue to run in all browsers just as it runs today through Dart2JS, it even has great source maps support which lets you debug native Dart code even though it's running transpiled JS. There's nothing special the "author" would have to do, it already exists as part of the project template, e.g. if the browser has a Dart VM it will run the Dart code natively, otherwise it will run the Dart2JS version. Since some Dart benchmarks http://www.dartlang.org/performance/ show Dart2JS outperforming handwritten JS in V8 even with the overhead of different semantics, I'm assuming that Dart2JS compiles to efficient JS that developers wouldn't write.
> because asm.js runs in all browsers
runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run. The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
Even Firefox ended up reverting a correction fix (deviating from their JS SpiderMonkey VM) in OdinMonkey because it would invalidate its type checker and cause this demo to run with their normal (i.e. unoptimized asm.js) JS engine: https://plus.google.com/111090511249453178320/posts/cr4jTsfx...
So whilst it can in theory technically still run since its "just JavaScript", it can currently be either a broken, or unusable experience if you don't use Firefox.
Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes it using IonMonkey, the exact same pipeline all JS code uses.
> runs is a technically interesting term, there are some asm.js demos that you would not attempt to run without asm.js specific optimizations (i.e. not Firefox) since it would be unusably slow. This is visible in the Epic Citadel http://www.unrealengine.com/html5/ flagship asm.js demo where it needs a Firefox Nightly release to run.
This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
The special interpreter is what I've inferred from pcwalton's comment of their being an optimized interpreter for it in Firefox. If its the same JS VM how can anything fail the type checker (e.g. forgetting a '+' or '|') cause it to run much slower? http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html and if its the same pipeline, how can an asm.js bug have different behavior to normal JS in Firefox? https://plus.google.com/111090511249453178320/posts/cr4jTsfx...
> This is simply false. You can run the Epic Citadel demo in Chrome (dev runs ok on my machine for example) and non-nightly versions of Firefox.
I've got the latest version of Chrome and it always crashes for me: http://imgur.com/Nrsxsdk I've tried it a few times and I've never seen it work in Chrome, It even crashes when I tried it in Dartium (a Chromium based browser shipped with Dart SDK). Though I don't have the dev version of Chrome to try it on.
> It is true that the Epic website recommends Firefox Nightly, that is outdated and it should definitely be removed.
Right, it works in normal Firefox which is what I meant.
P.S. it is good to have 2 from the Mozilla elite here to clarify Firefox internals :)
The type checker either succeeds or fails to type check. If it succeeds, we know all the types and send those with the code to IonMonkey (just like normal code, except with the types). Otherwise, we run it normally, and eventually it will also get sent to IonMonkey (with types inferred at runtime).
So failing to type check can make a difference in performance. It should not be large, and if you look on awfy, on most benchmarks it in fact is not (it is larger on large benchmarks though, which need more attention).
> I've got the latest version of Chrome and it always crashes for me
Yes, this was fixed by the Chrome devs, but not yet in a stable release. Please try the Chrome dev build for example, and you'll see it runs very well there. In just a matter of weeks that will be true in stable Chrome as well.
The code generation back-end and middle end are the same as IonMonkey uses (sans code generation patterns related to added IR instructions).
Overall both start of asm.js code compilation and end are highly customized and different from what happens to normal JS functions.
Whether this constitutes a separate pipeline or not is debatable. I think it does because none of this custom stuff is running for normal JavaScript no matter how you write it until you put "use asm"; in the right place. I am not debating that it is build on top IonMonkey though (my post from April states exactly that).
[One additional thing to notice is that asm.js typing rules are clearly at least partially duplicate what IonMonkey type inference already should infer statically for the JavaScript code, at the same time, if I am not mistaken, there is little sharing going on between OdinMonkey type-checker and TI engine.]
If this comes down to the semantics of "separate pipeline" then maybe that is pointless. There is some new stuff at the start and end of processing, as you say, but all the middle is shared, and that is by far the bulk of the code.
IMO it comes down to the fact that one developer wrote all the new stuff at the start and the end in a few short months. Compared to a team that took years to write IonMonkey and other parts of the JS engine that are shared. So calling this a new VM or new JIT is definitely wrong, and even calling it a new pipeline feels like an odd choice of words, since the "pipeline" used on asm.js code is almost entirely of the existing SpiderMonkey VM.
It is not a separate pipeline. asm.js uses the standard IonMonkey pipeline, with some additional IR-level instructions.
Furthermore, the argument that doing work on asm.js won't help normal JavaScript applies equally well to the Dart VM.
> There's nothing special the "author" would have to do, it already exists as part of the project template
I'm glad to hear that, but the fact that it is possible to just not serve the JS (or, just as badly, not test it: from what I've read elsewhere in this thread, the semantics of Dart2JS is not the same as the semantics in the Dart VM!) doesn't give me confidence that people won't write Web apps that depend on the Dart VM.
The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
> The demo doesn't let you run it in IE10 and whilst it lets you try run it in the latest Chrome, but it crashes.
That has nothing to do with optimizations and is a bug in Chrome's JS implementation. The ECMA standard says that asm.js is valid JavaScript.
> The worry is that Web apps will come to depend on the Dart VM being present. I have seen nothing to indicate that this is not a very real possibility.
Dart has always their primary goal to compile to efficient JavaScript:
> For languages that are quite different from JavaScript: it's important for Dart to compile to efficient JavaScript - http://www.dartlang.org/support/faq.html#compare-to-everythi...
There have been many times where language features were dismissed because they couldn't be compiled to efficient JavaScript (e.g. non-local returns and tail recursion). Google knows that Dart2JS is an important platform to optimize for (which has great source maps / debugging and tree-shaking optimizations) since it's the platform target that most browsers will be running and they want to ensure their own internal apps built with Dart2JS has a good experience across all browsers.
Following the mailing list, the only known deviation (that's wasn't a bug) is with some corner cases involving its use of arbitrary-precision integers: http://www.dartlang.org/articles/numeric-computation/ which relates from numbers in JS being stored in doubles (IEEE-754).
Other than that it's impossible for web developers to "target the Dart VM", the libraries in the Dart SDK are separated by platform so packages that can only run on the Dart VM like 'dart:io' cannot run on the client. Likewise there are some client packages like 'dart:html' that can only run in a browser and not on the server.
I've never heard anyone from Google state an intent to ship Dart VM in browser for general use without other browser vendors being on board (Dart VM for running Dart on the server, sure, and Dartium [Chromium with Dart VM] as a rapid-cycle tool for developers, sure), the specific reason being to encourage Dart use by not making it browser specific.
Heck, there's no reason, if asm.js catches on for optimized browser support, the preferred-for-client format of Dart couldn't move from compilation to bog-standard JS to compilation to asm.js.
asm.js is just JavaScript that works in all browsers and if a browser integrates an asm.js compiler, it'll run faster.
Yes there are deployments steps needed to serve both Dart and JS to browsers: Those steps are: 1. Include both the JS and Dart in your static resources. 2. There is no 2.
Since no general use browser implements the Dart VM, no one would do that, so its really pretty irrelevant.
That's right. My hope is that it continues to stay that way, absent browser-manufacturer consensus.
(for my personal projects, I genuinely love JS)
1 As someone who works in a large organization, I live this. Small groups with great programmers can make use of all the many tools and tricks for maintaining their project, but for teams fractured across time and space and governance, it is no fun.
http://arewefastyet.com/#machine=11&view=breakdown&suite=asm...
and you can see that saying that asm.js runs faster in a particular browser is just wrong. On many benchmarks Firefox and Chrome are very close.
In the end, asm.js speed is just like SunSpider and Octane and Kraken speed - it's something browsers compete on. That tends to reduce the differences over time, since all the JS engines are very capable.