
Google Introduces Portable Native Client - ahomescu1
http://techcrunch.com/2013/05/17/google-introduces-portable-native-client-makes-it-easier-for-developers-to-add-c-and-c-code-to-their-web-apps/
======
Irishsteve
It's like ActiveX... of the future!

------
alayne
This seems like a niche technology. I doubt that many C/C++ developers want to
write front end code for the web.

~~~
neilxdsouza
I want to. I am developing a survey progrmaming compiler. I am currently
isolating the runtime (written in c++) and trying to compile to JavaScript
using Emscripten. But PNaCl could be a another web delivery option

------
conradev
Just an interesting tidbit I'd like to point out: native client was not
mentioned in the Chrome portion of the I/O keynote at all, while asm.js was:

"And in the last month alone, we’ve gotten over 2.4x speed boost running this
asm.js code in V8, and there’s tons more optimization to come."

Not only that, but it turns out that the mentioned improvements had nothing to
do with asm.js at all: <https://twitter.com/mraleph/status/334719725617696768>

~~~
ianetaylor
We were going to show a couple of cool Native Client demos during the keynote
but we had to cut them at the last minute due to time constraints.

------
mindcrime
I have really high hopes for PNaCl, but I'm skeptical that it will "get
there". Getting other browser vendors to adopt it seems to be an uphill battle
so far, and figuring out the tradeoffs between security and power will
probably be a sticky point as well.

~~~
venomsnake
But it can solve a lot of problems for iOS development if you don't want to go
trough the store.

~~~
lttlrck
Yeah when Safari supports it...

------
pekk
I really wish that someone other than Google would take this up (whatever
Google would need to do for that). C has of course been a great choice for
performance-sensitive programs for years and it is quite a mature language
with mature tools. It doesn't make sense for everyone to be forced to use
JavaScript as the only option, forever, just because of convention.

~~~
kevingadd
Once it's actually possible to use PNaCL apps in webpages, I think it will see
dramatically faster adoption. It's mostly a question at this point of whether
they manage to ship it before someone else beats them to the punch (looks like
Chrome 30 is projected for August). By then Mozilla could easily have picked
up a lot of momentum with asm.js.

~~~
TazeTSchnitzel
Problem is we'll only ever see PNaCl support in Chrome. The nature of NaCl and
PNaCl is that they rely on single implementations by Google which are designed
around Chrome's internals, and so they are unlikely to ever be adopted by
other browser vendors, aside from perhaps Opera, since it will be Chromium-
based.

------
quackerhacker
Sounds kinda like Google's own implementation of WebCL? I guess Google is
really trying to push the concept of utilizing the Chrome browser as an OS
development environment instead of just a browser... seems cool.

~~~
wmf
WebCL runs on the GPU while PNaCl runs on the CPU.

