SAM CLEGG: Hi everybody,
my name’s Sam Clegg. This is Ben Smith. We’re engineers on the
Native Client team at Google, and we’re here today with Kester
and Brian, to talk about some of the things we’ve been working
on recently to make it easier to bring Native Code to the web. We’re going to split the
talk into three parts. First, Ben and I will talk
about some of the work we’ve been doing on the SDK. And then Brian and
Kester will each talk about how they’ve been using
Native Client in their work in other parts of Google. So we’ll start with
a quick introduction. For those who don’t
know, Native Client is an open source project
developed at Google, with the goal of being
able to compile and run Native Code in the
browser securely. So this technology’s been
available to Chrome apps in the web store
for a long time now. You just saw the presentation
about how the web store works. And Portable Native Client,
or PNaCl as we call it, is a newer technology that
builds on Native Client, and adds an architecture
and OS neutral binary format that allows Native
Code to be run in the open web on any web page. So, as a developer, if you
have a Native App written in C or C++, what do you normally
need to do to bring this to the web using Native Client? Traditionally, you
would have to use what we call the
Pepper APIs, which are the APIs available
to Native Client modules for communicating
with the outside world. So you’d normally
need to identify all the parts of
your application that do I/Os such as graphics,
sound, and file I/O, and either replace, or modify,
those parts of your code. Also, Pepper is traditionally
asynchronous API, so you might need to modify
the way your application runs and handles events. So this is a fairly
significant burden for application
developers to have to modify their
code in this way. And, also, one of the main
benefits of having access to C and C++ is being able to use
the myriad of existing libraries that are out there in the
world, in the Open Source world. And so we wanted to make
it as easy as possible to bring those libraries
to Native Client without any modifications. And that’s what we’ve
been working on. And to that end, we’ve
built a library called NaCl I/O and this is
essentially a POSIX emulation layer for Native Client. And it allows you to take
your applications that are written for POSIX-like
platforms such as Linux, and Mac, and Android,
and bring them to the web with far fewer
changes and far less effort. So NaCl I/O implements
many of the POSIX APIs that you’ll be familiar
with such a Standardized I/O, and the BSD socket API. It also has the ability
to make blocking calls and use a traditional
C-style main entry point for your application. One interesting part of
this is that, because we’re running in the web platform,
we don’t have direct access to the host file system. So, what NaCl I/O does is
build a virtual file system out of file-like objects that are
accessible on the web platform. So for example, files
on your web server, or files in Chrome’s
local HTML5 storage, become available through
the normal Unix file model that you’re familiar with. You can Open, Close, Read,
and Write, all these things as if they were files. And you can even write
your own file system types, so that your application
feels like it’s running in a POSIX environment,
and requires less porting. So one of the things that
NaCl I/O has facilitated is the growth of the
NaClports Project, which is a repository online
of existing applications and libraries that have already
been ported to Native Client and running Chrome. And we have over 100 libraries
and applications there today. Things like language
interpreters, python, ruby, and lua
that will run in Chrome, and middleware,
like ffmpeg or SDL, that you can take
advantage of today, if your application needs that. And a lot of these ports have
been facilitated by NaCl I/O, and many of them have zero
modification from the upstream, thanks to this POSIX layer. So now I’m going to
hand over to Ben, and we’re going to show you
some of the applications that are running live
in Chrome today. BEN SMITH: Thanks Sam. So, the first one is
going to be well known to probably 50% of you, it is
the famous text editor Vim. And Sam will be loading
it here, you can see it. This is pretty much unmodified. You can see him now adding some
Syntax errors, to some– no, almost adding– So
it looks very much like it’s running in a
terminal, but this is actually a Chrome app. And one of the benefits of that
is that it will run on Mac, Linux, and Windows and– oh, did
you lose it?– and Chromebooks. There we are. I thought you said
you were a vim wiz? OK. So that’s the text editor, vim. Moving on to something that’s
a little bit more visual, this is the Cocos2d-x
game engine. Cocos2d, according to
the Cocos2d authors, is the most popular
mobile game 2D engine. And so, this is just some
examples of some 3D graphics that can be rendered
using this engine. So very simple to take a game
that was written originally for mobile, and bring it to
the web, and also Chromebooks. All right, the last one
is another 2D game engine. This is called Love. This game, in
particular, is a game that is a mash up between Super
Mario Brothers and Portal. It used to be that you could
only play it on the desktop, but since ported
it to PNaCl, you can play it directly
in the browser. So you can see Sam, here,
trying to create a portal. Keep going. And there he goes. Very nice. So these are just some
of the cool things that you can do now with very,
very little porting at all. And I’m going to hand
it off to Kester, who’s going to talk about
some cool stuff he’s going to do next. KESTER TONG: Thanks Ben. So I’m going to be talking
about the work we’ve been doing porting
IPython to PNaCl. And this work has
involved Google, it’s also involved external
Open Source contributors, such as Matthew
Turk from the Center for Supercomputing Applications. And we’ve also started working
with the IPython Dev team. So for those of you who
haven’t heard of IPython, IPython Notebook
is an environment that allows users to it mix text
code, and the output of code, in a single notebook. And it’s very popular for
things such as data analysis, because people can
do some code, they can see the output
of that, for example, in the form of a graph. Then they can do
some more coding, and see some more output. And after they’re done
with this workflow, they have a written record of
every step that they’ve taken, so it’s very reproducible. And then they can add text
annotations, as you see here. And they can share this with
other people and publish it. So our goal is to
integrate IPython better with web technologies. We’ve done two things. The first is that we
ported IPython to PNaCl, and this allows for a
single one-click install from the Chrome Web Store. So currently IPython
is a desktop app, and it has a somewhat
complicated installation process, which may make it
hard for some users to use it. But when we’ve ported
IPython to PNaCl, we are able to now package it
as a Chrome Web Store app, which means a person can download
it from the Chrome Web Store in a single
click, and it’s going to work the same
on every single platform. The other thing we’ve done is
integrated the user interface with Google Drive. So previously, IPython was
using the local file system to manage notebook files. And this could make
collaboration difficult, because, for
example, people might have to email files backwards
and forwards, if they wanted to collaborate. But we’ve made that much easier
by integrating the front end with Google Drive. So that all notebook files
live on Google Drive. And furthermore, we’ve
integrated with the real time API so that multiple
people can work on the document
at the same time. So as you can see here,
it’s very much like a Google Doc-style interface where
you have individuals, you can see who’s in the
document at any time, you can see where
they’re in the document, and you can multiple
people working on the same document
at the same time. So how did we do this? This shows the architecture
of the Chrome app. So, Chrome apps
contain a front end, which is written in
JavaScript and HTML. But they could also
contain PNaCl files, PNaCl binary files. And in this case,
the PNaCl binary file is running the
Python run time, that is the IPython kernel, which
is executing the Python code. So all of the execution is
done inside the browser. A typical workflow
for a user would be to start off in the
Google Drive website, they could open a file,
by clicking on a file. Or they could create
a new one, that will launch a window
in the Chrome app, and then the front end will
talk to the Google API servers to implement the
real-time collaboration. As a developer, if
you’re going to implement such an app yourself, Chrome
apps basically packages, they contain not only
the front end– which is like a web page living
in a window, which contains JavaScript and
HTML– but then when you want to package
it with PNaCl, you also can include the
PNaCl binary inside the app along with a manifest
which contains permissions. In our case, one reason
we prefer the Chrome app is because then we can
have full access to the web without cause restrictions. I’m now going to demo this app. So I start in the
Google Drive website. I’m going to click, New,
and Create a New Document. It doesn’t look
very healthy there. I’m going to try one more time. OK, that’s even worse. So, I’m going to start
from one that I already have running– also
seems to have hung. So I’m just going to
do a reset of this. Let’s try this again. OK, that’s looking better. So it’s creating a new
notebook within Google Drive. And once it’s created
this notebook, we’ll be ready to
execute some code. So if I type in
some code such as, Print, Hello, It will
execute this code. And the execution is
happening in the browser. I’m just going to show
a very quick demo, which I won’t be able to
underwrite, but I’ll just write it in very quick. Thanks, thanks a lot, Sam. So what I’m doing here is I’ve
imported a library called, NumPy, which is a
numerics library. And I’m just going to show
some auto complete here. So I can find the random,
normal, distribution. And I’m going to
generate 10,000 of these. And add them up to
get a random walk. And then if I plot this, then,
as you can see, that’s a plot. So this is just a
very simple example of the sorts of things you
can do with this notebook. A very typical example
of something someone might do in real life,
is downloading some data off the internet,
doing some analysis, and then, with
our software, they can then share this
with other people, publish it, and so forth. I’m now going to
hand off to Brian, who’s going to go about
his team’s work with PNaCl. BRIAN ELLIS: Thank you Kester. So I work on the
Google Earth team. And I want to talk to you a
little about something related to this, which is working
with existing JavaScript APIs in Native Client. So the subtitle of my talk is,
why it doesn’t have to hurt. I’ll get to that in a minute. So in the bad old days, that
many of you may remember, the world was dominated by the
Netscape Plugin API, NPAPI. And here’s an example
of some NPAPI code. We have this magical embed
tag in the document, which just sort of grows some
JavaScript properties and methods which you can call. There’s a lot of magic
involved with this process. There are a lot of
reasons not to like NPAPI. It was a great technology at the
time, but the time in question was like 1995. So it’s really
hard to work with, hard to write, hard to debug. It has security holes the
size of small countries. And most relevantly for
all of us it is deprecated. It Is going away in Chrome. It is probably going
away soon in Firefox. Internet Explorer never
supported it terribly well. We don’t want to
use NPAPI anymore. Obviously, we would like to
consider Native Client to be the replacement for NPAPI,
but if you write Native Client code to do the same thing that
we did in the previous slide, you’ll see that it looks
very, very different. There’s now JSON messages
being passed back and forth. And it’s not
immediately obvious, but if you look
closely at this, you’ll see that it is
asynchronous code. There’s an event handler
that is processing the replies for
all these messages. So, if you have an existing
synchronous JavaScript API, that you want to port away
from NPAPI to Native Client, you can’t, at all. But that is about change. And I’m going to
demonstrate how. We have, just this week, added
to a Dev channel of Chrome near you a synchronous
version of the APIs for posting and
receiving messages. So this is the new code. And you’ll see, it looks
very much like the old code except that now there
is an AndAwaitResponse on the end of that message,
and it has a return value. So this is actually going
to do this synchronously and give you back the
value immediately. It may not seem like
much of a difference. After all, you’ve still
got all these JSON objects floating around. It’s still very message-based,
feels sort of like an RPC call. But with a small
JavaScript shim, which you can write
on top of this, you can get this code, which
out to look pretty familiar, because it is
basically line-for-line identical to the NPAPI code we
wrote in the very first slide. So here’s the broad
statement I’m going to make. It is now possible,
as of this week, to implement almost
any existing JavaScript API on top of Native Client. So to prove this
to you, I’m going to, by way of
demonstration, show you– looks like I’m going
to have to relaunch it because we restarted everything. So, let me do this. This is some of the technology,
behind Google Earth, running in a browser
in Native Client. And as you can see,
it is very smooth. I’m getting about 60
frames per second here. We have full support
for many of the features that you have grown
to know and love in Google Earth,
such as 3D buildings. So if I zoom in to
San Francisco here. And if the Wi-Fi network
in the Moscone Center is willing to cooperate
with me, you’ll see here we have full 3D. We also have some
JavaScript, and HTML, running on top of this view. So all of this rendering
is happening natively, using Native Client. But, for example,
I can do a search for pizza near the
Moscone Center. And these results, again
assuming that the Wi-Fi here is going to cooperate with
us, are rendered in pure HTML. And they can interact. So I can zoom in
to these results and see them on the map. I can even click through
and see information about each of these. These are, again, rendered
in pure HTML and JavaScript. We can interact in
more fundamental ways by turning layers on and off. So here we’re going to see, in
a minute, traffic information. At least, that’s the idea. I guess traffic is
at a standstill. Well, that happens sometimes. Let’s try Transit
Routes instead. I think that should
be– well, you may have to take my word for it. But it does work. And we even have
some features that don’t exist in
Google Earth today. For example, you can
switch back and forth from the globe to a
flat map, with all of the same information
plotted on it. And, again, the network is
loading fairly slowly, so– And all this is done
with no special code. There is a small
portability layer that Google Earth has had for
a very long time, which we’ve adapted to use the Pepper API. And we have JavaScript code,
which is written for this demo. And that’s it. Everything else is
exactly the code that we deploy everywhere else. And Google Earth is not
a simple application. So, let’s go back here. So there are few
caveats about this. One is, that with great power
comes great responsibility. When you have a
blocking API like this, you are actually going to
block Chrome’s renderer thread. So don’t wait long
before returning, or your users will notice
the performance drop. And also, similarly,
for the same reasons, prefer the asynchronous API,
whenever you can use it. The reason why that
is the primary API is for performance reasons. But now, if your
porting an NPAPI API, or some other API that
requires synchronous calls, you have that
option open to you. So happy hacking. And if you’re wondering
what to do next, we have some
suggestions for you. First of all, contribute
your Open Source product, or for that matter, somebody
else’s Open Source product to NaClports, the
URL is right here. And if you want to learn
more about NaCl and PNaCl, go to Thank
you very, very much. So I’m going to open
it up for questions. If anybody would like to– AUDIENCE: So, you guys said that
you ported the IPython notebook to PNaCl. Two questions. First of all, is
that somewhere to be found on the internet
for me to use? KESTER TONG: Yeah, it’s
actually inside the NaCl ports repository. AUDIENCE: Oh, very good. And secondly, you said
it’s ported to PNaCl, does the porting process differ
when porting to NaCl when compared to PNaCl, or is
it basically convertible? SAM CLEGG: It’s
slightly different. There’s a different compiler. With PNaCl, we’re using a
Clang based compiler, an LLVM. With NaCl, it’s a
DTC based compiler. The other main
limitation is that PNaCl doesn’t support
inline assembler. So if you have inline
assembler for x86 ARM, today you can’t use
that in the PNaCl world. But it does support
intrinsics for SIMD primitive, so you can get
some of the high performance that you might be looking
for in your assembly code. AUDIENCE: Thank you. KESTER TONG: I
just wanted to add, that only the kernel is
on NaCl ports right now. SAM CLEGG: But you are planning
on publishing that app publicly in the future, right? KESTER TONG: We’ll be making
an announcement next week at the [? SciFi ?]
conference regarding the open sourcing
of the rest of it. SAM CLEGG: Cool. AUDIENCE: You’re competing with
and Emscripten and asm.js so can just talk about the
trade offs between the two, and where you think
each one is stronger? SAM CLEGG: Yeah, there’s a
lot of similarities there. Some of the things that
we allow are currently impossible in Emscripten,
like background threads and blocking APIs. So we can actually
implement fopen and fread, where it goes to the network and
blocks for any amount of time. So some of the stuff you have
to do to go to Emscripten, you don’t have to do
to go to NaCl today. There are lots of
different trade offs. Our stuff has been
available for a bit longer, so it’s a bit more
mature, probably. It’s been in production
for several years now. There are probably
other people here who can speak more to the
subtleties between the two. But PNaCl and
Emscripten both use the same LLVM based tool chain. And they even share
some of the LLVM passes. So, there’s some
amount of convergence that the two teams– and they
do communicate, the two teams. You can expect more convergence
in the future, I think. AUDIENCE: Is there an example? Obviously, you probably
don’t have the source code for Google Earth out there. But do you have
another example code that uses– does
that use OpenGL? SAM CLEGG: Yes, that
uses OpenGL ES 2.0, which is what Native Client provides. You can either look in
the SDK, for our examples. Or you can look on NaClports,
the projects I mentioned, where you can see over 100
Open Source applications that run inside Native Client. AUDIENCE: And you
were also talking about being able to have
JavaScript on top of– SAM CLEGG: Yeah, so– AUDIENCE: what
exactly do you mean? And how does that work? SAM CLEGG: So, in
Native Client, you can either render to a 2D canvas
or a 3D canvas, like WebGL. And the canvases, if I’m right,
behave very, very similarly to HTML5 canvas and 3D canvas. It’s just an element. AUDIENCE: Yeah, so it’s just
a surface that you can– it’s a surface in the
JavaScript based web– BRIAN ELLIS: It’s actually
even simpler than that. You can simply overlay DIVs
on top of the NaCl embed, and it will composite correctly
with Alpha, and everything. AUDIENCE: This is only
available in Chrome, still? BEN SMITH: Yeah, it’s
only available in Chrome. AUDIENCE: You haven’t
convinced anybody else that it’s an Open
Source project? Presumably, it
could be included– BEN SMITH: Sorry, say again? AUDIENCE: I said, NaCl,
PNaCl, Open Source project. Conceivably it could be included
in Firefox, or whatever? BEN SMITH: Conceivably,
it could be. But I don’t believe that there’s
any plans for other browsers. AUDIENCE: Does this run
on Chrome on Android? BEN SMITH: It does not, no. Not currently, although
there are plans. FEMALE SPEAKER: Another
thing to point out is the Pepper JS
library, which lets you take an application
that’s targeting portable Native Client
and the Pepper APIs, and then compile that
using Emscripten, and we’ll create polyfills
of the Pepper APIs that target
JavaScript back ends. So, given that you’re
using the Pepper APIs it will make your life easier to
then port to an asm.js version. So we’re definitely trying to
work with the community here, and the different
technologies available, to give our developers
the best option. SAM CLEGG: Yes, so
using that technology, you can produce a JavaScript
file using Emscripten, and a PNaCl file using our tool
chain, from the same source code. That’s the idea. So then you could have a
cross platform solution. BEN SMITH: And
there are examples of that on, I think
it’s, FEMALE SPEAKER: More questions? AUDIENCE: So if I
want to use SIMD, then the x86 and ARM
intrinsics are different. So what do you actually support? BEN SMITH: So it
uses LLVM intrinsics, which are recently introduced. And there are examples of
that in the most recent STK, as well. So, it will look very
much like– anything that’s not actually implemented
by that processor will be sort of filled in
whatever way necessary. So it will always work. It’s just a question of will
it be– it won’t necessarily be as fast if the [INAUDIBLE]
doesn’t support it. AUDIENCE: I’m not familiar
with the LLVM intrinsics. Are they four at a time,
or eight, or sixteen, or–? BEN SMITH: You can
actually specify. There’s many different sizes. I think, currently, we
only support 128 bit wide, but we have plans to support
larger, is my understanding. AUDIENCE: Thanks. FEMALE SPEAKER: If
you want to learn more about Portable Native
Client and SIMD intrinsics, there’s also two videos that
we recorded and launched under the Google
I/O DevBytes site. And so, you can watch J.F.,
who implemented the SIMD intrinsics, tell you about
exactly how he did it and how he chose which
subset was super portable. And then also Brad
Nelson, who’s talking about a new developer,
editor, that we have created, so that you could
actually debug and edit your programs running
on a Chrome book. Go check that out. SAM CLEGG: Yeah, this
development environment actually at uses PNaCl
to run GCC, and vim, and bash, and make,
all inside of a tab. So we’re trying to get as
much with POSIX as possible to allow you to actually do
your development in Chrome, on a Chrome book. AUDIENCE: What about e.max? SAM CLEGG: E.max is coming. We have that in the pipeline. The build system for e.max
is a little bit crazy, so that’s the main
other questions? Cool. Thank you so much for listening,
and go check out PNaCl.

Google I/O 2014 – Distributing Native Code on the web using PNaCl
Tagged on:                                 

2 thoughts on “Google I/O 2014 – Distributing Native Code on the web using PNaCl

  • July 10, 2014 at 10:32 pm

    Will you guys sell them abroad? Specifically malaysia?

  • July 11, 2014 at 5:00 am

    promising, but the several errors make think this is not quite the pinnacle we're hoping for 😛


Leave a Reply

Your email address will not be published. Required fields are marked *