

Portable Native Client - amaks
http://blog.chromium.org/2013/11/portable-native-client-pinnacle-of.html

======
azov
[http://en.wikipedia.org/wiki/ActiveX](http://en.wikipedia.org/wiki/ActiveX)
\- 1996 is knocking… yes, I know - it's very, very different this time, but
still can't help remembering the horrors of ActiveX :)

PS. From Wikipedia article: _In principle it [ActiveX] is not dependent on
Microsoft Windows, but in practice, most ActiveX controls require either
Microsoft Windows or a Windows emulator_

PPS. I'm not really trying to compare them, just pointing out that obsessive
idea to run Photoshop in browser is almost as old as browser and photoshop
themselves. And so is the idea for a grand platform that will let us "write
once, run everywhere". Uncountable attempts were made, yet somehow they all
fall short of expectations. Is the idea itself flawed? Perhaps we have
different operating systems for a reason?..

~~~
axelf
It seems like every time someone tries to replace javascript with a better
solution someone has to bring up vendor lock-in. Are we supposed to just live
with javascript for eternity? When javascript was introduced it only worked on
netscape browsers than other browsers adopted it later. It wasn't made a spec
until later.

~~~
NinjaWarrior
Indeed. Every trial to replace "standards" is called "evil". From this
perspective, the web platform is far from open. The result is we all are in a
local optimum trap. I already gave up expecting cool future and decided to
stick to the native development for a while (for a decade or more).

BTW, as a game developer, it would be nice if this rendering latency issue
will be fixed soon.

\- [http://phoboslab.org/log/2012/06/measuring-input-lag-in-
brow...](http://phoboslab.org/log/2012/06/measuring-input-lag-in-browsers)

\-
[https://code.google.com/p/chromium/issues/detail?id=168459](https://code.google.com/p/chromium/issues/detail?id=168459)

I think this response time issue is a real show-stopper than JavaScript
performance.

~~~
peterhunt
This along with the fact that you can't avoid GC when handling browser events
makes it really hard to hit a consistent framerate for sure.

------
RyanZAG
Ugh. Sounds like the next IE6 is here...

Can't wait to log into a bank that demands I installed Chrome to use their new
'security' or some web apps that won't run in anything but Chrome.

~~~
pkulak
This seems like more of a ChromeOS move to me, so that you can run native code
on Atom and X86 machines. The knock on ChromeOS is always that it's "just a
browser". I seriously doubt anyone is going to write their Etsy storefront in
NaCl. The benefit here, of course, is that if someone does write the next
Photoshop for ChromeOS machines, it should also run fine in OS X, Windows and
Linux. Seems like a win for portability to me.

~~~
0x0
That worked out well for Java.

~~~
ryanackley
No, but it did for Flash.

~~~
0x0
Let's just say I'm pretty happy I'm not maintaining any products built with
Flex/Air.

------
cia_plant
PNaCl has been in development for a while, I'm having trouble understanding
just what is being announced here. Is PNaCl now enabled by default in Chrome?

I also hadn't seen pepper.js before, is that new?

~~~
devrelm
> [http://codepen.io/lbebber/pen/xrwja](http://codepen.io/lbebber/pen/xrwja)

I think so. I just updated to Chrome 31 and it brought up a UAC in windows,
which probably means that it was installing the PNaCl runtime since it usually
doesn't require a UAC.

~~~
mavhc
Or it could be Chrome asking to switch to installing in Program Files instead
of User profile.

------
bsimpson
Be interesting to see if this becomes a target for other languages, e.g.
allowing browser applications to be written in Python.

~~~
leoc
What would be _really_ great to see is someone putting a HTML client/DOM
implementation/etc. inside a PNaCL application. This is after all how things
ought to be: ideally you implement your DSL/document viewer inside your
general-purpose runtime, instead of kludging your document-format
specification up into an application runtime. None of the big browser vendors
(including Mozilla and Google itself) is going to welcome such an idea though,
as it threatens their _de facto_ control over Web standards.

~~~
wmf
This is a similar idea to the MSR Embassies project:
[http://research.microsoft.com/en-
us/projects/embassies/](http://research.microsoft.com/en-
us/projects/embassies/)

~~~
leoc
Looks like it. It's also similar to ideas which were (iirc) prevalent in the
mid-to-late '90s about a modularised/componentised browser as the future of
the Web.

------
_random_
Very good news! A lot of developers don't like JavaScript and HTML. Google
started to listen. I really hope the rest of big players will follow the
suite.

~~~
oblio
Be careful what you wish for because it might come true. A lot of people don't
like the Open Web and are clamoring for something obfuscated. Longer term is
lose-lose for everyone.

~~~
_random_
I don't understand how Web can be "Open" if your choice of language is limited
to JS, HTML and CSS that are changing as quickly as standards committee is
managing to react. And transpilers are just a second-class-citizen hack trying
to make the best of situation.

~~~
pjmlp
Just write native applications and use normal network communications.

Plenty of choice available with 100% full hardware use.

------
thrownaway2424
The demos are cool, but are there any among them that can't be done in JS? I
know I've seen Voronoi polys in JS that were way less janky than the one in
the PNaCL demo.

~~~
leoc
Well, presumably you could implement a language with bignums in PNaCL with
reasonable efficiency, something which is evidently not possible in JS.

~~~
azakai
Why is that evidently not possible? :) Serious question, I would guess
anything that can be done in C - and bignums can - could be done well in JS,
because typically C code compiled to JS runs at about half the speed of
native.

If you have results showing otherwise for bignums, I would be very interested.
Anything special about that particular problem?

~~~
leoc
> Why is that evidently not possible? :)

Because Mozilla assured us that it was not. Central to Mozilla's case against
Dart was the assertion that parts of it - including bignums - could not be
implemented efficiently by compiling to JS, leaving native Dart runtimes at a
strong advantage.

~~~
azakai
Link?

~~~
leoc
Here we are:
[https://news.ycombinator.com/item?id=3094072](https://news.ycombinator.com/item?id=3094072)

~~~
azakai
Thanks, reading that it says that native bignum support can speed things up.
That's probably true - the only question is how much. If it's 25% vs 2,500%
then that's what matters. I don't see an actual debate about numbers in that
thread there, just generalities?

As I said above, I would expect JS to reach about half of the speed of C. It's
possible that having native bignums would have removed some of that
difference.

More importantly, the context here is PNaCl. Do you see a reason bignums could
be emulated better in PNaCl vs JS? I assumed that's what you were implying,
but perhaps I misunderstood you? Sorry if so.

~~~
thrownaway2424
I'm not sure the poster meant "bignum" as in huge numbers like GnuMP handles,
or if he meant exact 64-bit integers, which JS doesn't have (natively).

~~~
azakai
I think true arbitrary-size bignums, because that's what Dart has?

------
tluyben2
It says 'LLVM style intermediate code'; why not actual LLVM intermediate code?
What would be the reason for an alternative? If it would be actual LLVM code
it would be easier to compile from programming languages and to different
backends, right?

~~~
mccr8
It is based on LLVM, but presumably they have to modify it for their
particular needs. The PNaCl bitcode reference manual goes into more detail:
[https://developers.google.com/native-
client/dev/reference/pn...](https://developers.google.com/native-
client/dev/reference/pnacl-bitcode-abi)

~~~
eliben
More details on the design process are available here:
[http://www.chromium.org/nativeclient/pnacl/stability-of-
the-...](http://www.chromium.org/nativeclient/pnacl/stability-of-the-pnacl-
bitcode-abi) (there's a link to a nicely formatted PDF in the bottom).

TL;DR: a lot of thought went into it :)

------
peterhunt
For anyone who works on Chrome: does this mean that Chrome won't move to
support asm.js? I tried searching the bug tracker and discussion group and
couldn't find anything.

In general I'm really happy that we're getting faster (no-gc) runtimes, but I
think I favor asm.js's approach due to its backwards compatibility (though I
admit I am not aware of the nuances of each implementation).

~~~
elisee
Chrome has taken the approach of working on improving their V8 engine to
(hopefully) achieve similar performance to Firefox's specialized asm.js AOT
codepath but without any special handling of the "use asm" directive (which
gives Firefox guarantees about variable types & stuff like that). See
[https://news.ycombinator.com/item?id=6553794](https://news.ycombinator.com/item?id=6553794)
for a discussion on the subject.

~~~
peterhunt
Great, thank you for the link!

------
Fr0styMatt
Why do people keep saying that PNaCL is like ActiveX, when it's nothing of the
sort? Is this a failing on Google's PR?

~~~
BitMastro
Because lots of people are narrow minded apparently

------
willvarfar
Great news for zerovm too! Will this mean apps that run seamlessly on ARM and
X86 boxes?

------
icefox
Anyone know why it takes so long to load any of the demos on
[http://gonativeclient.appspot.com/demo/bullet](http://gonativeclient.appspot.com/demo/bullet)
? They simply take way to long.

~~~
eliben
The PNaCl translator takes time to optimize the bitcode to highly-efficient
machine code (which is almost on par with native performance). This only
happens the first time you load the demo - afterwards the output is cached and
the load should be instantaneous.

Translation time is one of the highest priorities of the PNaCl team and it
should become significantly better in the future.

~~~
icefox
Sadly even after it loads and hitting refresh I still see a progress bar.

As google knows loading time really really matters and for such small demos it
does not look good that it takes 10(?) seconds to load. Makes me wonder about
larger applications.

~~~
eliben
Does it take the same amount of time to load on subsequent runs as on the
initial run? This should not happen. Are you running in incognito mode,
perhaps? (in that case, caching doesn't happen for obvious reasons). Feel free
to submit a report on the native-client-discuss mailing list or through the
bug tracker.

~~~
icefox
It is faster, say less than a half second and not the 10 seconds it was the
first time, but still _very_ noticeable. Normal latest chrome on a Windows
2008 box.

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

------
smegel
How is this different to Javascript? They both get jitted to native code (v8,
llvm)...what's the benefit?

~~~
ahomescu1
PNaCl bitcode is (mostly) statically-typed and has a C-like memory model, as
opposed to dynamically-typed JavaScript. Dynamic typing has a run-time
performance cost, and so does garbage collection.

~~~
eru
Are you sure that PNaCl bitcode is typed at all?

~~~
ahomescu1
It's kind-of typed. They kept the basic integer and floating-point types from
LLVM (i8, i32, i64, double) and pointers, but removed structures and arrays.
It's "more typed" than JavaScript, but less than C++. This still means that
numeric code (working with integers and floats) is going to be at least an
order of magnitude faster than on JS.

------
ThinkEzy
I am actually looking at saying good bye to browser (html / css / js and all
the madness) and hello to apps that connect to dropbox or s3 or some such
cheep server.

------
augustl
Isn't it better to ship uncompiled C++ code directly, instead of decompiling
and recompiling already compiled code?

Honest question, I'm a noob at compilers :)

~~~
mdaniel
Bytecode (whether x86, Java class files or this) is a far more compact and
(arguably) more complete representation of the program's logic than the input
source code.

Also, you haven't experienced pain until you've tried to compile C or C++ on a
machine other than the author's.

------
cek
When this is supported natively in Safari on iOS it will be interesting.

~~~
misuba
Apple's developer guidelines prohibit compiling and running anything that came
over the wire, for security reasons as well as competitive ones. They could
add this ability to Safari themselves, but why would they?

~~~
_prometheus
What do you think will be the evolution here? Surely mobile won't stay behind
native-webapps forever, at some point asm.js/pnacl/something else will come
in. But what?

~~~
misuba
I'll be interested to see how pepper.js performs on mobile. Certainly plenty
of people have skin in the game and want to see this stuff work.

------
djvu9
asm.js is a better answer.

~~~
general_failure
What's the question?

~~~
cia_plant
How many layers of indirection can we put between the developer and the
machine?

~~~
burstmode
I'm sure there is some space left for fancy named design patterns and a
template library with lambda support. You know you can't write a website
without lambdas, don't you ?

