4 ms·

There's a valid philosophical objection here, and I found the article illuminating about the nature of Asm.js. The strategy of making a static subset of a lang

There's a valid philosophical objection here, and I found the article illuminating about the nature of Asm.js. The strategy of making a static subset of a language that's easy to compile works great -- if it's targeted at humans! RPython, for example, means you can write the Python VM in Python, and the SmallTalk VM (or Squeak?) was written in SmallTalk using the same approach. The point is part of your code base is in this restricted language instead of C, and you can bootstrap that way. If this language is just a compiler target and not meant to be particularly human-friendly (RPython has classes and mixins) then making it a weird subset of JavaScript is a little more dubious and without precedent that I can think of.

acqq 14y ago
It's definitely not "just a compiler target," not more than the assembly language in which people still write some code by hand when there's need for that. The real world example: https://github.com/srijs/rusha https://github.com/srijs/rusha (see the benchmarks -- Firefox 21 uses asm.js) and the source https://github.com/srijs/rusha/blob/master/rusha.js https://github.com/srijs/rusha/blob/master/rusha.js I don't see that the code got ugly. The calculations needed are the same, the most obvious differences from the "non-asm.js" code is the "asm.js" and a few |0 marks. And some of such |0 constructs can improve speed even on the browsers which don't do full "asm.js". So the engines will get smarter by recognizing such constructs even without the full support of "asm.js" segments. It's a win-win already.
- munificent 14y ago
  Right, but your example here is a particularly skewed one. It's a hashing library. All it does is take integers and do arithmetic on them. Most real-world application code is not at all like that. Asm.js doesn't even support strings as far as I know.
  - acqq 14y ago
    Asm.js is exactly made for things like that: the pieces of code that don't depend on "strings" but calculate a lot. And for things like this: http://bellard.org/jslinux/ http://bellard.org/jslinux/ For "strings" the existing JITers do already the good job. You can just use JavaScript as is then.
    - munificent 14y ago
      Yes, agreed. asm.js is a great fit here. My point was that that fact doesn't generalize well to other problem areas. Earlier you said asm.js isn't just a compiler target, but if your program uses strings, or objects, or closures, or GC, then it's not going to be a good fit to use asm.js.

acqq 14y ago

It's definitely not "just a compiler target," not more than the assembly language in which people still write some code by hand when there's need for that. The real world example: https://github.com/srijs/rusha https://github.com/srijs/rusha (see the benchmarks -- Firefox 21 uses asm.js) and the source https://github.com/srijs/rusha/blob/master/rusha.js https://github.com/srijs/rusha/blob/master/rusha.js I don't see that the code got ugly. The calculations needed are the same, the most obvious differences from the "non-asm.js" code is the "asm.js" and a few |0 marks. And some of such |0 constructs can improve speed even on the browsers which don't do full "asm.js". So the engines will get smarter by recognizing such constructs even without the full support of "asm.js" segments. It's a win-win already.

munificent 14y ago
Right, but your example here is a particularly skewed one. It's a hashing library. All it does is take integers and do arithmetic on them. Most real-world application code is not at all like that. Asm.js doesn't even support strings as far as I know.
- acqq 14y ago
  Asm.js is exactly made for things like that: the pieces of code that don't depend on "strings" but calculate a lot. And for things like this: http://bellard.org/jslinux/ http://bellard.org/jslinux/ For "strings" the existing JITers do already the good job. You can just use JavaScript as is then.
  - munificent 14y ago
    Yes, agreed. asm.js is a great fit here. My point was that that fact doesn't generalize well to other problem areas. Earlier you said asm.js isn't just a compiler target, but if your program uses strings, or objects, or closures, or GC, then it's not going to be a good fit to use asm.js.