Hacker News Reader

Comment by kayoone | Hacker News Reader

As a game developer i was pretty excited about Native Client when i first heard about it in 2010, and PNaCL is definately nice.

However, nowadays asm.js + emscripten seem to be the right direction and Google should adopt it.

View on HN

PNaCL seems like a much saner stack, turning JS into assembly never made sense to me if you want to get the most out of the hardware (with resulting power savings and/or performance gains).

To be fair, asm.js isn't really JS. It's more like a low-level DSL. The fact that it happens to be a subset of JS is just a convenience for backwards compatibility.

At any rate, from the perspective of the developer, it doesn't really make a difference. Either way, developers are interacting with a C/C++ compiler, not directly with the browser engine.

It's the same interface for the developer, but instead of being run directly on the CPU, it's run in a JavaScript virtual machine that interprets it or eventually compiles it to some kind of native code. That's very hard to overcome from a performance standpoint.

asm.js is translated into native code before it's run, which is exactly the same as PNaCL, which is delivered in a non-executable format that has to be translated to the native architecture before it's run. The two technologies are just different standards for the exact same underlying idea.

Except LLVM bitcode seems much more able to expose the cabilities of the underlying CPU compared to asm.js. I guess we'll just have to wait to see what the benchmarks say.

PNaCL doesn't "run directly on the CPU" any more than asm.js. They are both intermediate formats that must be compiled locally.

I don't know what the difference between running "directly on the CPU" and "compiling to some kind of native code" is. If you mean that the Web page delivers raw machine code to the browser, that describes NaCl, not PNaCl.

Regardless, it is incorrect that asm.js is first interpreted before being compiled. asm.js is compiled ahead of time exactly as PNaCl is.

This doesn't sound right. It's a subset of javascript, you are still shipping javascript to the browser... which is then parsed and then jitted in said browser. Which is an extra step above bitcode, where you just jit it as is. Albeit it's specifically crafted to be easier to optimize but it is still javascript that you are sending to the browser.

I feel like someone is trying too hard to make javascript into something it isn't and shouldn't be. Javascript does it's thing pretty well, why is there no room for other tools in the toolbox?

I doubt parsing and validating ascii asm.js is much more work than parsing and validating binary llvm.

I call Bullshit.

https://github.com/dherman/asm.js/tree/master/lib is about 1,500 lines of code.

The contents of Bitcode/Reader/ in LLVM are about 3,000 lines of code alone, and that does not include the definition of LLVM data structures, the validator, etc.

No it's not. asm.js, like PNaCl, uses ahead-of-time compilation.

I fear the limitation that it has to be a subset of JS must lead to performance trade-offs, through the lack of 64-bit integer types or single precision floating point / SIMD vector arithmetic for instance.

This is not a fundamental limitation of asm.js. For example, there is already an extension introduced for compiled code that can be optionally used for improved performance: Math.imul. Similar extensions can be introduced later.

With the trade off that the code size is greatly increased and that the performance when falling back to pure JavaScript will be dog slow. If the performance of an application is only acceptable on the subset of browsers that implement asm.js then the portability advantage over PNaCL isn't worth that much.

The only actual numbers I've seen, from emscripten author Alon Zakai, show gzipped minified emscripten JS output as comparable in size to gzipped native code:

http://mozakai.blogspot.com/2011/11/code-size-when-compiling...

> With the trade off that the code size is greatly increased

http://mozakai.blogspot.com/2011/11/code-size-when-compiling...

> If the performance of an application is only acceptable on the subset of browsers that implement asm.js then the portability advantage over PNaCL isn't worth that much.

The Unreal Engine demo has proven that, even for games, these limitations don't result in "dog slow" performance on browsers that don't support asm.js.

The Unreal Engine demo does pretty much all of its work on the GPU.

> At any rate, from the perspective of the developer, it doesn't really make a difference.

Not true at all. Now we don't have to postprocess the LLVM into javascript and deal with the pain of debugging completely unreadable bitcode.

Unfortunately there are a number of downsides which will inhibit cross browser adoption and standardisation. I would view NaCL and PNaCL less for the open web, and more an attempt to position Chrome as a replacement for Desktop OS / application platforms.

PPAPI, and LLVM are not necessarily suitable for cross browser adoption or standardisation. LLVM is a single implementation and so like SQLite, its likely it would not be accepted. It is also not particularly architecture independent nor language agnostic. Low latency polyglot JIT is an open research area on LLVM.

PPAPI is a single vendors view on a suitable API. It focuses on a single vendors needs. The track record isn't there.

I think in the long run we're all better off if they fight it out and see who wins on the technical merits in the end. In the meantime, just make sure the native code you're writing can target either/or and serve the right version based on browser detection.

They can't fight it out on technical merits if nobody will adopt PNaCl due to some (real or perceived) Google lockin.

Reply on news.ycombinator.com