------
kodablah
How much of a subset of LLVM is it? Can other LLVM frontends target it easily
(e.g. Rust or <http://terralang.org/>)?

~~~
pcwalton
Rust could target it, but not as easily as you might think. LLVM IR is not
portable (for example, here's some of the code necessary to get the calling
conventions right in the LLVM IR for x86-64 [1]). The runtime and scheduler
would have to be ported to the Pepper API if you wanted stuff like GC, I/O,
and threads (which most Rust programs will want).

[1]:
[https://github.com/mozilla/rust/blob/master/src/librustc/mid...](https://github.com/mozilla/rust/blob/master/src/librustc/middle/trans/cabi_x86_64.rs)

~~~
anon1385
Possible still seems preferable to impossible, which is the situation with
Rust on asm.js (correct me if I'm wrong…)

~~~
pcwalton
asm.js Rust is no harder than PNaCl Rust.

------
pjin
To me, the most interesting thing about PNaCl is that it'll be the first real
test of LLVM as a portable assembly bitcode, rather than just a compiler IR.
There are arguments for why LLVM may not be such a good idea, but given the
momentum it's been making, I can only see good things happening for LLVM if
more people use it.

~~~
millstone
Right. I had always thought that LLVM bitcode was unsuitable as a portable
representation because it inevitably encoded architecture-specific details.

Consider code like this:

    
    
        int lsize(void) { return sizeof(void *); }
    

how would this be compiled portably, so that it returns 4 or 8 as appropriate?
What would the LLVM bitcode look like?

~~~
jensnockert
This is true for LLVM bitcode in general, but PNaCl specifies an abstract
machine that defines pointers as 4 bytes long. It also specifies Little Endian
&c.

See [http://www.chromium.org/nativeclient/pnacl/bitcode-
abi#TOC-D...](http://www.chromium.org/nativeclient/pnacl/bitcode-abi#TOC-Data-
Types)

------
mratzloff
> _PNaCl, which Google says we should pronounce as "pinnacle"_

Or as I will call it, "P-salt".

As in, take it with a grain of salt that Google will support this technology
18-24 months from now after it fails to gain much traction.

~~~
pekk
If you think this kind of technology compares to Google Reader, you are just
confused. WebGL would be a better comparison.

~~~
coldtea
Only WebGL is a standard, whereas PNaCL is a Google only endeavor. If it
doesn't catch up, they might abandon it just as they did anything else of
theirs.

Whereas they cannot abandon WebGL if they want to have a standards compliant
browser.

~~~
TheZenPsycho
Actually google doesn't seem to have much problems with abandoning standards
lately.

------
andyl
I don't see the need for NaCL when there is asm.js and emscripten. For fast
lightweight native sandboxing, now we have docker. NaCL seemed like a great
idea, but now it has been overtaken by other initiatives.

~~~
jules
Asm.js doesn't have (as far as I know):

1\. Good primitive data types (e.g. full width machine integers)

2\. SIMD

3\. Tail calls

4\. Threads

5\. Structs

6\. Gotos

7\. Memory management

Once you add these you lose the supposed advantages of asm.js in practice. You
lose the light weight. You lose realistic backwards compatibility because
programs using these features will run so slow on normal JS VMs that they're
unusable, or in the case of tail calls the program will stackoverflow on a
normal JS VM.

~~~
pcwalton
> You lose the light weight.

No, an asm.js that supported all of these would still just be JavaScript,
which is far more lightweight than PNaCl. Besides, these features dovetail
with things we want for JavaScript _anyway_ : SIMD, tail calls, full width
machine integers are things all JavaScript programs need. By implementing them
once and for all we help both regular JavaScript and asm.js.

> You lose realistic backwards compatibility because programs using these
> features will run so slow on normal JS VMs that they're unusable

No, we are compiling programs that use these already, and they are not too
slow as to be unusable. For example, Unreal Engine 3.

~~~
zaharpopov
> No, an asm.js that supported all of these would still just be JavaScript,
> which is far more lightweight than PNaCl.

What makes asm.js "far more lightweight" than PNaCl? What more "lightweight"
means here anyway?

> No, we are compiling programs that use these already, and they are not too
> slow as to be unusable. For example, Unreal Engine 3.

Do you mean the Epic Citadel demo which runs fine on smartphones. So you made
it run more or less smoothly on beefy x86 desktops, how much of an achievement
is that? Is it that "OMG I run my game from the 80s inside the browser with
HTML5 CANVAS!!!" thing again?

~~~
pcwalton
> What makes asm.js "far more lightweight" than PNaCl? What more "lightweight"
> means here anyway?

It's much simpler than LLVM and reuses the components of the JavaScript engine
that already must exist in browsers.

~~~
zaharpopov
> It's much simpler than LLVM and reuses the components of the JavaScript
> engine that already must exist in browsers.

But LLVM IR has complexity for a reason - you need to be able to generate
efficient code from it for multiple architectures. As I mentioned elsewhere,
"reusing JS components" is a very unfortunate party line because it keeps us
tied to this one JS forever and ever, and we should try to see beyond that.

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

~~~
capisce
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).

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

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

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

~~~
justncase80
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?

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

~~~
alexchamberlain
I call Bullshit.

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

