4 ms·
> Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes i
by azakai 13y ago
> Only Firefox uses a separate special interpreter (Odin Monkey) for asm.js
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/ 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.
- mythz 13y ago> Not true, Firefox uses OdinMonkey, which type checks the code, but then optimizes it using IonMonkey, the exact same pipeline all JS code uses. 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 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/cr4jTsfxVg8 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 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 :)
- azakai 13y ago> 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? 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.
- mraleph 13y agoOdinMonkey is: a separate front-end for optimizing compiler (one that translates JavaScript code to compiler IR), a couple of IR instructions specific to asm.js (e.g. asm.js heap access), plus AOT linker, trampolines for transitioning to/from asm.js code and some runtime infrastructure specific for bounds check elision on 32-bit platforms. Potentially there will also be a separate parser added to the mix. 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.]
- azakai 13y ago