Simple diet tricks for asm.js(floooh.github.io)
floooh.github.io
Simple diet tricks for asm.js
http://floooh.github.io/2016/08/27/asmjs-diet.html
6 comments
> Even with exception support disabled, you can still throw them, you just can't catch them in C++ land.
Is something printed in the console under emscripten if an exception is thrown?
Is something printed in the console under emscripten if an exception is thrown?
It gets converted into a Javascript exception, which will at least give you the Emscripten converted function it was thrown in.
Interesting. Thank you.
"The emscripten version is even smaller than the native version after compression, impossabru! I actually didn’t expect this myself (last time I did such comparisons the emscripten versions came out about 10..20% bigger)"
This is because JavaScript is alpha-numeric and is easier to compress than binary. There are a relatively 'small' number of characters in the alpha-numeric range, so they can be mapped together easier than the wider range of binary data.
This is because JavaScript is alpha-numeric and is easier to compress than binary. There are a relatively 'small' number of characters in the alpha-numeric range, so they can be mapped together easier than the wider range of binary data.
Can someone ELI5 what asm.js is? I've tried Googling it multiple times now and every time I basically give up because I can't relate to anything it's talking about when all they use is buzzwords.
This (funny and accessible, don't worry) talk by Gary Bernhardt is what helped me understand asm.js for the first time: https://www.destroyallsoftware.com/talks/the-birth-and-death...
Those recommendations together almost sound like "write C in C++".
A lot of C++ coding styles do something like that. I guess because C++ is so large.
asm.js really seem to be a good solution, I hope some day it will be used to do more than web games. But at the same time, the vision of the future of compiling everything in javascript is pretty scary.
I think WebAssembly will replace asm.js soon.
Think of WebAssembly as a binary encoding of asm.js. You'll be able to deliver the same program in either format. Asm.js will still be around to support older browsers.
> Asm.js will still be around to support older browsers.
I don't see a need for this since WebAssembly will provide a polyfill.
I don't see a need for this since WebAssembly will provide a polyfill.
The polyfill won't benefit from browser based JIT compilation. If you're concerned with performance, even for browsers that don't support wasm, you'll want to switch to asm.js.
I sort of think about it the other way round, actually.
Not sure what you mean? Asm.js was defined a couple of years before Web assembly
Yes, but it was defined after actual assembly/low level languages like BLISS. So it was defined as a way of doing something "assembly-like" (or BLISS-like, or BCPL-like) in an environment that didn't allow for such code.
nit: the C style example, should use /* These kind of comments */ not // these kind of comments.
C99 supports //.
C89 standard does not.
It is 2016.
Why evolve a language if you can't use any the new features?
Why evolve a language if you can't use any the new features?
So? If you're still using C89 you're doing it wrong.
2 other points I'd add to this overall:
1) Can't emphasize enough how bad exception support is for size, expect in the neighborhood of 30% size increase. This is due to needing to handle all of the possible ways functions can return. Even with exception support disabled, you can still throw them, you just can't catch them in C++ land.
2) goto's. There's a few good reasons to use these, especially in code that needs to make sure cleanup code always runs. Emscripten supports that with a couple different code constructs, pretty much all of which cause a significant amount of bloat. We've saved ~100k in some cases by specifically targeting some 3rd party code that made use of them and rewritting them to not have gotos.