[amelius]

I agree with these points. There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform (without becoming a really ugly hack), where I can see that happen for NaCl. This is a pity, because multithreading is something you need for making responsive applications (GUI not hanging when a computation occurs in the background). Yes, there's webworkers, but I don't consider them a multithreading solution, because they don't allow a shared address space for inter-thread communication (only message-passing). This can be detrimental for performance, because the "structural sharing" paradigm becomes useless.

I think that a base-language without support for garbage collection would be preferable. The main advantage is that multithreading is easier to implement. (Any language built on top of this language could implement its own garbage collection, in principle.)

[TazeTSchnitzel]

> There is at least one major flaw, though: asm.js can probably never be made into a truly multithreading platform

Are you sure? I believe I heard somewhere that Mozilla might be working on that by sharing a typed array across Web Workers.

I previously thought you couldn't do multi-threading, but now that I think about it, there's no real architectural reason you couldn't allow sharing a typed array between web workers, it's the DOM that's the problem.

And if you can share a typed array, you have a shared address space, as asm.js uses typed arrays for its heap.

EDIT: Aha, yes, Mozilla are working on this! https://bugzilla.mozilla.org/show_bug.cgi?id=933001

[amelius]

Interesting! Yes, that would help a lot, but I'm not sure how growing heaps will be modeled then (are they allocated block by block?) And how is a growing heap communicated in practice between threads? Is every read-operation to be guarded by a check if the corresponding block is available in the current thread?

[azakai]

Growing heaps are in progress,

http://discourse.specifiction.org/t/request-for-comments-swi...

(It's unclear how that would work with heaps shared between threads, but so are most issues regarding threads - still just fairly early experimentation there, last I heard.)

[TazeTSchnitzel]

I don't know either. I'm aware that asm.js currently doesn't allow expanding the heap (it's always a fixed-size allocation), but that might change.

If you mean allocating from that heap, I imagine it'd work as it currently does: the program implements its own allocator.

[sunfish]

asm.js is indeed growing the ability to resize its heap [0]. It's already implemented in Firefox Nightly [1].

[0] http://discourse.specifiction.org/t/request-for-comments-swi... [1] https://bugzilla.mozilla.org/show_bug.cgi?id=965880

[amelius]

What I'm wondering is what a pointer-dereference would look like. Is every pointer dereference in asm.js implemented by TWO dereferences (one to find the heap, and then one to find the index within the heap)? And are there mutexes (or other synchronization directives) used per dereference in a typical implementation?

[sunfish]

It's still being designed, but we're unlikely to do anything that would require a double dereference or synchronization on each access -- that would be a lot og overhead. We'll likely seek a way to keep accesses fast by doing more work at heap resizing time, since heap resizing ought to be infrequent.

[amelius]

I guess the allocator would be able to manage blocks so you could view them as a single heap. At least, that's how I'd like to deal with memory as a "user". However, a "pointer" then has two parts: first, it should point to the block, and second it should have the index within that block. A stored pointer (a pointer stored within the heap) then would need 2 lookups for a dereference (first, determine the block-number, look up the block from a small array, and then lookup the index within that block). This sounds a little convoluted to me. Shouldn't there be a simpler and more efficient way to deal with growing memory?

[cromwellian]

That seems woefully underspecified compared to multithreading in C. Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model? If you want to do safe, performant, multithreaded programming, these things need careful specification, especially in the context of optimizing compilers.

[TazeTSchnitzel]

> That seems woefully underspecified compared to multithreading in C.

It's not even multithreading yet, it's just a means that support for it might be added.

Also, I don't see why you're complaining about it "compared to multithreading in C". To write for asm.js, you write in C. All this is implementation details for how the C compiler (emscripten, probably) will generate its code.

> Where's my test_and_set? How do I implement locking/mutexes? What's the equivalent of volatile in asmjs? Does it have a memory model like the Java Memory Model/OpenMP Memory Model?

Presumably, locks would be added somehow.

[cromwellian]

pthreads exist in NaCL/PNaCL today, that's the point. There's not many big games on the market today that don't use multiple cores.

[TazeTSchnitzel]

Yes, NaCl has them today. What's your point? Yes, that means NaCl is somewhat faster for the time being. It doesn't mean it always will be.