You still have the pthreads issue. NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine.
That model is one of the easiest and safest ways of doing concurrency of which I'm aware, unless you want to enforce immutability on shared memory records.
We're not talking about what's safer, were talking about NaCL vs asm.js, and the primary purpose of those is to run native C code in your browser without significant rewriting (e.g. emscripten)
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.
It seems to me that most modern game engines have settled with some sort of parallel task system where the main thread pushes asynchronous tasks into a thread pool. Building such a generalized parallel task system on top of pthreads or WebWorkers in C/C++ is easier then trying to emulate something like pthreads in emscripten (you can't do this anyway because there are no shared memory resources in JS). One has to be aware of the overhead of getting data in and out of workers though.
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).
"modern C games use all kinds of multithreading and blocking I/O."
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.
It's true that gamedevs worry about this, and Tim Sweeney has even given prezos on how great functional languages would be for game programming, but the reality is, hardcore game devs crave two things from what I can tell: 1) determinism and 2) maximizing utilization of resources
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.
> 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.
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.
The variance in JIT optimizations will be much wider than the variance in compiling C code to NACL compliant x86 code. In one case, you have varying implementations of a runtime compiler, in the other, you have a single compiler known to the game-dev ahead of time, what varies in the sandbox hit.
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.
I think the proper question under the formulation you provided is, "Where can I find one that does anything other than produce bugs," since you asserted that bugs are the only result. To which the answer is: any of them.
Nothing of this complexity is bug free, but the fact and the points is that some of the most reliable software everybody uses every day -- OS kernels, DBMS, etc. -- are not just multithreaded, but heavily multithreaded.
Perhaps locking the DOM is a good trait if you can communicate between the main thread and the webworkers then you can request that the main thread changes the DOM and synchronize, without this you might get unexpected behavior anyways?
> NaCL can leverage SMP in a way that single-threaded JS can't, and the idea of introducing concurrency into JS sends shivers down my spine.
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.
