7 ms·

> NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. NaCL covers the only architectures that are likely to matter for phones and desktops fo

> NaCl is not portable. asm.js is. You should compare PNaCl and asm.js. NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. In doing so, it can support NEON, SSE, and other architecture-specific hardware features that make substantial differences in performance. So why shouldn't you compare NaCL to asm.js? PNaCL is there to cover the case where we move past ARM and x86, in which case it provides the ability to target new architectures from existing deployed code. In an ideal universe, sites would serve fat x86/arm/pnacl binaries, optimized for a given client.

hosay123 14y ago
We've already moved past ARM and x86: there's a bunch of MIPS Android tablets and phones on the market (just not in the West), and MIPS is extremely popular in home appliances (e.g. most LCD TVs). But this is besides the point. The real question is what the web will look like even 10 years from now, with a large installed base of arch-specific binaries everywhere. I don't want to have to explain to my kids why their browser requires the equivalent of a PDP11 emulator installed to watch certain classic movies and games.
- pifflesnort 14y ago
  We haven't moved past ARM and x86. Those two cover almost the entire mobile/tablet/desktop market. If there's a real MIPS resurgence outside of WiFi routers (eg, extremely cheap/low-quality tablets), then they can use PNaCL just fine until a native NaCL target is implemented. However, given the market weight behind ARM and x86, this seems extraordinarily unlikely to be used outside of some extreme edge players. IIRC, MIPS support isn't even mainlined into Android.
  - hosay123 14y ago
    Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures, one of which is a bitcode format that doesn't even run at native speeds, despite the name. I really love where this is going. [Edit] You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs, you have a totally separate offline manifest format that doesn't work like a regular web app, then you have 20 varieties of dumb formats pushed by a single company to advance its private for-profit agenda, when we already had all the vendor-neutral components openly specified, in place and deployed, that just needed some incremental improvement.
    - pifflesnort 14y ago
      > Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures 5 or 6? 2040? All we've seen over the past 20 years is the gradual reduction of in-use architectures down to a few winning players. We're even seeing it in the SoC/MCU space now, where custom architectures are being replaced with ARM. I expect to continue to see evolution and simplification, not revolution. If there is a revolution, well, we'll want to take advantage of the power of that fancy new hardware, I suppose. > one of which is a bitcode format that doesn't even run at native speeds, despite the name. PNaCL generates native code from the bitcode. [response to your edit] > You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. I would say that you're demonstrating why the web camp continues to fail so horribly to move past simple applications: you're so myopically focused on the ideology of tomorrow over providing a great user experience today. In fact, I day say you're leaving a far worse trail of destruction, because web applications are the ultimate expression of always-on DRM. When the servers for your "apps" disappear in a few years time, the applications will disappear right along with them -- forever. How is the Internet Archive going to archive your webapp? > You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs That's an overstatement of Pepper. It's quite simple -- far more so than the massive browser stack that WebGL+HTML5 brings with it. In fact, Pepper is simple and constrained enough that someone other than an existing browser vendor or major corporation could actually implement and support a standalone implementation of it. By contrast, producing a compatible browser is such an enormous undertaking that even companies like Opera are giving up and tracking WebKit.
      - bzbarsky 14y ago
        Last I checked, Pepper was full of underdefined stuff that depended on details of Chrome internals. So no, it's not "simple and constrained" enough that you can implement it without reverse-engineering said internals....
        14y ago
  - mtgx 14y ago
    I think there will be - maybe not at the ARM popularity level, or even x86's level, but it's been acquired by Imagination and I'm sure they have pretty big plans for it.
espadrine 14y ago
> why shouldn't you compare NaCL to asm.js? The portability limitations have made Google wait for PNaCl before it flips the switch to authorize NaCl apps on the Web by default. Note that I believe this choice is wise. I quote them: > This will… avoid the spread of instruction set architecture dependent apps on the web.
- pifflesnort 14y ago
  I agree that it's wise to default to a portable implementation. I also think it's wise to also have the option of serving up binaries that are optimized for the devices your users actually have, today.
