4 ms·

> By that argument any JS JIT is "no longer JS". JS JIT is an internal implementation detail. If a JIT exposed its internal bytecode (assuming it has one), you

> By that argument any JS JIT is "no longer JS". JS JIT is an internal implementation detail. If a JIT exposed its internal bytecode (assuming it has one), you certainly wouldn't call it JavaScript. asm.js's strict requirements expose that implementation detail. To make asm.js useful, you can't treat it as JS, in which case the fact that it's javascript is a pointless burden on the entire target community of developers and users. > Those are not portable, which JS must be. Users don't care about whether a particular application uses non-portable optimization strategies, they care about battery life and application performance. If that means I have to use NEON on ARM, SSE on x86, and provide a portable fallback implementation, then so be it -- as a developer, that's my job. As a platform/OS vendor, your job is to make it possible for me to provide the best available user experience on the market. This isn't the web development space; we can't just tell users to go get faster hardware, the way web developers tell IT to go get faster/bigger servers. > PNaCl will of course have the same issues asm.js does with not having direct binaries that can just be loaded and run, not allowing use of CPU-specific code, etc. You can target x86 and ARM specifically (which are likely to be the only architectures that matter for the next 5 years), and fallback to PNaCL for everyone else. > If you don't care for portability, then the web/JS/asm.js/WebGL/etc etc. are likely not the best thing for you. I don't care about sacrificing user experience for some irrational slavish devotion to JavaScript. Of course I want portability, but not at the cost of providing the best user experience on the market.

azakai 14y ago
> JS JIT is an internal implementation detail asm.js optimizations are also an internal implementation detail. You don't need to do them, and the code still runs fast. Or you can do them in a variety of ways, not just the one being tested in Firefox. In fact I argued for optimizing in a very different way originally. The point of asm.js is that it ensures you don't do things like use multiple types in a single variable, avoid undefined values cropping up, etc. That helps JS JITs in general, both existing ones as well as new optimizations made more feasible by the approach. So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > Users don't care about whether a particular application uses non-portable optimization strategies Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. > You can target x86 and ARM specifically (which are likely to be the only architectures that matter for the next 5 years), and fallback to PNaCL for everyone else. That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you.
- pifflesnort 14y ago
  > asm.js optimizations are also an internal implementation detail. Come on, really? If you require a full spec to define a very specific format, type annotations, and special designators to actually take advantage of it in any meaningful way, it's not an "implementation detail", because as the user, I have to care about it. > So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). That's exposing implementation details, too, and demonstrates a failing of JS. > Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. Users want apps to run, and run well. They don't care how. Figuring out how is our job. Making user's lives suck more because we have lofty ideas is not doing our job. Apple gets it. Google gets it. Even Ubuntu gets it. Mozilla doesn't get it. > That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. Not really. Apple and NeXT navigated these waters successfully for multiple decades via Mach-O and CFM fat binaries, and toolchains built around easily and efficiently supporting multiple architectures. > But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you. The web is competing with native applications. Now you're trying to compete with native operating systems, yet you're not willing to take the steps necessary to actually compete. Ultimately, you're creating a two tier systems where platform vendors like yourself get decent performance and runtime environments in which you can produce things like Firefox, and 3rd party developers get crappy performance and runtimes environments where we can produce webapps. I'd love to see you write and deploy Firefox in asm.js, and then try to compete with Chrome.
  - azakai 14y ago
    > Come on, really? If you require a full spec to define a very specific format, type annotations, and special designators to actually take advantage of it in any meaningful way, it's not an "implementation detail", because as the user, I have to care about it. First of all, it doesn't require a spec. We could have just done some heuristical optimizations like all JS engines have been doing since 2008, finding more cases where we can optimize and so forth - in fact, this was my initial idea for how to do this, as I mentioned earlier. But we did decide to write a spec because (1) we want to be 100% open about this, and a spec makes it easier for others to learn about it, and (2) it helps us check we didn't miss anything because we have a formal type system. >> So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > That's exposing implementation details, too, and demonstrates a failing of JS. If so, then that exposes a failing of all JITs, including the JVM. All optimizing implementations expose details. People have optimized for the JVM for years. If you can't stand anything between you and the underlying CPU, then nothing portable (like JavaScript, C#, Java, etc.) will satisfy you. Actually even a CPU might not, because CPUs also optimize in unpredictable ways, these same issues are dealt with on that level too. Again, there is room for native apps. But there is also room for portable, standards-based apps. The web is the latter. > Apple and NeXT navigated these waters successfully for multiple decades via Mach-O and CFM fat binaries, and toolchains built around easily and efficiently supporting multiple architectures I do see your point, but that isn't quite the same. Apple fat binaries were of a platform Apple controlled. We are talking about the web, which no one controls. But again, yes, to some degree it is possible as you say to overcome such issues. > The web is competing with native applications. Now you're trying to compete with native operating systems, yet you're not willing to take the steps necessary to actually compete. I disagree. If we have 2x slower than native now, and 1.5x slower than native later on, we're competitive with native on that front. And we have some advantages over native, like portability, which can have long-term performance advantages (for example, we can easily switch to a different underlying CPU if a faster arch shows up). There are also short-term performance advantages to things like Firefox OS that only run web apps, like their graphics stack being much simpler than Android's or Linux's (you don't need another layer underneath the browser compositor, and can go right into GL).
