> When I sit down and think about performance gains that asm.js-implementation OdinMonkey-style brings to the table I don’t see anything that would not be possible to achieve within a normal JIT compilation framework and thus simultaneously make human written and compiler generated output faster.
https://v8.googlecode.com/issues/attachment?aid=25990016000&...
you can see that on a few of those there is still a significant difference, for example on Lua (I filed an issue on that here http://code.google.com/p/v8/issues/detail?id=2873 ).
In principle, a JIT can do anything an AOT compiler can (and more). In practice, the JITs in Chrome and Firefox have gotten close to what the asm.js AOT in Firefox can reach, but only on most benchmarks, not all. The AOT does give a fairly good guarantee of always running the code at a good speed, while the JITs depend on heuristics. In practice, this means that JITs can be tweaked to run any benchmark well, but they don't always do it out of the box, while the AOT far more often does do so.
Again, JIT heuristics can be fixed and improved, I have no doubt about that. And JITs could be designed to rely less on heuristics, I am a strong believer in that as well. But neither of those has yet been proven. I hope they will, though :)
There is still a ways to go though before they are fully on par with Firefox. Note that one of the benchmarks is still far slower on Chrome, and there are still probably edge cases here and there that trigger slow JS in Chrome. The guarantee of asm.js that your code is ~2x slower than native is nice. Additionally, loading in massive amounts of asm.js in Firefox will be much faster in Firefox in the future when they optimize the parser for asm.js.
All in all, these are very happy times. There are pros and cons to both approaches, but it's exciting to see how far it's going.
What? How did a couple of benchmarks that showed ~2x performance for a few tasks become a 'guarantee'? In some situations asm.js only takes twice as long to run your code, in others it takes 12 times as long[1] or even more[2].
[1] http://cdn.arstechnica.net/wp-content/uploads/2013/05/benchm... [2] http://cdn.arstechnica.net/wp-content/uploads/2013/05/classi...
It's fair to say that for single-threaded code, asm.js has a very good chance of running at half the speed of native, or better. For multicore code, it depends on whether web workers make sense for that use case - if they do, it can still maintain the same performance compared to native. Otherwise, the web platform would need to consider adding some more low-level parallelism to JS. Such proposals exist and there is some discussion about them.
It's hard to get over the fact that a JIT simply faces an uphill battle against an engine that starts by restricting you to a subset of the language; basically, you can assume both engines are being written by equally smart people, so you kind of have to expect that the one that takes the restrictions is going to have a long-term persistent advantage in practice, no matter how theoretically the other team could catch up. OdinMonkey still has all the JIT opportunities, but it has other opportunities too.
The target for most of this is porting C games to the Web, and many modern C games use all kinds of multithreading and blocking I/O. Game programmers are not interested in safety, they are interested in performance.
Yes, message passing leads to fewer bugs. It also leaves a lot of performance on the table if you are trying to maximize usage of CPU resources on an SMP architecture.
The funny thing here is that gave devs are still kind of weary of threading bugs, and blocking I/O was something that was probably earliest dealt with by the people having to stream content off of spinning plastic discs.
A VM or high level compiler abstraction, especially with GC, tends to interfere with #1, and sandboxed environments with abstract APIs for accessing hardware tend to interfere with #2.
Yes, this is not to say that games won't use scripting, like Lua or UnrealScript, but those are not part of the rendering loop.
Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP).
I don't really see it as a target for next-gen games, regardless of the cool UnrealEngine demos. Mobile casual games maybe.
For #1, asm.js doesn't have GC, by and large (there are a couple of places where the GC gets used when interacting with Web APIs, but those are fixable and don't matter much in practice). For #2, "a sandboxed environment with abstract APIs for accessing hardware" precisely describes Pepper!
> Asm.js provides predictability in terms of GC, but it does not ensure predictability in terms of performance (because of differing JIT implementations), nor does it give the direct access to hardware resources one would like (e.g. SMP).
I don't understand what you mean. The performance predictability is fixed by "use asm" and AOT compilation. V8 is opposed, but your point (rightly, IMHO!) argues against that choice. If you're just arguing that there will be multiple implementations of asm.js and that's bad for predictability I don't see that being fixed with any solution outside of a browser monopoly. If PNaCl is to become a cross-browser solution, then you must be open to alternative implementations.
As for threads, we can continue to evolve JavaScript so that it is supported, at least in asm.js mode. I don't see this as some fundamental obstacle.
Yes, pepper is an abstraction, but you get concurrency primitives which is lower level than asm.js.
The reality is, neither asm.js nor NaCl are going to succeed in getting the gamedev community onto the web platform. The two most popular platforms, iOS and Android, have native SDKs, and so do the consoles and desktops, so any developer who wants to maximize revenue is going to want to target those. The additional headache of a browser port onto a heavily fragmented platform with unpredictable performance, and an audience that has shown little appetite for paying for web apps pretty much guarantee that this whole asm.js vs NaCL debate is moot.
Developers just don't care about runtime portability as far as games are concerned. They will do the work to do a source port for optimal performance if the market is there.
Does Electronic Arts or Valve care about getting Battlefield 4 or Portal 2 running in the browser in a portable way? I highly doubt it.
The PS3 SPUs also didn't have access to system memory, and SPU code had to be compiled into small "executables", so in a twisted way this is a similar model to WebWorkers ;)
Shared TypedArrays would be nice, but only if this also comes with a complete set of atomic operations. But in my opinion, vector datatypes would be more important in the short term for JS (so it can make use of SSE under the hood).
Which is already more than proven that only leads to threading bugs.
I agree that we don't want to break the single-threaded JS model. But we have options, the easiest of which is to restrict shared mutable state to ArrayBuffers and asm.js, or asm.js-like code.
edit: Video link http://www.youtube.com/watch?v=IXIkTrq3Rgg
JavaScript is not some immutable thing. It needs enhancing, not replacing.
I looked at the spec briefly (http://wiki.ecmascript.org/doku.php?id=strawman:value_object...), but it doesn't talk about the how.
I understand nan-boxing and similar techniques, but they seem to imply at least some runtime overhead to test the type of the value in some cases. Also, AFAIK, 64 bit integers cannot be represented with nan-boxing, as there are only 51 bits available for the payload.
On the other hand, Dart doesn't have required type annotations either and it has 64-bit ints, doesn't it? So it should be possible to introduce in JS.
Runtime overhead is likely, but then when you're in the JIT sweet spot the types are all known so you get JITcode that doesn't check types.
GC is a related example of a place where VM designers told us not to worry ourselves, but it turns out that GC is inherently hard and you are going to pay for that convenience - either in performance or in memory. See: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow....
I agree that not having to rely on the JIT to figure out how to optimize your code with 'magic' is preferable. I tend to lean towards that where possible in most of the JIT/GC-based environments I use (C#, JavaScript, etc), and it tends to pay off.
This is precisely what "use asm" is for. It gives you direct control: each allowable operation in the subset has a direct analogue to the appropriate machine instruction(s). If you fall off the happy path and stray into "JIT magic" territory, you get a message in the developer console telling you to fix your code.
Unfortunately V8 is opposed to "use asm" in favor of the "JIT magic".
There are already multiple types in JavaScript, and this already affects performance; for example "+" is defined for both numbers and strings. All JavaScript engines handle this in the same way, more or less. You start out with a "baseline JIT" that does not make assumptions about the types of objects and has type-check-and-dispatch on operations like "+". These type checks record the types of objects that have flowed through each point. Once enough types have flowed through so that we can reasonably predict the types, we recompile the function to assume that the same type (for example, number) goes through, which enables greater optimizations. You then hoist type guards up (or eliminate them if you can prove them never taken) so that you deoptimize and bail out.
Value objects don't change this overall picture, they just add more types.
All of this, however, is irrelevant to asm.js. With an ahead-of-time optimizing compiler, we know what the types are beforehand via the asm.js spec. So there are no type guards inserted at all, and none of this is an issue. For example, NaN-boxing is not used in the Firefox asm.js compiler (OdinMonkey). We know which values are doubles and which are integers, so we need no runtime guards or type tests at all.
In this cas mozilla is the one that took the lead on the asm.js case, and healthy competition is always better, but I believe it makes no doubt that the v8 team would have worked at improving their js speed as much as possible even without that pinch from mozilla.
That's not accurate. I recommend you go back and look at the actual order of events here.
Apple started the JS perf battle with SquirrelFish Extreme and Firefox answered with TraceMonkey, all before Chrome was even announced.
I am not discounting the impact that V8 has had on the industry, but it is simply wrong to claim that Google kicked this thing off when Apple and Mozilla were both there publicly squaring off in JS benchmarks well before you, and just about every one else on the planet, even knew Chrome was a thing.
http://nontroppo.org/timer/kestrel_tests/
and when Safari was still an early beta Opera was marketed as "The Fastest Browser on Earth".