3 ms·

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

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-asm.js/ http://leaningtech.com/duetto/blog/2013/05/28/Comparing-to-a...

flohofwoe 13y ago
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
- angersock 13y ago
  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?
- apignotti 13y ago
  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.
  - flohofwoe 13y ago
    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 :)

flohofwoe 13y ago

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

angersock 13y ago
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?
apignotti 13y ago
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.
- flohofwoe 13y ago
  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 :)