pcwalton 14y ago
If x86 and ARM become the favored platforms for full speed on the Web, as you've essentially locked the Web into those architectures for all time. Web developers will realistically not optimize the PNaCl solution. I disagree that this is worth the cost. This is not about "a slavish devotion to JavaScript"; your solution is fundamentally opposed to portability.
- pifflesnort 14y ago
  > Web developers will realistically not optimize the PNaCl solution. It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that. > I disagree that this is worth the cost. This is not about "a slavish devotion to JavaScript"; your solution is fundamentally opposed to portability. Users want applications that don't waste their battery, and that perform well. What do they care about architecture portability beyond the devices they actually have? Fortunately, PNaCL solves that problem, too, as a fallback, while still being able to target x86/ARM without compromise.
  - pcwalton 14y ago
    "It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that." I haven't seen PNaCl benchmarks. Have you? It is true that the compilers for asm.js are more immature than LLVM at this time, but there's nothing stopping asm.js from reaching that level. Again, it's just syntax. You're complaining about the fact that the code is delivered in a backwards compatible surface syntax and extrapolating that to unfounded assumptions that it must be slow. It's really an absurd claim.

azakai 14y ago

> JS JIT is an internal implementation detail asm.js optimizations are also an internal implementation detail. You don't need to do them, and the code still runs fast. Or you can do them in a variety of ways, not just the one being tested in Firefox. In fact I argued for optimizing in a very different way originally. The point of asm.js is that it ensures you don't do things like use multiple types in a single variable, avoid undefined values cropping up, etc. That helps JS JITs in general, both existing ones as well as new optimizations made more feasible by the approach. So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > Users don't care about whether a particular application uses non-portable optimization strategies Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. > You can target x86 and ARM specifically (which are likely to be the only architectures that matter for the next 5 years), and fallback to PNaCL for everyone else. That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you.

