Google launches Portable Native Client

http://thenextweb.com/google/2013/11/12/google-launches-portable-native-client-lets-developers-compile-code-run-hardware-site/

by hackhackhack • 13 years ago

125 111 13 years ago

thenextweb.com

bdfh42• 13 years ago

So sort of .NET for Chrome? Cool. I like the language agnostic approaches we are seeing these days.

pritambaral2• 13 years ago

Does this abstraction of native OS environments mean lesser supported platforms like Linux will see more apps? Of course, only if the app dev decides to port it to PNaCl.

One thing I am concerned about is, since PNaCl is essentially yet another platform, how Google (or anyone) is going to manage the host of supporting tools required. Tools like dependency management, libraries, process control etc.

By the way, Google has already proven their "platform-creation" skills with Android.

geofft• 13 years ago

I think NaCl is already portable across different OSes on the same architecture, since it exposes its own API.

The new part of PNaCl is that you don't have to recompile for each target architecture. Among other things, if they push hard for this for desktop developers on the Chrome App Store, then suddenly they have a large number of things that work on Chromebooks without demanding that developers recompile.

pritambaral2• 13 years ago

You are right. But even with NaCl, the original question remained: would a game dev compile an NaCl app for Linux (even though code changes weren't required.)

PNaCl eliminates a dev's actions to recompile.

cbhl• 13 years ago

I'm under the impression that once a game dev compiled for NaCl x86/x86_64 at all, it ran on all of the Chrome binaries on x86/x86_64, i.e. Mac, Windows, Linux, and Chromebook.

There are already a few games on NaCl, like Don't Starve[0] that work on x86/x86_64-based chromebooks. They just don't run on ARM-based chromebooks -- which is one of the incentives for PNaCl.

IIRC, NaCl could only run in Chrome Web Apps precisely because it was platform-dependent. It looks like PNaCl will also allow ActiveX/Flash-style embedding.

[0] http://www.dontstarvegame.com/

jmpe6• 13 years ago

This could also be a fertile pasture for distributed computing on the fly. Suppose you have a website that attracts 1k visitors per day on chrome, how many MIPS could you harvest? Could you let them mine bitcoins or fold proteins in the background without attracting attention?

eliben9• 13 years ago

How is this different from existing client-side JavaScript code? PNaCl is significantly faster than JS, but conceptually it's similar - you can run code on the user's machine.

jmpe6• 13 years ago

The "significantly faster" is your answer. A 10 second visit on JS vs PNaCl is a whole new game.

Edit: to elaborate: do a simple simulated annealing on a 200x200 array in JS - it's measured in seconds on my laptop. I wrote a program in JS that did this (image segmentation, fg/bg seperation for recognition) and abandoned it because of speed issues.

adrianmalacoda2• 13 years ago

I sure hope this doesn't become a thing, and if it does, that existing ad blocking and/or anti-malware tools pick it up and warn the user against it.

When you start appropriating other peoples' computers for your own purposes, secretly, without their approval, that's called a bot net.

jmpe6• 13 years ago

yeah, but think of the pro: "you can help pay for this website by pressing this button and leaving this window open for an hour". You could help SETI by just visiting a URL.

By fertile pasture I mean that both malevolent and benevolent communities will support this. This could see a lot of optimization if open sourced (is it?).

egeozcan2• 13 years ago

Bandwidth may be a problem then. I mean, your gains in mining would be seriously hurt by the bandwidth costs. Also, if more people start mining this way, there will be more competition and your earnings will decline. There's also the case of some users maliciously feeding you false results. So you'll have to introduce redundancy to the system (I'm not sure if you get punished for false results apart from simply not getting paid though).

Procrastes3• 13 years ago

My guess is this gives Google a clear migration path away from Java to a unified Chrome OS for phone, tablet, notebook etc. PNaCl could coexist with Android apps until Google finally phases Java out.

efuquen• 13 years ago

Am I missing something here, when was this about Java and phasing it out of Android? I don't think that's a likely plan but if you have any evidence to the contrary I would love to see it. Java is pretty pretty central to Android to think that it's somehow going to be "phased out", that would be more like destroying the entire platform.

I know everyone loves to hate on Java, but I'm always amazed by some of the wacky things people say ...

_random_5• 13 years ago

Maybe a new virtual machine along with a high-level language will magically materialize out of thin air? GoVM perhaps, that was secretly being developed all this time?

Procrastes3• 13 years ago

I really don't hate Java at all. It's had a generally beneficial impact in all sorts of places. But I wonder with the change-over in leadership for Android[1] if we aren't seeing signals that Google wants to consolidate all of its apps under Chrome. One possible motivation is that they may not want to leave a core technology under the control of Oracle forever.

1. http://thenextweb.com/google/2013/07/17/google-is-holding-a-...

CookWithMe• 13 years ago

Using the NDK [1], an Android app can already run C/C++ code. If Google really wanted to phase out Java (where did that come from anyway?), the biggest task is to port the whole SDK, especially the UI, and not to run C code.

[1] http://developer.android.com/tools/sdk/ndk/index.html

_random_5• 13 years ago

You probably wanted to say JVM. Please read some Wikipedia for background info before posting.

Procrastes3• 13 years ago

Nope. I said what I meant. Java is alot of things. I was talking about all of them. I used to be part of Sun's Java Center.

egeozcan2• 13 years ago

One day, I will be able to compile my golang apps to work on browsers without losing considerable performance, multiple threads and concurrency. That day, I'll be very happy.

eliben9• 13 years ago

You'll be interested in this project, then: http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-p...

It's important to emphasize that PNaCl is a platform. We currently provide front-ends for C and C++, but nothing prevents you from writing your own, for your own language (or an existing one). As long as you emit PNaCl bitcode, Chrome will run it for you. The PNaCl bitcode has a definition here - https://developers.google.com/native-client/dev/reference/pn... - and we're working on making it more precise.

Touche3• 13 years ago

Working on a PNaCl spec or did I miss it and that was released too?

_random_5• 13 years ago

Native in-browser CLR, JVM and LLVM support would be the best world to live.

stonemetal• 13 years ago

I don't know that sounds like a very large surface to secure.

pjmlp6• 13 years ago

One day, I will be able to compile my golang apps to work on browsers without losing considerable performance, multiple threads and concurrency. That day, I'll be very happy.

One day, the browser will be used again just for documents. That day, I'll be very happy.

adamb_• 13 years ago

Is this how Google plans to bridge the JS performance gap to get web apps running at "native" speeds?

dragonwriter4• 13 years ago

It's one of several approaches in that direction. Google's not particularly shy about pursuing multiple approaches in parallel for important priorities.

mtgx• 13 years ago

They sure took their sweet time. Didn't say they it was supposed to arrive like a year ago? NaCl should've worked on ARM from day one.

Refefer• 13 years ago

How does PNaCl differ beyond intermediate representation from asm.js? They both seem to focus on providing cross compiling into a browser environment with the latter already having compatibility across the entire set of javascript interpreters. What does it offer that hasn't somewhat been solved?

Filligree• 13 years ago

Using the LLVM toolchain, thus probably better performance and language support?

I'd like to see the benchmarks before assuming that, but if this leads to letting me use Haskell in the browser, I'll be all over it.

mccr82• 13 years ago

Most asm.js is generated using Emscripten, which is also based on LLVM. I guess the backend optimizations will be different.

eliben9• 13 years ago

The PNaCl bitcode can serve as the output of any compiler. Google currently provides toolchains for C and C++, but folks have been working on Go ports, Lua, Python etc. Haskell, in fact, already has a LLVM backend so porting that to emit PNaCl bitcode should not, in theory, be overly hard.

mccr82• 13 years ago

At the moment, PNaCl supports pthreads-style threads and asm.js does not.

Also, Native Client, but apparently not PNaCl, supports SIMD, while asm.js does not.

Of course, both PNaCl and asm.js are evolving, so asm.js may be able to eventually support those features somehow, and PNaCl may get additional features.

Some information about features PNaCl supports are here: https://developers.google.com/native-client/dev/faq

dragonwriter4• 13 years ago

They are basically approaching the same problem from two different directions (PNaCl is the older project, despite having a later stable release; asm.js was a response to PNaCl.)

EDIT: And pepper.js is essentially a response back to asm.js and its "run, albeit with less performance optimization, on any modern JS engine".

azakai5• 13 years ago

How does PNaCl differ beyond intermediate representation from asm.js?

Both are basically intended as a target for LLVM-compiled code, so lots of similarities, but the main difference is that asm.js is a subset of JS so it runs in any JS engine, while PNaCl is different. Aside from that, there are lots of technical differences, but it's hard to say which actually matter in the long run. To quickly summarize, right now asm.js tends to run a little more slowly than PNaCl but start up a little more quickly. But engineers on PNaCL and on JS engines intend to shrink those differences over time, and there is no reason in principle why they won't succeed.

To judge for yourself, you can see some comparisons between PNaCl and asm.js in these two sites:

http://www.flohofwoe.net/demos.html

http://trypepperjs.appspot.com/

My impression is that the perf differences are not that noticeable already. For example, the bullet demo in the second one seems to run slightly faster in PNaCl than asm.js. However, profiling shows that 65% of time is spent in three.js rendering code, not in asm.js, so perhaps rendering differences account for most of the disparity, and it mostly isn't comparing asm.js to PNaCl.

binji2• 13 years ago

We were seeing some significant slowdowns when running lua in emscripten (testing on repl.it) vs. PNaCl.

Take this naive fibonacci function: function fib(n) return n<2 and n or fib(n-1)+fib(n-2) end print(fib(30))

On my machine, it completes in less than a second on PNaCl, but takes nearly 10 seconds to complete in emscripten.

lmkg• 13 years ago

The point of both projects is to allow a larger class of programs (and programming languages) to run on web platforms.

The point of PNaCl was to overcome or remove some of the constraints that come with the JavaScript language, like the lack of a concurrency model. This necessitates a new runtime. Since a new runtime was required anyways, Google decided to expend the engineering effort to make it as similar to native code as possible in terms of capabilities and performance, while also maintaining security.

The point of asm.js was to not include another runtime in the browser, but still meet the needs of the programs that PNaCl was trying to serve. Because it plays within the bounds of JavaScript it doesn't meet all the needs that PNaCl does (again, like concurrency), but it still allows native-like programming.

josteink• 13 years ago

I'm so glad to see Google finally make a mobile version of Active X.

Seriously though. Stuff like this is what made me quit Chrome. Too much non-standard Google nonsense in what is supposed to be a standards-compliant web-browser.

It just feel wrong.

eliben9• 13 years ago

As opposed to Active X, PNaCl runs on all major OSes (desktop and ChromeOS so far, not mobile yet) and on all major CPU architectures.

Active X, AFAIR, was portable in true Henry Ford manner - running everywhere as long as it's a Wintel box with Internet Explorer.

igreulich• 13 years ago

Marginally off topic, but calling a A Windows box a Wintel box implies that there is functional, if not fundamental, difference between Windows/Intel machines and Windows/AMD machines. There isn't.

I ran all the same Active X controls on my WAMD box you did on your Wintel.

Or am I missing something about the Windows/Intel combination?

Anecdote: I switched to Mac (Mintel? Mactel?) in 2007. Prior to that, my 486DX4 100 (circa 1995) was the last Intel I used.

</offtopic>

pietro• 13 years ago

I believe Microsoft learned that lesson a decade ago. Since then, they've pushed Silverlight as an open, standardized, cross-platform programming environment for the web with virtually no success. This is the relevant comparison.

pornel• 13 years ago

Microsoft Delivers ActiveX on the Macintosh Oct. 17, 1996

http://www.microsoft.com/en-us/news/press/1996/oct96/macpr.a...

kovalkos• 13 years ago

Additionally, it is Open Source.

_random_5• 13 years ago

At least they are trying to innovate. I am tired of seeing n-th JS-MVC framework that are posed as something fundamentally new.

drdaeman3• 13 years ago

I believe it's open, and not patented (or I'm wrong?), an attempt to bring LLVM IR (quite standardized) to browser side. It's redundant (competes with asm.js, which is the same kind of "non-standard nonsense" with a WIP spec) with it's own pros and cons, but that's about it.

Every browser vendor experiments with new ideas, only because of this we're getting nice things as the results.

rsanders3• 13 years ago

I have no axe to grind against LLVM or PNaCl, but I think you may have a novel definition of "quite standardized".

eliteraspberrie• 13 years ago

I can't be the only one who doesn't think this is cool.

From an application security point of view, PNaCl -- and the general trend of packing everything into browsers -- is not good. The first rule of security is to keep things small and simple. A browser with a built-in compiler is no longer a browser.

If Google had its way, phones would just be dumb bootloaders for operating systems downloaded on the fly from their cloud.

eliben9• 13 years ago

Do note that PNaCl uses Native Client as a base. Native Client is a very secure sandbox that's been out in the wild for some time, had security contests run against it and has in general proven itself to be very secure. The PNaCl translator (backend of the compiler) runs within a NaCl sandbox itself, so nothing in the Native Client security model is compromised.

_random_5• 13 years ago

So JS shouldn't be JIT-ed as well?

enneff• 13 years ago

You have it backwards.

The PNaCl thing actually makes it more realistic to actually install a "Web App" inside Chrome and use it independent of an internet connection. The browser is lagging well behind Android and iOS in terms of user experience. Efforts like PNaCl and asm.js help to restore the balance.

All browsers include compilers already, by the way.

RRRA2• 13 years ago

Embrace, Extend, Extinguish... now in version 2.0 beta!

mistercow2• 13 years ago

What I'm really looking forward to with this is not PNaCl on the web, but PNaCl as a way of writing high performance portable native apps by using a Chromium wrapper.

I'm very excited by the idea of being able to write an app that "just works" across a ton of platforms using JS and HTML5, with compiled code sprinkled in for performance-critical portions. Projects like AppJS have been working toward this already, but with PNaCl, a big missing piece can finally be filled in.

RRRA2• 13 years ago

Could we just standardize and complete what is missing from Firefox OS's proposed standard: WebAPI ?

mistercow2• 13 years ago

I am unaware of any part of WebAPI which is geared toward native code performance. And cool as it is, asm.js is never going to have the same potential that PNaCl has. Primarily this falls under one reason: multi-threading.

Web Workers are a step in the right direction, but they're incredibly limited by design because of the inability to share memory across threads. The requirement of copying data across threads means that parallelizable tasks involving small operations over large chunks of data often don't benefit from using Web Workers. Unfortunately those tasks make up a large percentage of situations where parallel processing is useful.

felipe• 13 years ago

Have you considered XULRunner?

mmastrac• 13 years ago

My problem with PNaCl is that it's basically defined an a LLVM module (snapshotted as the implementation an LLVM module today), but with a bunch of limitations of what you can't do ("The only calling convention supported by PNaCl bitcode is ccc - the C calling convention", "PNaCl bitcode does not support visibility styles."[1]).

I understand not wanting to re-invent the wheel, but I don't think we should bake a bunch of LLVM-isms into something that should be designed to run on browsers for the next 20 years. Basically, the whole PNaCl spec feels way too half-baked for something that should be a standard -- sort of how I felt about embedded SQLite into web standards as the spec and reference implementation (WebDatabases, shiver).

I prefer asm.js's approach over PNaCl. I'd also be happy if the browser vendors came up with a new bytecode from scratch as well, designed for the web.

[1] https://developers.google.com/native-client/dev/reference/pn...

lambda3• 13 years ago

And the Web SQL initiative failed, for just this reason; SQL itself does not define enough to write portable SQL, so they just had to say "well, SQL as implemented by SQLite as of this particular version", and that was pretty much a non-starter. Web SQL had even got a little more buy in from multiple vendors (Safari, Chrome, and Opera), but due to the problems with it Mozilla and Microsoft refused to implement it.

The same is likely to happen to PNaCL. It will probably survive for a while in Chrome, as it may be useful for writing ChomeOS specific apps, but it will never be adopted by any of the other browser vendors. ASM.js runs just fine in other browsers, the only difference is that they don't implement the stricter subset and same optimizations as Firefox does, so it's a lot more likely to catch on, as people can write cross-platform ASM.js right now.

rybosome• 13 years ago

Correction: you can write cross-platform PNaCl code; there's a project called pepper.js that compiles the PNaCl application using emscripten. To quote the GitHub README: "Native Pepper applications can now be run in Chrome, Firefox, Internet Explorer, Safari, and more."

This leaves them in roughly the same place; write code that will be heavily optimized for one of the browsers, then include a compatibility layer that will make it runnable in all of the others. Without making an argument as to which underlying approach is better, I see no clear upper-hand from the perspective of compatibility.

What somebody needs to do now is define another language that compiles to both PNaCl and asm.js-suitable languages, and offer a deployment mechanism that correctly uses one or the other when in a browser-optimizable situation. Nothing beats too many standards like adding another standard to unify them. ;)

