3 ms·
Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to be
by mortehu 13y ago
Three such languages are called AMD64, IA32 and ARM machine code, and are supported by Google Native Client (NaCl). I think they will be exceedingly hard to beat when it comes to speed and loading time.
- Yoric 13y agoThey are fast, indeed. But by targeting NaCl, you are producing code that: - will only run on Chrome; - will only run on the hardware platforms for which you have developed. This kind of kills all the fun in the web. By contrast, asm.js code will run just about everywhere, today. And will get blazingly fast in ~12 weeks for Firefox (a little later for Chrome and Opera).
- ihnorton 13y ago> - will only run on the hardware platforms for which you have developed. What fast browser JITs are actively developed for platforms other than ARM, AMD64 and IA32? V8 does not support anything else, and while Firefox enables SpiderMonkey for MIPS and SPARC [1], "unsupported" is not a very hearty endorsement. https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#Platform_support https://developer.mozilla.org/en-US/docs/SpiderMonkey/1.8.8#...
- bzbarsky 13y agoSpiderMonkey works on PPC, for what it's worth; the TenFourFox project is actively maintaining it there. They're usually a bit behind on porting the JITs, but they do actively port them. But the real issue with NaCl is this thought experiment. Assume NaCl were developed in 1998 and everyone had jumped on that bandwagon and the web in 2003 were full of NaCl blobs targeting the hardware architectures that mattered in 2000-2001. Then ask yourself the following questions: 1) Would this have affected the choice of hardware for phones and tablets and whatnot? 2) Would it be viable today to ship a web browser on an ARM system? 3) What makes us think that the currently-relevant set of hardware architectures will still be the set we want to be using in 10-15 years? In 30 years? The nice thing about asm.js or PNaCl compared to NaCl is that even if we ship it right now and only run it right now on ARM/AMD64/IA32, if someone comes up with a new hardware architecture they want to ship in consumer devices they can simply implement a JS JIT for it (in the case of asm.js) or an LLVM backend (for PNaCl), which is something they would need to do _anyway_ for that "consumer devices" bit. On the other hand, if they have to deal with legacy NaCl content they suddenly have to do hardware emulation or something insane.