asm.js as a library as opposed to target?

[Drakim]

There has been talk about adding support for asm.js to Haxe in the past:
https://groups.google.com/forum/#!topic/haxelang/yB6WJWbTOvQ
https://github.com/HaxeFoundation/haxe/issues/1649

But as Nicolas concluded at the end of the feature request, implementing asm.js as a target is not feasible until it has a GC. But I would argue that even with a GC, implementing asm.js as a target isn't desirable. asm.js was designed to be be a strict subset of JavaScript, working soley with primitives like int and float, with no classes/prototypes, objects, and other convenient but slow dynamic features. This allows the browser to make a lot of assumptions about the code, which means it can run faster.

While the Haxe compiler could in theory implement all of it's higher level and general purpose functionality in asm.js (such as classes, objects, dynamic, typing, etc), or the compiler could output Haxe -> C++ -> Emscripten -> asm.js, it's not clear that this would actually end up being faster than just outputting to the regular vanilla JS target. The idea is actually rather silly. We would be forgoing higher level features of the JS language while sticking to a strict subset of fast low level features, just to then turn around and re-implement those higher level features by hand. I don't think our implementation would be any faster than the native one that browsers provide. Chrome and Firefox are written in C++, which is faster than asm.js. It would also bring a lot of downsides to the table such as it being very hard to interact with popular JS libraries from the asm Haxe.

Rather, I feel asm.js lends itself better to isolated number crunching tasks and the like. I think that Haxe would be better served by asm.js by treating it as an addition to it's JS target rather than a replacement. If you take a look at this library TomBebbington wrote a while back, you may get the idea:

https://github.com/TomBebbington/llhx

Following this sort of design, rather than trying to jam all of Haxe into asm.js, we could selectively mark a class or function as being powered by asm.js. The compiler would then output asm.js for that particular section, and throw errors if we do something that isn't allowed in asm.js (such as instancing an object). While the llhx project above is cool, I'm not sure it's that viable to implement asm.js merely as a macro rather than compiler feature, as compile-time will balloon as the macro works on converting huge amounts of code.

What do you think? While I am not so hot on the idea of my entire project being asm.js (think of the debugging, ugh!), I very much like the idea of being able to speed up my A* pathfinding, or speeding up that tight audio generation loop with asm.js.

[Haxiomic]

Hey, sounds like a great idea, something like an @:asmjs function meta would do the trick - looked like TomBebbington was onto something just like that, it's a shame it hasn't been updated in a few years - do you know the current state of the library?

[Hugh]

I would guess there could be some benefits from the "|0" style type-hints.  Haxe has this information and since it is backwards compatible, there might be a nice  speedup at the small expense of file size.

The other tricks, like using a byte-array as "memory" maybe directly usable by haxe without needing the whole VM/GC thing, like using an array of floats instead of an array of point objects.  I also think there is some good scope here to implement a "struct" system using macro without needing to change the language.

Hugh