pcwalton3• 13 years ago

I'd also be happy if the browser vendors came up with a new bytecode from scratch as well, designed for the web.

I would actually really like this, if defined as an isomorphism to asm.js. (asm.js core operations are pretty simple, it's only the JavaScript syntax that is funny.) Anyone can do it. Write a compiler in JS that compiles this WebBytecode to asm.js (and PNaCl if you want, though I'm not sure if you can dynamically generate PNaCl at runtime from JS) and evals it. You could then ship apps with this bytecode today and have them work in all browsers, and it would be, effectively, completely standards-based since the asm.js semantics would be normative and the asm.js semantics are defined by the ES6 draft spec. You'd be able to ship a clean bytecode representation, unsaddled with the legacy baggage of JavaScript or LLVM, and cross-browser compatibility with what could be, if implemented properly, a tiny stub loader.

The biggest hurdle to getting it working in PNaCl would be wrapping the Web APIs in the Pepper APIs as an "inverse pepper.js", but that should be done anyway as any app that wants to target the standards-based Web APIs and the Google-specific, nonstandard Pepper APIs will want this.

cromwellian• 13 years ago

I don't think the problem with asm.js is the on-the-wire format, it's the semantics. Someone writing native C code wants threads and low level currency primitives. Javascript is fundamentally unable to model that, and Javascript as designed for the browser does not model synchronous blocking either (XHR sync and dispatchEvent notwithstanding)

