Please get in touch with us, your project is very exciting and would be a great use case for CheerpJ. Just drop us a line at http://leaningtech.com/cheerpj/#early.
CheerpJ has full DOM access and interoperability with JavaScript. Demos of these case study will be coming soon.
In addition, the full source code of Nontetris ( http://allievi.sssup.it/jacopone/cnontetris/ ) will be published in a couple of days, with a 'guide' on porting a C++ game to Javascript with duetto.
For games I think you need to show that duetto is just as fast as emscripten when running. emscripten-generated code is very light on the garbage collector (inside emscripten generated code no garbage is produced at all, only in some wrapper code which needs to talk to JS libs), and having the "heap" in a plain typed array usually also gives a performance advantage, since as in C++ you have exact control of the memory layout of your data structures. Not having to construct and destroy JS objects all the time, and keeping all data in typed arrays is essential for performance I think. This is even true without diving into asm.js.
Disclaimer: speaking strictly from a game-devs perspective: I remember that post and from a game dev's perspective the pre-allocated-memory vs. reclaimed-through-garbage-collection argument is a bit weak IMHO. Games have predictable memory usage, and game devs are used to see memory as a static, finite resource anyway (since that's how it is on consoles). Grabbing a chunk of memory upfront is quite common for games. And as for the (big) size of the pre-allocated memory: either your game needs that much memory at a time or it doesn't, if the user doesn't have that much free you're f*cked either way.
The perf comparison is missing a "asm.js + V8" bar, asm.js code is usually faster then non-asm.js code, even if the JS engine isn't implementing AoT compilation as FF does.
"Since I do not expect native platforms (i.e. GLibc) to preallocate gigs of memory at application startup to make it faster when dynamic memory is actually used, I do not expect this from a compiler for the JavaScript target either."
So, it would actually make very good sense to have the thing slab allocate a big honking array upfront, and then manage it with brk/sbrk/malloc, and perhaps just add more memory as needed.
Like, if we're going to be writing C/C++ in the browser, why not do this? Why make us deal with the GC at all?
I see your point. Still, I believe the browser environment is different from a console since it is not supposed to monopolize system resources while being used. Managing memory in smaller short lived chunks is more fair for the system as a whole.
Well, it's just about how much max memory you need at a time, no matter whether that size is split into many small chunks or allocated as a single block. True, an application which needs very little memory most of the time, and spikes to huge sizes from time to time is not optimal with emscripten's approach.
But I don't want to nitpick all day. The more options we have the better, keep up the good work :)
FYI: http://leaningtech.com/duetto/examples/ is broken on OSX in Chrome and FF for me, it looks like a mobile page is served which makes the code examples unreadable. It looks good in Chrome on Windows7, but also broken in FF on Windows7. Haven't test other platforms.
Wow: and a minute after I typed this, my Windows machine gave me a blue screen, not sure if it's related but it's the first in years ;)
Please get in touch with us, your project is very exciting and would be a great use case for CheerpJ. Just drop us a line at http://leaningtech.com/cheerpj/#early.
CheerpJ has full DOM access and interoperability with JavaScript. Demos of these case study will be coming soon.
Cheers - LT