MALE SPEAKER: OK.
So say we solve off line.
And we improve the layout and
paint, and all that stuff.
That's great and
all, but there's
another piece of
the puzzle missing.
And that's raw computation.
So you wanted to do
something like a physics
engine or real-time
video analysis.
Pick out things that
are in an image.
Face recognition over a whole
audience full of people.
Can we get the performance
of near-native code
without throwing security
out of the window?
Well, here to say yes, and
hopefully some other words,
it's Molly Mackinlay and
David Sehr, everyone.
[APPLAUSE]
DAVID SEHR: So it is really
the last talk of the day,
so I don't want to
keep you too long.
But we're going to talk
to you about something
we think is really great--
Portable Native Client.
I'm David Sehr.
I'm the TL of the
Native Client team.
MOLLY MACKINLAY: And
I'm Molly Mackinlay.
I'm the PM on the
Native Client team.
And you are getting to your
drinks soon, I promise.
But we really appreciate
your attention
for this final talk of the day.
So I want to start off about
where Linus started off,
with the fact that we
have a new web today.
Our expectations for what you
can do on the web are changing.
This native app on a
phone, versus a native app
on a computer, versus
a website that you're
navigating to-- these are
all starting to emerge.
We aren't in the '90s anymore.
Back in 1995, we had a
website that was mostly text.
There were some links.
You could click on some stuff.
But mostly, it was
text, as you can see.
We ended up having new
ways to link to things.
We had Yahoo, Microsoft,
and even Google.
It was pretty basic,
our interactions we had.
Fast forward to today, and
we have much more rich ways
of interacting with websites.
Now we have interactive video
editing, data visualization,
ways of showing what our
solar system looks like,
and mapping applications.
The web today is way more rich.
One example, the Google+
Photos application.
This is something you'd
expect much more on desktop,
in Photoshop, than in a
web application you just
navigate to.
I'm going to start
off with a fast demo,
just to keep you guys
from getting bored.
So here, hopefully, is my lion.
Let's go into the Edit mode.
Move this over here.
Maybe resize our window a
little bit, potentially.
Drag.
[? Green slide. ?]
That might work.
Perfect.
OK.
Lion.
Huzzah.
We can do some cool stuff,
like tuning our image.
You can go and play with
some sliders yourself.
Or just go with what
they're suggesting.
We could Pop or Moody.
Kinda cool.
I'm always a Pop person.
Let's go saturation level up.
And apply that for
a little while.
We also have a lot of
really cool filters
that you can apply,
just right there.
Some of my favorites
are these retro looks.
I'm not retro, I don't know
what that really means,
but they look cool.
So Voyager is a fun one.
You can also just shuffle
through it randomly
until you find one you like.
Wow, that looks funky.
OK, let's apply that.
And then bam, you have a
completely different image.
Like, I don't know Photoshop.
I would not know how to
do that if you put me
on a native
application, and I had
to edit this pixel by pixel.
But compare the
images we have now.
I've created a completely
different, and different style
image than I had before.
It's a really rich experience.
And I think you'll all
agree, 20 years ago
you would not see
this on a website.
Today we're
expecting a lot more.
Continuing on, these
native features,
they're coming to
our web applications.
Back in the day,
AutoCAD-- it really
could only exist on a PC.
Now there's a
Chrome app for that.
We're not only asking for the
native capabilities in our web.
We're having to ask developers
to develop for many platforms.
They have a C++ application,
an Objective-C application,
a JavaScript application.
They're maintaining
many development stacks.
Wouldn't it be great
if we could only
maintain one stack
that could then
be applied to these many
different platforms?
Now that's an ideal I
would like to fight for.
DAVID SEHR: OK, from
almost the beginning,
people recognized, I think, the
potential of a web platform.
But as Molly just described
just a second ago,
the web didn't really have the
capability at the beginning
to do some of these rich
interactions that we wanted.
So way back in the mid
'90s, browser vendors
added extension platforms,
or extension APIs.
What in fact were things
like ActiveX and NPAPI.
These were ways to get at the
underlying operating system
features for things like
embedding a media controller,
so you can listen to
your CDs, in those days.
Or put up a local
database server.
And these were
ways, as I say, that
give you access to
some of the features
that they thought were
cool in the native platform
by drilling through
with these plugins
to the underlying
native capabilities.
Now, because these were
coding to the underlying
native operating
system, they tended
to be either platform specific,
in the case of ActiveX.
Or things like NPAPI, where
you had to kind of know
which platform you
were going to be on.
So it was going to be compiled
for Windows or for Linux
or for Mac, depending upon
which browser the user happened
to be running at the time.
Maybe a different set of
browser APIs, et cetera.
So this is kind of a
complicated and cumbersome sort
of way of programming
these things.
And so you see at
about the same time,
these plugins come up
that provide capabilities
for getting at those underlying
operating system features,
but through better
programming approaches.
So you have Java.
You have Flash and its
predecessors coming.
And these are ways,
again, that gave you
access to some of the
underlying features,
such as canvases to draw on or
underlying database engines, et
cetera.
And much later, then
you have Silverlight,
which is giving you the
capability to do this.
And of course across a
broad spectrum of languages
on the .NET framework.
So this is sort of what
happened between the '90s
and the mid-2000s were plugins.
Now, plugins had a
number of issues,
as I'm sure you're all aware.
Plugins have this user
interaction where, gee, I
go to a page, and it
says I need Flash.
But I don't have
Flash installed,
so I get this popup saying
I need to install Flash.
Or I need Silverlight
for this content.
Or I as a developer
need to know,
am I going to get
to the people I
want to get to if they don't
have the plugins installed?
So it's kind of an unfortunate
interaction that way.
And also, the plugins
tended to be-- well,
you had what was running
inside the plugin.
And you had what was
running outside the plugin.
And there was always this
sort of jarring interaction
between them.
Which made for
sort of clunky UI,
if you didn't really work very
hard at isolating that, or not
isolating that little box,
that had your Java applet
running in it, from
the rest of the page.
And sort of most concerning
of all, all of the plugin APIs
provided you with direct, native
access to the operating system.
And that made the
possibility that bugs
became security issues.
And not just became
security issues,
became security issues
that were prevalent
just about everywhere.
And just about all the plugins
we see security issues that
have become-- and this is
2009, 2010 from Symantec--
become serious issues
for security on the web.
So fast forward now to 2008.
2008, JavaScript
takes a new turn.
Kernel ignites the
JavaScript performance spiral
that we've all witnessed
over the last five years.
And the web's not been static.
The browser has been growing
this open web platform that
has all these features we've
been hearing about today
and we'll hear about tomorrow.
And so it's a much
richer platform.
So with JavaScript's
performance coming up
and the platform getting
richer, a new approach
to bringing native code to
the web comes to the fore.
And that's exemplified
by Emscripten.
Emscripten is you compile
from native to JavaScript
and run it in the web platform.
And Emscripten, we think, you
get the access to the features
that you're after and
some of the performance--
most of the
performance, perhaps.
But there are some issues
still with Emscripten.
The first one is,
if you're really
developing a native application,
and it has memory management
issues, for instance,
debugging a null pointer
check in JavaScript is
not as easy as it sounds.
Also, if you're trying to get
to all the native capabilities,
for instance, threads,
it's not there yet.
And furthermore, I said
most of the performance.
Perhaps we get to 2x, within
2x of native performance.
You would still like
to get to the remainder
of that performance.
So that brings us
to, why are we trying
to bring native code to the web?
Why are we talking about
bringing native code
to the web?
As I said, we still think
there's better performance yet
to be had.
From features like
threading, as well as
from that last 50%
or more, and also
increasing the
developer options.
So in this team, we started
the Native Client project.
And the Native
Client Project was
about bringing native
capabilities-- threads,
[? sending ?] instructions, et
cetera-- from the beginning.
Bringing performance.
Trying to get as close
to native performance
as we could get while
still securely executing
your application
in the web browser.
And a familiar developer
model, so you can use GDB.
And if you're a
native developer,
you can debug in
the way that you've
become accustomed to developing.
MOLLY MACKINLAY: In
addition to trying
to bring all of these native
capabilities in performance,
we're also trying to do
something really simple.
We're trying to open up
the web to all developers,
not just developers who have
been graced with the ability
to learn JavaScript.
Many people start out
learning a C or C++ class.
And they go and they
build applications
that are useful and interesting.
And everyone wants to have
access to those things,
but they've been unable to
bring those to the web so far.
And we want to give
them that opportunity.
There are many different
coding languages
that need to be brought.
And we're looking
forward to doing that.
An example of that is
the Bullet Physics demo
that we released with
Portable Native Client.
Let me navigate over here.
Well, maybe navigate over here.
Well, you can see
a sliver of it.
That's something.
Let's expand this again.
Cool.
This is mostly a
JavaScript application.
What it's done is taken a C
library, the Bullet Physics
library, and just embed
that capability in itself.
Now I can interact
with my Jenga thing.
I'm really bad at Jenga.
I've learned that
through this application.
And I can, as a
JavaScript developer,
take advantage of this C
library right here in my page.
And play around
with some things.
Knock over lots of bricks.
So that's one example of
how we could take advantage
of Portable Native Client
to bring native performance
to the web and
native capabilities.
Now let's say that I'm
actually a C and C++ developer,
and that's what I'm
comfortable with.
All right, fine.
I can also-- this is an example
of Lua, a Lua interpreter.
This is written
almost entirely in C.
And I can go and
take my native code
and run it right
here, on the web.
Here I have a--
well, actually, I
don't know if this
is going to render
very well in our
weirdly-- oh, donuts.
That's surprisingly--
DAVID SEHR: And who
doesn't like donuts here?
MOLLY MACKINLAY: So this
is mostly a C application.
And I've brought it to the web.
I've brought it to all of
the viewers and people that
can experience it there.
So either way, no matter
what language I develop in,
I now have access to
the web, to bring that
to all of the people who
want to interact with it.
DAVID SEHR: OK.
So you've seen
some of the things
that we're trying
to bring to the web.
And you've seen a
demonstration, in fact,
of some of these things
actually running in the web.
So what is Portable
Native Client?
Portable Native
Client is native code,
security, platform independence.
This is the web we're
talking about here.
We want it to run on
all these platforms
we talked about before.
And performance, performance
as close to native
as we can give
you, with security.
MOLLY MACKINLAY: So
let's talk a little bit
about how we give
you access to native.
Now, this touches a little bit
on Joe's presentation earlier.
But we're using the
Pepper API in order
to give you access to
the native capabilities.
This gives you secure access
to things like USB, OpenGL,
mouse cursor lock, full screen,
and TCP and UDP messaging.
This gives you really
all of the feature
set of a native application,
but in a secure fashion.
DAVID SEHR: OK.
So security I talked
about just a moment ago.
So you want to put
this wonderful piece
that you've put into
your application.
Now, this is a screenshot of
[? Air Mac, ?] which is not
running on PNaCl,
for full disclosure.
But this is the sort
of thing that people
are doing with
Portable Native Client.
So you want to put your piece
of native code in the web.
Well, there are all
these browser APIs
that the plugin APIs
gave you access to.
There are also underlying
operating system APIs.
And we said before
that unfiltered access
to those things was what
gave rise to the security
issues we've all come to
know and [? loathe. ?]
What kind of security issues?
Going and snagging your cookies,
doing something inappropriate
with that.
Going and sending your
credit card number
cross-site to some
malicious site.
Putting a keylogger
in that'll follow you
for the rest of your session.
Turning on your cam and
watching all sorts of things
that you don't want
the web to know about.
Or scraping your screen and
finding your bank account
numbers, or other things that
might be up on another window.
These are the kinds
of things that
unfiltered API access can give
you that are really scary.
So we're about providing
access to the features
that Molly just
talked about, but not
through unfiltered
access to these APIs.
So with regard to
platform independence,
Native Client from
the start was x86.
We added ARM a year or so ago.
And in fact, as Joe said before,
four out of the top five Amazon
laptops are ARM devices
running Chrome OS.
This is something we have a
very central commitment to.
And we also run on the
other desktop platforms
that Chrome runs on-- Windows,
Mac, Linux, Chrome OS.
MOLLY MACKINLAY: Now,
it's really important
to be platform independent.
But I think you'll
all agree that we
want to run on every browser.
And unfortunately right
now, PNaCl is Chrome only.
But we want to have a
cross-browser story as well.
Now, if you're
developing for native,
this is kind of what your
application structure would
look like.
You have your C++ file.
It targets the Pepper
API to get access
to all of those native
capabilities, which then talks
to the browser and gives
you the right link up.
If you're making a
PNaCl application,
you'd compile your C++ file
to a portable executable--
what we call a pexe-- and
that talks to the Pepper API,
which is included in Chrome.
Now, if you want to go and run
your application on another
browser, you'd compile your
C++ file using Emscripten
into a JavaScript file.
Now that would start trying
to talk to the Pepper API,
but that's not implemented
on another browser.
We've created a solution
called pepper.js.
This links up the calls in
your JavaScript application
to the JavaScript APIs
in other browsers.
Now your application can go
and run on multiple browsers.
Example is one of
our demos, Voronoi.
If I go over here, here I
have the Voronoi application.
It has all of these dots.
They're running around.
I can refresh it.
I'm running in
the PNaCl version,
so that means that I can
hopefully scroll down here
to the bottom.
Hypothetically, I could
scroll down to the bottom
and show you that I could
bump up our thread count
and make this run even faster.
Maybe I can still do that.
Cool.
Hypothetically.
Fair enough.
This always happens.
Another option is that I could
be running that same demo,
right here on my Nexus tablet.
Which I could potentially
show you using the screen.
Or I could just hold it
up, and you could all tell.
Notice, it's running.
It looks wonderful.
And there's lots of points
and they're animating.
And I would try
and do this, but I
don't think it
would do anything.
Fair enough.
DAVID SEHR: OK, so Molly
gave you the visual demos.
So here's the boring
text version of this.
Across a broad variety of
benchmarks that we've run,
we've seen overheads
are actually,
relative to native performance,
in the 80 to 90% range.
So we're able to
give you performance
which is very close to native,
while keeping the security
benefits we talked about before.
And we're not the only ones.
People in the broad
benchmark Native Client
as being the closest
sort of approach
to native code performance, even
after the asm.js announcements.
So that's what you get.
What do you have to do
to get a Native Client
application going,
and what's actually
going on under the hood?
So you have your cool
piece of source code.
You use our tool
called pnacl.clang.
So we've based this
off the LLVM toolchain.
The pexe, or the
portable executable,
is actually a modified
version of LLVM bitcode
that has been made a little
better for long-term use
on the web.
Once you put something
up on the web,
the expectation is that it's
going to work for a long time
to come.
So we made some simplifications
to make that more possible.
So you compile
using our toolchain.
And you add this-- again,
we have a manifest file.
The manifest file
gives you a way
to specify where to find the
portable executable and also
a way to specify some
metadata, some things
about relative translation time
versus delivered performance
trade offs, and such things.
You put an embed
tag in, and boom.
You have a page that's enabled
to run Portable Native Client.
Now your user
comes and starts up
the page that you just put up.
And the browser,
Chrome, is going
to see, well, there's
that embed tag.
And it says that I'm
going to be referring
to a portable executable.
And of course, it's portable.
It's not something I run
natively on the platform.
So it's going to say,
I need a translation
of that to run on my platform.
So it'll ask for a translation.
The translation then is done
by something called the PNaCl
translator.
Again, that's based on
part of the LLVM toolchain.
In this case, it's one
of the LLVM backends.
And the translator,
while streaming
the portable executable
down, is translating
the portable executable
into something,
in this case, a native
ELF executable that
actually runs on your platform.
And running on
your platform-- OK,
I just told you all the security
that you want to prevent.
So we use something called
software fault isolation.
And software fault
isolation creates a region,
that we call the sandbox,
that you can guarantee
that the executable can
only execute instructions
that we've looked at--
the browser's looked at.
That the instructions are
ones that are acceptable.
And that they don't only
refer to memory that's
in the application's
address range.
So with that, this little piece
of the Native Client technology
called a validator
actually validates
those sets of constraints.
And with that, it can
determine whether it's
possible for this application
to have access to these APIs
that we said were
dangerous before.
And if it can't
validate the executable,
if it can't prove that it
doesn't do these bad things,
then we just flat refuse
to start the executable.
So.
On the other hand,
if it can show
that this set of changes to
the underlying instructions
are followed, then
we don't allow,
or we won't be able
to get native access,
unfiltered access to those
APIs, and it can run safely.
So if it starts running, we
start it running at that point.
And we start it running.
All the while it's
running, if it
wants to interact with
the outside system,
it interacts through something
we call the Native Client
Runtime.
And the Native Client
Runtime will also
enforce security
policies that we'll
talk about in just a second.
Now you might
remember, some of you,
that in fact, whenever you
run a web page in Chrome,
that page is actually
running in an outer sandbox.
And so one more thing-- the
Native Client sandbox is also
running inside the
Chrome sandbox.
So we have sandboxes
inside of sandboxes.
For the "Inception"
challenge, that's-- anyway.
So we have sandboxes
inside of sandboxes.
And with this, we've crafted
the cones of silence.
Right?
So now we have two processes
that can't talk to each other.
And of course, that
hearkens back to PPAPI
is the way that applications can
securely talk to the browser,
and get access to
these native features
that the application wants,
and retain the security
that we need for
the native code.
MOLLY MACKINLAY:
So we've told you
a little bit about why we
need native code in the web.
We've shown the performance
benefits you can get.
And we've told you a little
bit about how we do it,
how this works under the hood.
So where we going
with this next?
We're trying to bring these
native capabilities to the web,
because it enables a really rich
interaction, a really rich set
of applications, that
we believe should exist.
But we're not quite done.
We want to keep improving
on our techniques,
on how we get these
applications up and running.
I'm going to give you a little
bit of an analogy in explaining
our future directions on how
to make this even better.
First off, we want to
speed up your lion.
We want to increase
your translation time.
A user navigates
to your page that's
running a PNaCl executable.
It should load as quick
as we can make it.
We also want to make
you even more capable,
give your lion some claws.
We're going to give you
both C++ exception handling
and vectorized
instructions in PNaCl.
We're also going to decrease
the size of your PNaCl bitcode,
so that your page can load.
And it'll download over
those crappy connections
we've been talking about all
day, as quickly as we can.
Finally, we really want
to be responsive to you,
our developer community,
and moving forward
in figuring out what are the
things that you need in order
to make this the next rich
platform, the next way
to make really
amazing applications.
Thank you so much for your time.
Please visit gonacl.com
if you have any questions.
I'm not going to
hold you any longer.
Go five minutes early.
Have some drinks.
And please come
and chat with us.
We'll be right up here.
Thank you so much for today.
It's been wonderful.
And cheers.
[APPLAUSE]