dragonwriter 14y ago
> NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM. > PNaCL is there to cover the case where we move past ARM and x86 That, too, but more importantly, it exists to let you run the same code (delivered as LLVM bitcode) on supported platforms, including x86 and ARM, instead of having to deliver separately-compiled code for each supported platform, as is the case for NaCl. That's what the "P" ("Portable") is about -- the code delivered runs on any PNaCl engine, unlike the case with NaCl where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM. You seem to have confused what PNaCl does now (experimental toolchain inside the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe bitcode to native code piece of the toolchain from the SDK side into the client side, so all you deliver to the client is the platform-agnosti .pexe rather than the platform-specific .nexe.)
- pifflesnort 14y ago
  > This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM. I didn't intend for this to be misleading -- the option to deploy code specific to each architecture is a benefit. It means you can take advantage of the architecture's specific features (such as NEON and SSE).
  - dman 14y ago
    The phase that the web camp is in currently reminds me of a brief phase with Java in the 90's where everything was going to be rewritten on top of the JVM and all heterogeneity in computing stacks was going to disappear overnight.
  - dragonwriter 14y ago
    > I didn't intend for this to be misleading -- running code specific to each architecture is a benefit. Permitting it may be a benefit in some cases, Being limited to it, as NaCl is until client-side PNaCl is ready, is a disadvantage. Which is why Google is not enabling NaCl by default on the web (i.e., outside of the Chrome Web Store) until client-side PNaCl is ready -- they don't want needless proliferation of non-portable NaCl code on the web. And, I suspect, they want to make the .pexe-to-.nexe process as efficient, in terms of code generation, as possible, so as to minimize the scope of cases where specific-platform-targetting is necessary.

hosay123 14y ago

We've already moved past ARM and x86: there's a bunch of MIPS Android tablets and phones on the market (just not in the West), and MIPS is extremely popular in home appliances (e.g. most LCD TVs). But this is besides the point. The real question is what the web will look like even 10 years from now, with a large installed base of arch-specific binaries everywhere. I don't want to have to explain to my kids why their browser requires the equivalent of a PDP11 emulator installed to watch certain classic movies and games.

pifflesnort 14y ago
We haven't moved past ARM and x86. Those two cover almost the entire mobile/tablet/desktop market. If there's a real MIPS resurgence outside of WiFi routers (eg, extremely cheap/low-quality tablets), then they can use PNaCL just fine until a native NaCL target is implemented. However, given the market weight behind ARM and x86, this seems extraordinarily unlikely to be used outside of some extreme edge players. IIRC, MIPS support isn't even mainlined into Android.
- hosay123 14y ago
  Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures, one of which is a bitcode format that doesn't even run at native speeds, despite the name. I really love where this is going. [Edit] You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs, you have a totally separate offline manifest format that doesn't work like a regular web app, then you have 20 varieties of dumb formats pushed by a single company to advance its private for-profit agenda, when we already had all the vendor-neutral components openly specified, in place and deployed, that just needed some incremental improvement.
  - pifflesnort 14y ago
    > Right, so by 2040 we can't distribute an application without rebuilding it for 5 or 6 different architectures 5 or 6? 2040? All we've seen over the past 20 years is the gradual reduction of in-use architectures down to a few winning players. We're even seeing it in the SoC/MCU space now, where custom architectures are being replaced with ARM. I expect to continue to see evolution and simplification, not revolution. If there is a revolution, well, we'll want to take advantage of the power of that fancy new hardware, I suppose. > one of which is a bitcode format that doesn't even run at native speeds, despite the name. PNaCL generates native code from the bitcode. [response to your edit] > You're basically demonstrating the entire problem with the Native Client camp - you're so myopically focused on the immediate needs and the immediate environment (arm! x86! games! performance this year!) that you have absolutely no appreciation for the trail of destruction being left for future generations. I would say that you're demonstrating why the web camp continues to fail so horribly to move past simple applications: you're so myopically focused on the ideology of tomorrow over providing a great user experience today. In fact, I day say you're leaving a far worse trail of destruction, because web applications are the ultimate expression of always-on DRM. When the servers for your "apps" disappear in a few years time, the applications will disappear right along with them -- forever. How is the Internet Archive going to archive your webapp? > You have Pepper which is a huge bastardized, specialized clone of all WebGL/HTML 5 audio/media APIs That's an overstatement of Pepper. It's quite simple -- far more so than the massive browser stack that WebGL+HTML5 brings with it. In fact, Pepper is simple and constrained enough that someone other than an existing browser vendor or major corporation could actually implement and support a standalone implementation of it. By contrast, producing a compatible browser is such an enormous undertaking that even companies like Opera are giving up and tracking WebKit.
    - bzbarsky 14y ago
      Last I checked, Pepper was full of underdefined stuff that depended on details of Chrome internals. So no, it's not "simple and constrained" enough that you can implement it without reverse-engineering said internals....
      - 14y ago