pifflesnort 14y ago
> asm.js optimizations are also an internal implementation detail. Come on, really? If you require a full spec to define a very specific format, type annotations, and special designators to actually take advantage of it in any meaningful way, it's not an "implementation detail", because as the user, I have to care about it. > So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). That's exposing implementation details, too, and demonstrates a failing of JS. > Of course users do. A portable application would be runnable from all the users' devices, that's a huge plus. Just like users want to play their music from their iPod, laptop, TV, etc., they want to run their apps on all their devices as well. Portability makes that possible. Users want apps to run, and run well. They don't care how. Figuring out how is our job. Making user's lives suck more because we have lofty ideas is not doing our job. Apple gets it. Google gets it. Even Ubuntu gets it. Mozilla doesn't get it. > That's a big compromise. If we had done that before the rise of ARM, for example, ARM might never have achieved its current success. Not really. Apple and NeXT navigated these waters successfully for multiple decades via Mach-O and CFM fat binaries, and toolchains built around easily and efficiently supporting multiple architectures. > But anyhow, of course there are different compromises to be made. The web and JS focus on true portability, with its downsides. If you personally are willing to compromise more to get better performance, then sure, another option might be better for you. The web is competing with native applications. Now you're trying to compete with native operating systems, yet you're not willing to take the steps necessary to actually compete. Ultimately, you're creating a two tier systems where platform vendors like yourself get decent performance and runtime environments in which you can produce things like Firefox, and 3rd party developers get crappy performance and runtimes environments where we can produce webapps. I'd love to see you write and deploy Firefox in asm.js, and then try to compete with Chrome.
- azakai 14y ago
  > Come on, really? If you require a full spec to define a very specific format, type annotations, and special designators to actually take advantage of it in any meaningful way, it's not an "implementation detail", because as the user, I have to care about it. First of all, it doesn't require a spec. We could have just done some heuristical optimizations like all JS engines have been doing since 2008, finding more cases where we can optimize and so forth - in fact, this was my initial idea for how to do this, as I mentioned earlier. But we did decide to write a spec because (1) we want to be 100% open about this, and a spec makes it easier for others to learn about it, and (2) it helps us check we didn't miss anything because we have a formal type system. >> So asm.js does not expose any implementation details, no more than say CrankShaft and TraceMonkey do in the documents written about "how to write fast JS for modern JS engines" (which often say explicit things about "don't mix types" and so forth). > That's exposing implementation details, too, and demonstrates a failing of JS. If so, then that exposes a failing of all JITs, including the JVM. All optimizing implementations expose details. People have optimized for the JVM for years. If you can't stand anything between you and the underlying CPU, then nothing portable (like JavaScript, C#, Java, etc.) will satisfy you. Actually even a CPU might not, because CPUs also optimize in unpredictable ways, these same issues are dealt with on that level too. Again, there is room for native apps. But there is also room for portable, standards-based apps. The web is the latter. > Apple and NeXT navigated these waters successfully for multiple decades via Mach-O and CFM fat binaries, and toolchains built around easily and efficiently supporting multiple architectures I do see your point, but that isn't quite the same. Apple fat binaries were of a platform Apple controlled. We are talking about the web, which no one controls. But again, yes, to some degree it is possible as you say to overcome such issues. > The web is competing with native applications. Now you're trying to compete with native operating systems, yet you're not willing to take the steps necessary to actually compete. I disagree. If we have 2x slower than native now, and 1.5x slower than native later on, we're competitive with native on that front. And we have some advantages over native, like portability, which can have long-term performance advantages (for example, we can easily switch to a different underlying CPU if a faster arch shows up). There are also short-term performance advantages to things like Firefox OS that only run web apps, like their graphics stack being much simpler than Android's or Linux's (you don't need another layer underneath the browser compositor, and can go right into GL).

pcwalton 14y ago

If x86 and ARM become the favored platforms for full speed on the Web, as you've essentially locked the Web into those architectures for all time. Web developers will realistically not optimize the PNaCl solution. I disagree that this is worth the cost. This is not about "a slavish devotion to JavaScript"; your solution is fundamentally opposed to portability.

pifflesnort 14y ago
> Web developers will realistically not optimize the PNaCl solution. It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that. > I disagree that this is worth the cost. This is not about "a slavish devotion to JavaScript"; your solution is fundamentally opposed to portability. Users want applications that don't waste their battery, and that perform well. What do they care about architecture portability beyond the devices they actually have? Fortunately, PNaCL solves that problem, too, as a fallback, while still being able to target x86/ARM without compromise.
- pcwalton 14y ago
  "It'll be "fast enough", which is what you're claiming for asm.js's backwards compatibility mode, and PNaCL is a whole heck of a lot faster than that." I haven't seen PNaCl benchmarks. Have you? It is true that the compilers for asm.js are more immature than LLVM at this time, but there's nothing stopping asm.js from reaching that level. Again, it's just syntax. You're complaining about the fact that the code is delivered in a backwards compatible surface syntax and extrapolating that to unfounded assumptions that it must be slow. It's really an absurd claim.