I feel like both PNaCL and asm.js are a kludge in search of a problem. I just don't see either of these winning over say, DICE to implement Battlefield 4 in a browser, or Valve for the next Half-Life franchise. Triple-A developers don't want to leave performance on the table, and running your code inside of a browser virtual machine, even a C-based sandboxed one virtually guarantees that.

Asm.js might be vitally important for a platform like Firefox OS, but I doubt either PNaCl or Asm.js will ever be something the drive by web bothers with, because the kinds of applications that need native levels of performance are also the ones native developers are most likely to do native platform specific ports for. That is, having to recompile and port from Win32 to OSX to Linux is worthy tradeoff vs losing 20-50% performance off the bat, not to mention the different purchasing behaviors of Web users vs console or native mobile users.

haberman2• 13 years ago

I think this and asm.js are both extremely cool. I look forward to the competition this will inspire, and the improvement of both approaches as a result. I say this honestly not sure which one I personally think will be better in a year or two.

I often think of software as "walking a path." What I mean by this is that there are often different approaches to the same problem, and these start out as just basic, undeveloped ideas. But put smart people on it (and I have high regard for both the Google and Mozilla engineers on these projects) and let them refine these ideas over time and you'll learn more about all of the consequences, the fundamental strengths and limitations, of these approaches.

