|
|
|
|
|
by leoc
4243 days ago
|
|
> It's more than just "usable". Chrome doesn't support asm.js, but it runs asm.js apps just dandy, albeit not quite as fast as Firefox. Chrome is hardly the most likely problem child; older versions of IE are more likely to taking up the rear when it comes to performance. > I don't see what's unreasonable about it. You compile native code to a portable intermediate language. It runs at near-native speed in some browsers, and reasonable speed in others. Yes, it's a subset of JS. So? Why does this bother you? Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases. If you're telling me that asm.js now consistently runs at roughly-as-good-as-native-code speeds across the board, then that is surprising but great news. It certainly didn't seem to be the case three years ago, when we were assured that it was impossible to efficiently implement bignums in code compiled to JS, but I suppose things have been moving quickly in this area. Unfortunately OP doesn't seem to fully support that idea, as it seems to imply that IonMonkey requires significant processor time to make the JS run fast. (Shuffling that overhead off to another thread may effectively remove the performance burden when running single-threaded code on a machine which has two or more idle cores and is plugged into the wall, but it comes back in other cases, including the case where several tabs are all running asm.js programs at the same time.) |
|
Older versions of IE won't run normal JS fast either. I hardly see why this is a problem.
> Well, the biggest and most obvious reason to be bothered (though not the only one) is the concern that the journey through JS (as opposed to generating slightly-shackled native code and running that on the client) is going to impose a performance burden that the browser's JS engine won't be able to fully eliminate, at least in some cases.
Are you aware of how asm.js is actually designed to function? In Firefox, asm.js is slightly-shackled native code. It's not JavaScript at all.