6 ms·

"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows th

by asb 14y ago

"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js allows them to 1) make use of their existing JIT compiler and 2) avoid defining a new bytecode format (the benefits of this are questionable). asm.js is ugly, but it doesn't seem that much more ugly than adding a new multi-megabyte dependency to every browser. I suppose an interesting question would be how hard would it have been to standardise on the PNaCl bytecode format and use that as the input to ${FOO}monkey

drivebyacct2 14y ago
I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...
- asb 14y ago
  I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.
  - drivebyacct2 14y ago
    I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.
- josteink 14y ago
  I think the main reason for anyone not to support it, would be that it makes the WWW platform specific. I can't wait for my first "Sorry. This webpage does not support ARMv7 Hard-float". Another reason Mozilla might not support this is that it's actually not called Na(tive) Cl(ient). It's full name is "Google Native Client". That sure as hell doesn't sound like a standardized and fully spec'd thing I'd implement in my browser if my name was anything besides Google.
deleted 14y ago
[deleted]
- shardling 14y ago
  >JITing strictly typed code is a vastly different problem than JITing dynamic code. My limited understanding is that it's only vastly different because it's easier. One thing javascript JITs do is try to infer the datatypes likely to be used, and compile a version of the code with those assumptions baked in. In other words, when you've seen the 100th iteration of a loop, you can guess that the next 1000 iterations will involve the same types and optimize for them.
auec 14y ago
But wouldn't they want to eventually use LLVM to compile Asm.js anyway? Surely LLVM is going to produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it. OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to support a specific LLVM bitcode version forever.
firefoxman1 14y ago
> "Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage." In other words, Flash reincarnated.
- sultezdukes 14y ago
  Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage." In other words, Flash reincarnated. Who cares? Asm.js apps are little black boxes.
cali 14y ago
Wouldn't they want to eventually use LLVM to compile Asm.js anyway? Surely LLVM will produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it. OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to forever support a specific LLVM bitcode version.
olpit 14y ago
Wouldn't they want to eventually use LLVM to compile Asm.js anyway? Surely LLVM will produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it. OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to forever support a specific LLVM bitcode version.
chc 14y ago
Or they value backwards compatibility. Any asm.js you output will run with the same semantics and most likely pretty good performance whether or not the browser supports asm.js. Feed PNaCl bitcode to anything but special builds of Chrome and you may as well be streaming from /dev/random.
mraleph 14y ago
I don't think you really need to import LLVM to use bytecode, nor do I think that bytecode must look anywhere like say LLVM bitcode. I specifically listed freedom of choice as a bytecode benefit for implementors. You can have bytecode and pipe it through a separate front-end into your JavaScript JIT compilation pipeline. You can have a separate compilation pipeline as well, if you think it is better.
- asb 14y ago
  I didn't mean to imply you had said that. Sorry if my wording gave that impression.
  - mraleph 14y ago
    oh, no. I was not saying that I have such an impression. I sometimes wrongly use "I did not say" as "I don't think" as a habit, literal translation from Russian where it does not have critical connotation. I fixed the comment above.
MichaelGG 14y ago
From a technical perspective, using JS as a bytecode is less than optimal, of course. But asm.js is a good backdoor. Good luck getting some third party bytecode added to MS's and Apple's browsers. There was a fairly popular bytecode used in web apps: Java.
- wwweston 14y ago
  > There was a fairly popular bytecode used in web apps: Java. At least two, actually: Flash is another. Arguably better performing and more generally successful. And both of them were mostly open... freely targetable as runtimes, and almost freely re-implementable. With as much hate as both of them have had, I find it a little weird when someone talks about doing it again, but then again, maybe the people who hated Flash aren't the same people who want a Google VM. Or maybe they think third time's the charm.

by asb 14y ago

drivebyacct2 14y ago

I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't one of them...

asb 14y ago
I'm just speculating wildly like most other people here are, but you really think it wasn't a positive for them that they could reuse the JIT they've invested in and have expertise in rather than relying on LLVM.
- drivebyacct2 14y ago
  I don't want to speak to that. I was more referring to the notion that they didn't consider it because LLVM is a large dependency. As others have noted, emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl have been spelled out lots of places.
josteink 14y ago
I think the main reason for anyone not to support it, would be that it makes the WWW platform specific. I can't wait for my first "Sorry. This webpage does not support ARMv7 Hard-float". Another reason Mozilla might not support this is that it's actually not called Na(tive) Cl(ient). It's full name is "Google Native Client". That sure as hell doesn't sound like a standardized and fully spec'd thing I'd implement in my browser if my name was anything besides Google.

deleted 14y ago

[deleted]

shardling 14y ago
>JITing strictly typed code is a vastly different problem than JITing dynamic code. My limited understanding is that it's only vastly different because it's easier. One thing javascript JITs do is try to infer the datatypes likely to be used, and compile a version of the code with those assumptions baked in. In other words, when you've seen the 100th iteration of a loop, you can guess that the next 1000 iterations will involve the same types and optimize for them.

auec 14y ago

But wouldn't they want to eventually use LLVM to compile Asm.js anyway? Surely LLVM is going to produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it. OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to support a specific LLVM bitcode version forever.

firefoxman1 14y ago

> "Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the benefits of the (P)NaCl approach but don't want to have to import LLVM. Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage." In other words, Flash reincarnated.

sultezdukes 14y ago
Or, you know, it could be like Mozilla's vice president of products said about NaCl: "These native apps are just little black boxes in a webpage." In other words, Flash reincarnated. Who cares? Asm.js apps are little black boxes.

cali 14y ago

Wouldn't they want to eventually use LLVM to compile Asm.js anyway? Surely LLVM will produce better code than a JavaScript JIT on non-dynamic code, since it's designed for it. OTOH the Asm.js approach has the advantages of backward compatibility and not being forced to forever support a specific LLVM bitcode version.

olpit 14y ago

chc 14y ago

Or they value backwards compatibility. Any asm.js you output will run with the same semantics and most likely pretty good performance whether or not the browser supports asm.js. Feed PNaCl bitcode to anything but special builds of Chrome and you may as well be streaming from /dev/random.

mraleph 14y ago

I don't think you really need to import LLVM to use bytecode, nor do I think that bytecode must look anywhere like say LLVM bitcode. I specifically listed freedom of choice as a bytecode benefit for implementors. You can have bytecode and pipe it through a separate front-end into your JavaScript JIT compilation pipeline. You can have a separate compilation pipeline as well, if you think it is better.

asb 14y ago
I didn't mean to imply you had said that. Sorry if my wording gave that impression.
- mraleph 14y ago
  oh, no. I was not saying that I have such an impression. I sometimes wrongly use "I did not say" as "I don't think" as a habit, literal translation from Russian where it does not have critical connotation. I fixed the comment above.

MichaelGG 14y ago

From a technical perspective, using JS as a bytecode is less than optimal, of course. But asm.js is a good backdoor. Good luck getting some third party bytecode added to MS's and Apple's browsers. There was a fairly popular bytecode used in web apps: Java.

wwweston 14y ago
> There was a fairly popular bytecode used in web apps: Java. At least two, actually: Flash is another. Arguably better performing and more generally successful. And both of them were mostly open... freely targetable as runtimes, and almost freely re-implementable. With as much hate as both of them have had, I find it a little weird when someone talks about doing it again, but then again, maybe the people who hated Flash aren't the same people who want a Google VM. Or maybe they think third time's the charm.