- mtgx 14y ago
  I think there will be - maybe not at the ARM popularity level, or even x86's level, but it's been acquired by Imagination and I'm sure they have pretty big plans for it.

espadrine 14y ago

> why shouldn't you compare NaCL to asm.js? The portability limitations have made Google wait for PNaCl before it flips the switch to authorize NaCl apps on the Web by default. Note that I believe this choice is wise. I quote them: > This will… avoid the spread of instruction set architecture dependent apps on the web.

pifflesnort 14y ago
I agree that it's wise to default to a portable implementation. I also think it's wise to also have the option of serving up binaries that are optimized for the devices your users actually have, today.

dragonwriter 14y ago

> NaCL covers the only architectures that are likely to matter for phones and desktops for the next 5+ years: ARM and x86. This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM. > PNaCL is there to cover the case where we move past ARM and x86 That, too, but more importantly, it exists to let you run the same code (delivered as LLVM bitcode) on supported platforms, including x86 and ARM, instead of having to deliver separately-compiled code for each supported platform, as is the case for NaCl. That's what the "P" ("Portable") is about -- the code delivered runs on any PNaCl engine, unlike the case with NaCl where NaCl x86 code runs only on x86 and NaCl ARM code only on ARM. You seem to have confused what PNaCl does now (experimental toolchain inside the NaCl SDK), and what the point of PNaCl is (to move the .pexe -> .nexe bitcode to native code piece of the toolchain from the SDK side into the client side, so all you deliver to the client is the platform-agnosti .pexe rather than the platform-specific .nexe.)

pifflesnort 14y ago
> This is misleading. NaCl exists for both these platforms, but it doesn't support running the same code on each; NaCl lets you run native x86-compiled code on x86 and native ARM-compiled code on ARM. I didn't intend for this to be misleading -- the option to deploy code specific to each architecture is a benefit. It means you can take advantage of the architecture's specific features (such as NEON and SSE).
- dman 14y ago
  The phase that the web camp is in currently reminds me of a brief phase with Java in the 90's where everything was going to be rewritten on top of the JVM and all heterogeneity in computing stacks was going to disappear overnight.
- dragonwriter 14y ago
  > I didn't intend for this to be misleading -- running code specific to each architecture is a benefit. Permitting it may be a benefit in some cases, Being limited to it, as NaCl is until client-side PNaCl is ready, is a disadvantage. Which is why Google is not enabling NaCl by default on the web (i.e., outside of the Chrome Web Store) until client-side PNaCl is ready -- they don't want needless proliferation of non-portable NaCl code on the web. And, I suspect, they want to make the .pexe-to-.nexe process as efficient, in terms of code generation, as possible, so as to minimize the scope of cases where specific-platform-targetting is necessary.