Using WebAssembly and Threads (Chrome Dev Summit 2018) - VoiceTube: Learn English through videos!

Subtitles section Play video

[MUSIC PLAYING]
THOMAS NATTESTAD: My name is Thomas,
and I'm the product manager for WebAssembly.
ALEX DANILO: My name is Alex, and I'm a software engineer
on Chrome OS.
THOMAS NATTESTAD: And today we're
going to talk to you about WebAssembly.
We're going to start off by briefly
describing what WebAssembly is and what you can use it for.
Then I want to show off some of the amazing new features
that the WebAssembly team has been working on to deliver
to you in this last year.
Then I'll showcase some of the amazing applications
that have managed to build with WebAssembly,
and our shipping and production.
All right.
So first off, what is WebAssembly, actually?
WebAssembly is a new language for the web,
and offers an alternative to JavaScript for expressing logic
on the web platform.
It's important to note, though, that WebAssembly is in no way
a replacement for JavaScript.
Rather, it's designed to fill the gaps that
exist in JavaScript today.
Specifically, WebAssembly is designed as a compilation
target, meaning that you write in higher level languages,
such as C++, and then compile into WebAssembly.
WebAssembly is also designed to deliver
reliable and maximized performance, which
is something that can be difficult to get out
of JavaScript.
Most exciting, though, is the fact
that WebAssembly is now shipping in all four major browsers,
making it the first new language to be fully supported
in every major browser since JavaScript was
created more than 20 years ago.
All right.
So what can you actually do with this?
Well, as I already mentioned, because WebAssembly offers
maximized and reliable performance,
you can now expand the set of things
that you can feasibly do in the browser.
Things like video editing, complex application, codecs,
digital signal processing, and many, many more
performance-demanding use cases can now
be supported on the web.
Secondly, WebAssembly offers amazing portability.
Because you can compile from other languages,
you can port not only your own applications and libraries
but also the wealth of open-source C++ libraries
and applications that have been written.
Lastly, and potentially most exciting to many of you,
is the promise for more flexibility
when writing for the web.
Since the web's inception, JavaScript
has been the only fully supported way
to execute code on the web, and now with WebAssembly you
have more choice.
All right, so now that we all know what WebAssembly is,
I want to jump in and show off some of the new features
that we've been adding in just the last year.
First off is source maps.
You likely all know how important source maps are
when you're working with something like TypeScript
or Babel, but it's even more important
when you're trying to debug your WebAssembly code.
Source maps let you turn something
that looks like this into something just slightly more
friendly, like this.
With source maps you can see the specific line of code
where an error has occurred and you can also
set breakpoints and have the program actually pause
at the appropriate moment.
One of the big feature requests that we've heard from users
is for better performance when you're starting up
your application so that your module can actually
get going faster.
And for that we've created streaming compilation.
In the past, when you wanted to compile a module
you had to wait for the entire module
to be loaded off of the network, and only then could
you move on and actually compile it.
Now with streaming compilation, you
can start compiling each piece of your module
immediately, even before the other parts have
finished downloading.
To show you what that actually looks like,
here's a simple example where we called a fetch function--
or fetch for a WebAssembly Fibonacci module,
and then we just passed that fetch promise directly
into WebAssembly.inst antiateStreaming,
and it takes care of all of this underlying bits
and pieces for you to deliver this experience.
We did some profiling at different network speeds
to see the impact of this.
We found that all the way up until 50 megabits
per second network speed, the network
was actually the primary bottleneck,
and that the compilation was done as soon as the module was
loaded.
It wasn't until you hit the 100 megabits per second speeds
that you actually needed additional time past the time
it took to download the module in order to fully
compile and get it going.
To make startup time even faster,
the team built and launched an entire new compiler
that we called the Liftoff compiler.
This Liftoff compiler takes the WebAssembly byte code
that comes down off of the wire and then starts executing it
immediately.
The WebAssembly module is then taken off the main thread
and optimized further by the TurboFan optimizing compiler.
When TurboFan is done optimizing the WebAssembly code,
it's then hot swapped in directly
without any need for explicit developer action.
Unity did some benchmarking on the effects that Liftoff had.
On a benchmark where they tried to load a very large game,
they found that it went from taking seven seconds to load
the game to less than one second, which
makes all of the difference when you're waiting
to get into a game experience.
Probably the biggest feature that the team's
been working on this year is WebAssembly threads.
WebAssembly threads lets you run fast, highly paralyzed code
for the first time across multiple browsers.
It also lets you bring existing libraries and applications
that use threaded code such as Pthreads to the web.
This is such a big feature that I'm actually
going to leave most of the explanation to Alex later on.
But before I get into that, I want
to show off some of the cool new applications
that have already been building and launching with WebAssembly
this last year.
First off is SketchUp.
SketchUp is a 3D modeling software
that you can learn and start using really quickly.
Unlike traditional computer-aided design,
most people can learn SketchUp almost right away.
SketchUp lets people draw in perspective and then
push-pull things into 3D.
In no time, people can draw and redesign a living room,
plan out a do-it-yourself project,
or create and export a model for 3D printing.
This app is a lot of fun and you should all check it out,
which you can do right now instantly, just
by going to app.sketchup.com.
SketchUp has been around for a desktop application,
but the team's strategy has always
been to expand and broaden the market
of people who can use 3D modeling,
and by making it simple and easy to use
and accessible to everyone.
Delivering the app over the web was a critical step
in that strategy, and the team knew
that they wanted to use the same code
base as their desktop applications,
because rewriting their entire application in JavaScript
was just simply not an option.
The team's approach was to use the WebAssembly and Emscripten
compiler to compile their core 3D modeler
and bring it to the web.
The initial port took two engineers only three months
to bring to the web, which is pretty phenomenal when
you realize just how drastically it expanded
the reach of their application.
The early focus for SketchUp has always
been on the next generation of 3D modelers,
and today SketchUp is already one
of the most popular apps on the G Suite for education
marketplace.
At the same time, the app has opened up a subscription model
for SketchUp, and in just over six months,
the team has increased its paying customer base by 10%.
SketchUp has also seen consistent growth
in session time, returning visitor percentage,
and active users.
Moving on, the next application that I want to mention
is Google Earth.
I'm happy to say that Google Earth has successfully
gotten their application ported to WebAssembly, including
the newly added support for WebAssembly threads.
The best part is that they actually
got this threaded build working in both Chrome and Firefox,
making Google Earth the first WebAssembly
multi-threaded application to be running in multiple browsers.
Google Earth did some benchmarking,
comparing their single threaded version
to their multi-threaded version.
They found that the frame rate almost
doubled when they went to their threaded version,
and the amount of jank/dropped also reduced by more than half.
All right, so the last big company
and launch that I want to mention is Soundation.
Soundation is a web-based music studio
that enables anyone to make music
online with a wide selection of instruments, loops, samples,
and effects.
No additional hardware or installation or storage
is required.
Everything is accessible instantly and everywhere.
Soundation's mission is to facilitate musical creativity
in the world, and they do this by offering
a powerful, accessible, and affordable service
to the growing demographic of casual producers.
As an online web app, Soundation streamlines
the ability for producers to connect with peers,
get feedback, enter competitions, and even get
record deals.
Soundation is using a wide variety
of advanced web features to deliver this smooth experience.
And the first of these is audio worklets.
Launched in Chrome 66, the audio worklet
brings fast performance and extensible audio processing
to the web platform.
It could be used in conjunction with other cutting edge web
technologies such as WebAssembly and SharedArrayBuffer.
Soundation is also one of the world's first adopters
of WebAssembly threads, and they use these threads
to achieve fast parellelized processing to seamlessly mix
songs.
So let's have a look at their architecture
and see if we can learn anything.
On the JavaScript side of the world,
they have their application UI.
That application UI then talks to an audio mixing engine.
This audio mixing engine then spawns off
multiple different worker threads in WebAssembly,
and each of these worker threads can
talk to the same piece of SharedArrayBuffer memory.
This SharedArrayBuffer memory is then
passed on to the mixing threads, which further passes it
to the audio worklet, which produces the final result.
Here's a visualization showing the performance improvements
on rendering a song as they added multiple threads.
Adding just a single additional thread doubled
their performance, and by the time
they've added five threads, they had more than
tripled the performance of their application.
So that's a great visualization showing the performance
improvements that thread can bring,
but since this is Soundation, I thought we would instead
try and listen to it.
So here is us trying to render a song in Soundation
in the single threaded version of WebAssembly.
And fair warning, this is not going
to be an entirely pleasant experience.
[STATICY MUSIC]
So as you can imagine, this is not the experience
that you want when you're trying to create beautiful music.
But luckily Soundation succeeded in launching with WebAssembly
threads, and now they're able to deliver
an experience that sounds just a little bit better.
[SMOOTH MUSIC]
So as you can see, not only is this a much more
pleasant experience, but the CPU also
has additional cycle for other work.
All right, so I want to close off my segment by just talking
about some of the amazing community
projects that we've seen people working on out there.
And the first of these that I want to mention
is the awesome work that's been done by the Mozilla
team and the Rust community to bring Rust to the web
through WebAssembly.
They have an awesome set of tools and materials
to help you get started, and you can check those out
at rustwasm.github.io.
Speaking of languages, we've also
seen more than 30 different projects
trying to bring other languages to the web through WebAssembly.
These languages include ones like Perl, Python, Ruby,
Kotlin, OCaml, Go, PHP, and the .NET framework.
Many of these languages require garbage collection,
which isn't currently something that's
supported in WebAssembly, though we are working on it.
These languages come to the web by actually taking
their garbage collection system and other runtime bits
and compiling that itself down to WebAssembly,
and then shipping everything down to the application page.
This is a great strategy for getting started
and experimenting with some of these languages on the web,
but because of some of their performance and memory
characteristics, these aren't currently suited
for production applications.
The fully supported languages today are C, C++, and Rust,
but everything else should still be considered experimental.
And there are so many more amazing community projects
that I don't have time to do justice.
We've seen people porting Gameboy emulators, GNU
libraries, digital signal processing, and even
entire operating system like Microsoft Windows 2000 now
available in a browser tab, which
is, if not a exactly pleasant experience,
definitely interesting.
You can check out all of these demos
and much more at the forum where we have multiple demos
set up for you to check out.
And with that, I want to hand it back off to Alex
to talk to you more about WebAssembly threads
and how to use some of these features.
[APPLAUSE]
ALEX DANILO: Thank you, Thomas.
One of the kind of big things at the conference
here, when we talk about the browser,
we talk about using the platform.
And quite often people think of the platform as the software
stack that's inside the browser, but I
like to think of it a little bit different.
I like to think about the hardware, the platform that's
actually in your machine.
So here is an artist's rendition of the inside
of a desktop microprocessor.
This is what you see today if you
take the plastic off the top.
So at the top, we have the green bit,
which interfaces to the PCI bus, used
to be called the northbridge.
The left and right, you have memory interfaces.
These little yellow boxes are integrated memory controllers.
And you see all these blue tiles here.
And what they are is cores.
So each of those is a CPU core in its own right.
So this may be a desktop microprocessor, but even
in your pocket, if you have an iPhone or an advanced Android
phone, you'll have something like six
to eight cores in there, ready to be
used to do good computing work.
So when you write a normal web application,
you're looking at something like this.
You have one core running and so you have
all this silicon doing nothing.
So you're not really using the platform.
Now we've seen people come along and do something
like spawn a web worker to do the hard work,
and have the main thread for UI.
In that case, you're running a double threaded application.
And so you're using the platform a bit better,
but you're not really doing everything you could.
Now since we have introduced WebAssembly threads,
you can do stuff like this.
You could actually use many cores for your application.
And as we saw with the Soundation demo,
there's visible improvement in the user experience.
So I'd really like you to start thinking
about how you can adapt your application
to use all these cores.
Now when you create a web worker,
you have to understand that that is a threading primitive
and they run concurrently.
So you can do compute in parallel.
And this is a primitive that we all know pretty well.
But one of the things about when we do something
like this, if we have an app, on the left,
we have what we call the main thread--
we're all familiar with the main thread--
that interacts and talks to the DOM.
The worker that we generate is what
we call the background thread.
So it's running in parallel but it doesn't actually
have the ability to call web APIs
and interact with the DOM and stuff like that.
But when you create workers, and you create them
normally with a JavaScript thing, it creates an instance.
So these instances kind of sit on their own on the side,
they're running parallel, they don't get
to do anything with the DOM.
So they kind of run on the side.
So if you create one, you get V8 hanging off
the top of your main thread, and you get an instance hanging off
your worker.
So then if you go and create a bunch of workers,
you get a bunch more V8 instances.
Now each of these instances consumes memory.
So that means that if you start spawning lots of JavaScript
workers to make your application do stuff more complex,
it will actually consume more and more memory
and you might run out on a phone, or something like that.
But I'll let you in on a little secret.
They don't talk to each other.
So you've got separate bits of JavaScript
running in all these parallel threads,
but they don't communicate.
They don't have any shared state.
They're literally another copy of V8 sitting in memory.
The way these things can talk to each other,
though, is with postMessage.
And postMessage is kind of like sending a paper plane over.
I'll send it from this worker to that one,
I'll sit around and wait for it to arrive,
and there's no predictability about when
that will be delivered.
So it's not a great experience for a true multi-threaded
application.
Now, when the team built WebAssembly threads,
they implemented something that looks a lot more like this.
So what happens is, this is an example of, say,
having three threads.
So under the hood, we actually spin up the three web workers
but the difference here is that the WebAssembly module
is shared between the workers.
So there is one copy of the code,
so you're not consuming nearly as much memory.
But more importantly, they share state,
and the way they share state is through a thing
called SharedArrayBuffer.
So if you're a JavaScript engineer,
you probably know what a typed array is, because you use them
day to day.
So SharedArrayBuffer is basically the exact same thing,
except that it can be shared across workers.
And so what that means is the state
of the execution of the application is visible to any
of the workers in parallel.
Now if you farm off something into a pool of workers
and you have it hanging off your main app,
it will look something like this.
You'll have your main thread for your main application that
can talk to the DOM, it can use all the web APIs,
and it can see the SharedArrayBuffer,
and that SharedArrayBuffer is being
manipulated by all the parallel threads in the WebAssembly
module.
OK, but by now you're probably thinking,
this is all well and good, but how
do I use this stuff in my actual application?
So I'll start with a very simple example.
We'll do an example which is just a little Fibonacci program
that runs in two threads.
So it will look a bit like this.
There'll be the main thread, the background thread,
the WebAssembly module, all talking
to the SharedArrayBuffer.
So we just take some source code,
which will be something like this,
which is just a bit of C code.
And what we want to do is we want
to compile that into a form that we can use in parallel threads.
And the way we do that is with the Emscripten tool chain.
So it has a compiler called EMCC,
and there are a couple of flags here,
though, I want to point out.
The first one is -s USE_PTHREADS=1.
What that does is turn on the multi-threading support
when you're compiling your WebAssembly module.
The second flag that's interesting is -s
PTHREAD_POOL_SIZE=2.
What this does is tells the compiler
that I want to pre-allocate two threads for my application.
So when I actually start the WebAssembly module
it will pre-create two threads and get going with that.
Now this is kind of visualization
what would happen.
If you set PTHREAD pool size to two,
you get the picture on the left, you get two workers,
and if you set it to eight you get eight workers.
And that happens at startup time of your web app.
Now you may be wondering why you care about the number.
Well, the thing is that you should really try and set it
to the maximum number of threads.
If you say I only want two threads,
and then suddenly your application needs
three or four, it's a bit of a problem.
So what happens is that the WebAssembly module
has to yield to the main thread before it
can create that worker.
So if you're relying on all the threads being
there at the startup, you need to set the number high enough.
But of course, if you set that number too high,
you're wasting memory.
So this is something to tune.
So in Soundation's case they used five threads
and it works really well for them.
So when you're tuning your apps you need to think about it.
OK, so if you want to get out there and actually try
this stuff, which I'm sure you're all
dying to, if you fire up Chrome 70
and navigate to Chrome flags and search for WebAssembly thread
support, change the setting here from default
to enabled, and at that point, you'll
have to restart your browser.
And then you can start building stuff and testing it locally.
Now once you've built a working WebAssembly thread app,
you probably want to deploy it out to the public.
And the way you do that is by getting an origin trial token.
So an origin trial token is tied to your domain
and you get it from us.
And you basically-- it's just a meta tag
that you put on the page.
And that tells the browser, hey, these people
are trying WebAssembly threads and let's use it.
So if you want to go ahead and do that,
and I encourage you all to do so, just go to this short link,
and there's a form you can fill in, put
in your URL, the reason you want to use this stuff,
and go start building something really cool.
Now of course, as developers, we spend most of our times
in DevTools trying to debug things, which is how it is.
So in Chrome 70 at the moment, which is released to stable,
you can single step instructions.
And that is a WebAssembly instructions.
So it looks a little bit like this,
like not friendly, as Thomas pointed out.
So you can see this little box up here,
which is showing you the threads.
So this is a two thread application running.
And this box is the actual WebAssembly disassembled code.
So it's not the binary, it's a text form of the instructions
that are in the module.
And you can single step those and it's all
very well and good, but realistically, we don't really
like that debugging experience.
So Chrome 71 brings source map support,
as Thomas mentioned earlier.
So source maps lets you change what you saw before
into something-- oop, next slide--
something that looks like this.
So this is the source code of the Fibonacci function sitting
in Dev Tools, and you can single step over instructions,
you can set breakpoints, you can do all stuff like that.
Now, if you want to actually do this yourself
and you want to generate the source map,
you just need to set two flags on the EMCC compiler command
line.
The first is -g, which says generate debug symbols,
and the second is --source-map-base,
and that points to a URL where it will actually
find the source map file.
In this case, I'm using local host,
so I'll be using it on my own workstation.
OK, so I'll just recap on what we've talked about today,
just so you can remember what we talked about.
The first thing is it's streaming compilation,
which lets the browser compile the WebAssembly
module as it comes over the wire, which is launched now.
It's in Chrome 70, which speeds things up.
The second is Liftoff, which is the tiered compiler,
so you get the first compile really fast so your app starts,
and then hot swaps in the better code a bit later on.
Then we have, of course, WebAssembly threads shipping
now in Chrome 70, and you can use it with an origin trial,
so you can ship it to your customers
and they can use it and play with it.
And of course, Chrome 71, which will be out really soon,
contains source maps, which means
that it's a lot easier to debug your code.
And so I'd encourage all of you people
out there to start writing using WebAssembly threads,
because it unlocks the power of the supercomputer that's
sitting in your pocket right now.
Thank you.
[MUSIC PLAYING]