
Google launches Portable Native Client - hackhackhack
http://thenextweb.com/google/2013/11/12/google-launches-portable-native-client-lets-developers-compile-code-run-hardware-site/
======
haberman
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
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
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.

~~~
pcwalton
Yes, I find the possibility of convergence hopeful.

I'd prefer the inverse of pepper.js and deprecation of Pepper. Way back in the
plugin-futures days, every other browser vendor rejected Pepper because it
duplicated Web APIs and a C binding to the Web APIs would be more useful. To
me, Emscripten and pepper.js just shows that this was true. Emscripten
provides C bindings to Web APIs, and pepper.js shows that Pepper is
effectively equivalent to the functionality the Web APIs provide. So I see no
need for Pepper, and I hope that Google will eventually eliminate this
unnecessary duplication of functionality.

~~~
haberman
> pepper.js shows that Pepper is effectively equivalent to the functionality
> the Web APIs provide

From my reading of it, pepper.js can only support a subset of Pepper's
complete capabilities. At a high level, it is missing:

    
    
        - threads
        - memory mapping
        - memory protection
    

There's also stuff like this in pepper.js that clearly demonstrates a lack of
parity:

    
    
        // The Web Audio API currently does not allow user-specified sample rates.
        var supportedSampleRate = function() {
          return createAudioContext().sampleRate;
        }
    

Also pepper.js is filled with chunks of code like:

    
    
        var FileRef_GetFileSystemType = function() {
          throw "FileRef_GetFileSystemType not implemented";
        };
    
        var FileRef_GetName = function() {
          throw "FileRef_GetName not implemented";
        };
    
        var FileRef_GetPath = function() {
          throw "FileRef_GetPath not implemented";
        };
    
        var FileRef_GetParent = function() {
          throw "FileRef_GetParent not implemented";
        };
    
        var FileRef_MakeDirectory = function() {
          throw "FileRef_MakeDirectory not implemented";
        };
    
        var FileRef_Touch = function() {
          throw "FileRef_Touch not implemented";
        };
    

I don't know enough about these APIs to say whether this is just incomplete or
whether these Pepper calls can't be reasonably implemented on Web APIs, but
pepper.js seems far from a demonstration that Pepper is "effectively
equivalent" to Web APIs.

------
mmastrac
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...](https://developers.google.com/native-
client/dev/reference/pnacl-bitcode-abi)

~~~
lambda
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
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.
;)

~~~
yetanotherphd
>there's a project called pepper.js that compiles the PNaCl application using
emscripten.

That made me laugh. You write code that is supposed to compile to native code,
only to have it compiled to javascript instead. It's a crazy world we live in.

~~~
pjmlp
It is the hipster world, where an application created to show documents has
been subverted into a virtual machine.

------
josteink
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.

~~~
eliben
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
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>

~~~
lambda
Wintel just refers to the instruction set, not the actual processor. The
reason for using it in this case is that since ActiveX are compiled for x86,
they won't run on other platforms that Windows runs on. In the past, Windows
NT ran on PowerPC, Alpha, MIPS, and Itanium platforms; now Windows runs on ARM
in the form of Windows Phone and Surface. So it's not just IE on Windows that
is relevant for ActiveX, it's IE on Windows on x86. But that's a mouthful to
say, so people abbreviate it to "Wintel".

------
mistercow
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.

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

~~~
mistercow
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.

------
egeozcan
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.

~~~
eliben
You'll be interested in this project, then:
[http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-
does-p...](http://blog.awilkins.id.au/2012/12/go-in-browser-llgo-does-
pnacl.html)

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...](https://developers.google.com/native-
client/dev/reference/pnacl-bitcode-abi) \- and we're working on making it more
precise.

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

~~~
eliben
Can you clarify what you mean by "spec"? The bitcode ABI document I pointed to
is the spec of the IR used by PNaCl. The official documentation covers the
Pepper APIs which are PNaCl's interface with the browser and DOM.

~~~
Touche
A document with which someone could create an alternative implementation; like
another browser for example. Do I take this to mean that there isn't one?

