Google Native Client - Part 1 | Hacker News Reader

Google Native Client - Part 1

blog.leafsr.com

40 pointswglb26 comments

Google should be pushing Portable Native Client, not plain Native Client, which is by implication Non-Portable. NaCl solves Google's problems, but is a damaging standard for the rest of us.

Nobody should be pushing CPU architecture specific executables as a web standard. Yes, you can compile is for x86 and ARM, but that's incredibly short-sighted. What about PPC? MIPS? Some future architecture that hasn't been invented yet? Do we have to make a virtual machine then? Yes, you can also compile as LLVM bitcode, but then why give prejudicial preference to x86-32 and ARMv5? (Note the specific versions there) You might as well just ship as PNaCl and skip NaCl altogether.

PNaCl is an amusing evolution of web scripting: we've come full circle from a JVM thru Javascript back to a solution which is almost a JVM. To be cynical, it seems like an awfully huge project just to avoid writing Java.

Heck — we're already having enough pain as Typed Arrays expose system endianness to the web platform. Most scripts using Typed Arrays are already broken on big endian systems, and it's practically inevitable that Typed Arrays are going to have to convert endianness dynamically to appear little endian.

FWIW, LLVM offers other advantages over a JVM, such as letting you not have to use things like garbage collection and strict typing (as in, you can have arrays of random garbage that you type cast back/forth through structures and unions; that's all allowed in LLVM, and all considered safe by way of PNaCl AFAIK, as it doesn't care whether your program works or fails, only that it doesn't escape).

Native Client Adoption by all browsers would be awesome for the gaming market and would also provide alternatives to Javascript, which many people would like i guess.

In the short term, sure. But since NaCl doesn't run on all CPUs and is not standardized, it would lead to problems in the long run.

Regarding alternatives to JavaScript, you can compile pretty much any language into a form that can run on the web, right now: C++, C#, Java, etc. (That form happens to be JavaScript.)

> But since NaCl doesn't run on all CPUs

The PNaCl project[1] aims to distribute LLVM bitcode, solving this problem. You also gain the advantage that all programs can be JITed to exactly your processor spec.

[1] http://www.chromium.org/nativeclient/pnacl

It aims to do that. It isn't finished and it is not clear what the final product will look like in terms of portability and performance.

I would really like to see that all NaCl apps have to ship at least a PNaCl binary (and possibly ARM as well). Browsers should verify this and refuse to run apps that are x86 only.

If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary).

Also it's certainly an improvement over native plugins that not only lack a sandbox, but are also tied to the OS in addition to the CPU. In fact, I suggest that browsers should adopt NaCl at least for plugins, maybe even allowing unrestricted access to the file system, camera, etc. and gradually phase out conventional plugins. Even without the security benefit this still gives us portable plugins.

> If all NaCl apps would contain PNaCl/x86/ARM binaries I don't see a disadvantage compared to compiling other languages down to JavaScript (which is just as unreadable/proprietary).

Even if PNaCl worked today, and even if it gave good performance and portability, it would still not be standardized. The only way to get PNaCl into a new browser would be to use the current implementation (which defines what it is).

Having that implementation open source is a good thing. But it isn't as good as JavaScript which has a standard and multiple independent implementations. If you want to write a JS engine in Haskell, for example, you can do that. You can't do that with NaCl or PNaCl, you must use the existing code as is.

So write another new implementation? That's like saying (the first JS engine) is the only one that exists, so every other browser must also use it.

There is a standard for JavaScript, a spec to implement. And new features in the JS language evolve out of a standards process that involves all the browser makers (as well as others). As a result, you can write a new implementation of it, and people do.

There is no standard or spec for NaCl, PNaCl or PPAPI. Those things are still being developed, and they change a lot (talk to people that develop for that API to get an idea of how things can change with each 6-week update of Chrome). To implement those, you need to basically "do what Google's implementation does." Trying to track that large and complex - and changing - implementation is practically impossible.

PNaCl targets LLVM bitcode, so can be supported on any modern CPU: http://www.chromium.org/nativeclient/pnacl/building-and-test...

Compiling other languages to JavaScript imposes an unacceptable speed penalty. C++-to-JavaScript is not a viable platform for real applications, especially anything performance-critical.

See comments below - PNaCl is not finished, and we don't know what performance and portability it will provide when it is. It is also not close to being standardizable since it is in flux.

Do you have numbers for the "unacceptable speed penalty" JavaScript imposes on compiled code? That's an honest question, I am curious to see benchmarks about that.

Except, of course, LLVM bitcode isn't meant to be distributed: it's designed as a compiler IR, and merely an intermediary form. It's also not portable: the existence of types like x86_fp80 and ppc_fp128 make this quite clear.

Yes, and it also implicitly includes assumptions on endianness, stack size, alignments, etc. It is very hard to make it portable.

It's a great compiler IR though! This isn't a criticism of LLVM bitcode.

I suggest reading the PNaCl paper, which addresses how they make LLVM bitcode distributable and portable. Because believe it or not, they have thought about these problems, and solutions to them have been designed and implemented.

It's not a force-fit either. LLVM is designed to be a form from which machine-specific code is generated. The problem is only that different platforms have different conventions. But any modern 32-bit platform can use a given set of conventions if you want it to.

C++ to JavaScript.

That won't be hell to debug.

emscripten already exists and has a lot of... frankly unbelievably amazing demos to show for it.

It is actually easier to debug than C++ to x86 in my experience.

Better not. It's giving too much power to the browser, and it's just reinventing native apps

Giving too much power to the browser? What does that even mean? Native Client runs in a very similar sandbox as JavaScript, so the only extra "power" it has is the ability to run faster. Why could it possibly be bad for the browser to be faster?

This is impressive, it would be nice when people adopt that, I wonder if we could make a python for browser out of it.

I know that the Mono C# is now supported. I think it's due to its LLVM support. So basically, any language that supports LLVM JIT can be used with NaCl.

I could be wrong, but I remember reading about it somewhere. Either way, it is pretty cool technology of which nobody else seems to want to support. Which is too bad, really.

Yes, but Google contributed a huge patch to Mono to make it work, making changes in the runtime all over the place. So LLVM is not the reason, at least not in this case.

Maybe there is also a NaCl backend for LLVM, I don't know ...

Yes, I believe it is called PNaCl. It uses LLVM as its back end.

edit: I suppose a link should be presented.

http://www.chromium.org/nativeclient/pnacl/building-and-test...

Last time I did a web search for how to write something for Google Chrome in a language other than Javascript I found nothing.

Where is the "hello world" for writing a plugin/chrome-app in some other language?

Reply on news.ycombinator.com