

Ask HN: Javascript type inference and Asm.js - logn

Asm.js works best for compiling statically typed languages into Javascript, adding type information into the JS so that compilers can optimize around this. Some people are worried this will lead to stagnation in JS optimization for when it's written by humans (although I've seen V8 developers de-prioritize Asm.js requests in favor of other optimizations serving JS programmers).<p>Can't we add type inference to JS to let it be Asm.js compiled? E.g., http://www.ccs.neu.edu/home/dimvar/jstypes.html (however, this doesn't distinguish between float/double/int/long, but that doesn't seem impossible)<p>I don't see in the Asm.js spec that they add type info for classes/objects, but this doesn't seem too hard to infer either. You'd take an inventory of what keys and types are in objects and make a hierarchy of them for 'inheritance' of objects.<p>Am I missing something?
======
llogiq
Are you proposing a JS to JS filter that

a) checks if functions/modules are eligible for asm-ifying (that is, it only
uses asm.js functionality, no metaprogramming, only using asm.js "heap", do I
oversee something?) b) adds a "use asm" to the function/module c) adds the
correct type information d) perhaps compiles some JS functionality into asm.js
(I'm thinking of the heap, which could be precompiled under certain
constraints, but it's probably better to make the compiler not too smart)

~~~
logn
Generally, yes. Granted, I don't know the specific details of this. I'm just a
JS programmer, not familiar with Asm.js (other than browsing their homepage
and slides and articles). But it seems like the people working in these
communities have written off or not focused on JS ever being compiled to
Asm.js JS and achieving near-native efficiency. And that instead, the focus is
on more traditional languages with static typing compiling to Asm.js JS. And I
suspect there's a reason for this, that it's hard or impossible to compile
regular JS to use asm to achieve near-native efficiency. But I'd like to know
specifically why, because in my naive view, it's possible (and even if really,
really hard... totally worth it since you can then speed up all the JS that's
ever been written to date and all future JS we write... and even if that's not
possible that we can focus on avoiding certain features of JS to make
compilation to Asm.js JS possible, i.e., a saner way to write Asm.js JS in
JS).

------
argonaut
I am not by any means an expert in compilers/language design. But apparently
according to this talk [1] dynamic typing is not the reason JS and other
dynamic languages are slow, given the optimizations that effectively "solve"
that problem.

I would guess that both 1) metaprogramming, and 2) lack of low-level memory
management contribute more to the fact that JS is slower than dynamic typing.

[1][https://speakerdeck.com/alex/why-python-ruby-and-
javascript-...](https://speakerdeck.com/alex/why-python-ruby-and-javascript-
are-slow)