~~~
jryans
There is no real "spec" of the Pepper APIs, just API docs. While those might
be of high quality, it still depends on many implementation details, so it
seems like it would be challenging for another browser to duplicate.

------
Refefer
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
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.

~~~
eliben
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.

~~~
sanxiyn
Doesn't Haskell's LLVM backend depend on custom LLVM calling convention to do
tail call? Does PNaCl bitcode support tail call?

------
jmpe
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?

~~~
eliben
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.

~~~
jmpe
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.

~~~
azakai
JS should not be that slow in my experience. Do you still have the code to
your benchmark somewhere? Perhaps you ran into a performance bug that we can
file for the relevant browser(s).

~~~
jmpe
I have it somewhere, also still have that laptop. It wasn't a benchmark but a
poc for an algorithm.

I did some serious optimization when I wrote it. There was a "best practices"
for V8 that shedded some light on the background of JS variable allocation, I
followed it and got a serious boost. Also did lookup tables instead of runtime
math with exp/log functions. But in the end: hit several worst case images
that took more than 12s, which was a gap that couldn't further be reduced
through optimization.

But you're absolutely right, I should redo it in PNaCl.

~~~
azakai
I never said that ;)

~~~
jmpe
ouch, sorry, misread your last sentence.

------
eliteraspberrie
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.

~~~
eliben
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.

------
Procrastes
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
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_
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?

~~~
munificent
> Maybe a new virtual machine along with a high-level language will magically
> materialize out of thin air?

Dart[1] is high-level, and has a clean, fast VM implementation. Also, ARM
support[2].

[1] [https://www.dartlang.org/](https://www.dartlang.org/) [2]
[https://code.google.com/p/dart/source/browse/branches/bleedi...](https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/runtime/vm/assembler_arm.h)

------
pritambaral
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
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.

~~~
pritambaral
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.

~~~
dragonwriter
NaCl -- even the non-portable form -- doesn't require recompiling for
different OS's. It only requires recompilation for different machine
architecture (x86 vs. ARM.)

PNaCl removes the need to compile different x86 vs. ARM binaries for NaCl.

~~~
eliben
This is correct.

A more significant difference is, however, that NaCl is restricted to the
Chrome web store, while PNaCl is available on the open web. You can have a
PNaCl module your web app, on your website/domain today, and Chrome 31 (and
later) will run it.

~~~
dragonwriter
The two are tied -- the reason Google didn't enable NaCl outside of the Web
Store is to avoid architecture-tied NaCl code from becoming common on the web
when PNaCl was in the pipeline.

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

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

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

------
buremba
It seems Atwood was right. [http://www.codinghorror.com/blog/2007/07/the-
principle-of-le...](http://www.codinghorror.com/blog/2007/07/the-principle-of-
least-power.html)

------
eonil
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.

~~~
pjmlp
Qt, wxWidgets, Gtkmm, Juce

~~~
eonil
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.

~~~
pjmlp
What has GPL to do with the listed frameworks?

Not all of them have GPL licenses, plus it is only fair to pay people for
their work.

~~~
eonil
Maybe here's a miscommunication. I meant _no price, no need to trade my
copyright_ , and maybe you're meaning _freedom to access source code_ \-
strict GPL meaning.

Also I haven't argue payment itself is bad. Go back and read carefully my
reply. Fair trade is good, and I would gladly pay for good product.

~~~
pjmlp
I still don't get your point.

You mentioned targeting the browser with C++ for portable applications.

For me the place of native code is at the OS level, and the browser should be
left alone for plain interactive documents, instead of Frankenstein VM.

Hence my short reply with a list of native frameworks.

It has _nothing_ to do with licenses.

~~~
eonil
OK I see your point.

My original intention was using HTML as a GUI toolkit layer, and I realized
that was wrong idea with PNaCL. It's exactly opposite concept. It's my
mistake. I'm sorry for that.

Wow. now I see PNaCL is really completely useless except for Google's API
dominance.

------
talles
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
Does Google use this internally? For example are they using it as an optional
faster frontend to their apps?

------
mtgx
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.

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

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