I first had this thought when working at Amazon. I remember hearing an off-hand comment about how S3 and Dynamo, both Amazon projects that started around the same time, started with very different consistency goals (Dynamo: very weak, S3: very strong) but as the details were fleshed out, ended up coming towards each other and both became more moderate.

I think that's extremely valuable knowledge, because it can become part of the body of resources that any future designer can look at. Whenever you have an idea, chances are other people have "walked the path" of that idea (or some variant of it) before, and reading about their experience can help you see down the road and anticipate what practical problems you'll run up against. You might have an idea for how to improve on what the previous designers did, but by reading about their experience you can save yourself a lot of the work they already did.

For this reason, I look extremely forward to watching these two projects evolve and compete, and in doing so, to learn more about the fundamental properties/tradeoffs of this design space.

jkn• 13 years ago

Thanks for bringing some positivity to the debate. PNaCl and asm.js are timely and they are technically very different. It will be interesting indeed to see how it goes from here.

BlackAura• 13 years ago

The introduction of pepper.js is particularly interesting. It's a re-implementation of (some of?) the Pepper API on top of the standard web APIs, so you can write stuff for PNaCl but also compile it using enscripten for other browsers. Which means you could target both PNaCl and asm.js at the same time.

That also means it's effectively encouraging asm.js adoption, which might give Apple and Microsoft enough of a kick to optimize that. Google seem to already be planning on it (they added some asm.js tests to their Octane benchmark).

