Therefore I greatly prefer optimisations which speed up 'asm.js-like code', rather than the all-or-nothing optimisation one gets from firefox.
Therefore I greatly prefer optimisations which speed up 'asm.js-like code', rather than the all-or-nothing optimisation one gets from firefox.
[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] http://discourse.specifiction.org/t/request-for-comments-swi...
This is definitely a trade-off, but it's my understanding that asm.js makes more sense as a target for compilers to emit code for, rather than for hand-writing. Would you hand write an entire application in x86 assembly? Probably not...
I don't mind no GC, but having to allocate the maximum memory your program will use before it starts can be painful.
dlmalloc is cross compiled for you. I might be mincing words, but you make it sound like you have to bring your own allocator. Not so.
> makes it hard not to massively waste memory by overallocating a huge buffer.
Non issue. there are compiler flags `-s TOTAL_MEMORY=X` and `-s TOTAL_STACK=X`. Of course, you have to play around with these values otherwise you might not have enough space. I'm working on memory profiling tools to visualize the state of the heap in emscriptenized code [0] and getting them merged upstream. [1] The docs could be better on those flags.
> Therefore I greatly prefer optimisations which speed up 'asm.js-like code', rather than the all-or-nothing optimisation one gets from firefox.
Why must they be mutually exclusive? It's a straw man to paint it like we can only have one or the other but not both, and therefor we must choose. All-or-nothing is also an incorrect categorization; Firefox's JIT makes the same optimizations for non ASM code after it warms up.
[0] https://github.com/nickdesaulniers/emscripten-memprof [1] https://github.com/kripken/emscripten/pull/3178
Wait, so I don't have to include an allocator in every asm.js project? How do I avoid doing that?
> Non issue. there are compiler flags `-s TOTAL_MEMORY=X` and `-s TOTAL_STACK=X`. Of course, you have to play around with these values otherwise you might not have enough space.
How does that make my complaint a non-issue? I shouldn't have to, in this day and age, manually tune the maximum amount of memory my program will use up front. That what my OS is for, I ask for more memory when I want it. What happens when some user decides to use my app in a sensible, but more memory hungry way, and hits so arbitrary limit I had to set for mobile users?
Of course, someone else replied this second point is now invalid, as asm.js is gaining the ability to grow the heap.