Hacker News Reader

Comment by flohofwoe | Hacker News Reader

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.

View on HN

We have written a detailed post a few months ago comparing duetto to emscripten. We also explain why we think it's not a good idea to use a pre-allocated typed array heap: http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...

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.

Edit: fixed "...uncommon -> common..." above

From the link:

"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 :)

Reply on news.ycombinator.com