It also might be useful if, at some point, other browsers want to implement a PNaCl runtime. One of the main sticking points (aside from the use of LLVM bitcode, which is not something LLVM was designed for) was that it requires the Pepper API, which is huge, and duplicates much of the existing web APIs. Google have the spare engineers to do that, but Mozilla certainly doesn't.

A reverse of that would be useful too - an implementation of the standard web APIs on top of Pepper, so you could re-target an asm.js app to PNaCl. Or some kind of tooling that lets you transparently target both.

Maybe we'll see some kind of convergence thing going on? Wouldn't surprise me too much if they started evolving slightly towards one another. I think it's probable that asm.js will eventually get some kind of compact bytecode representation, especially if it can be implemented as a shim to allow it to load in existing browsers.

andyl• 13 years ago

Another brick in Google's walled garden. I will never use it.

buremba• 13 years ago

It seems Atwood was right. http://www.codinghorror.com/blog/2007/07/the-principle-of-le...

eonil4• 13 years ago

If I want to write a portable C++ GUI app, this codebase would be a good free option to fork.

Anyway running in Chrome product sandbox is nothing attractive. For the web, I would bet on Emscripten + asm.js which is a lot more portable.

pjmlp6• 13 years ago

Qt, wxWidgets, Gtkmm, Juce

eonil4• 13 years ago

GPL requires you to PAY your freedom to choose license for the freedom to access source code. So it's trade of freedoms, not free.

talles• 13 years ago

NaCl is not new, I remember seeing about it I guess over a year ago?

What really happened, they reached a stable version or something?

frozenport• 13 years ago

Does Google use this internally? For example are they using it as an optional faster frontend to their apps?

Google launches Portable Native Client

Related Stories