CppCast - WebAssembly

Episode Date: July 9, 2015

Rob and Jason are joined by JF Bastien to discuss WebAssembly. JF Bastien is a compiler engineer and tech lead on Google’s Chrome web browser, currently focusing on performance and security to bring portable, fast and secure code to the Web. JF is a member of the C++ standards committee, where his mechanical engineering degree serves little purpose. He’s worked on startup incubators, business jets, flight simulators, CPUs, dynamic binary translation, systems, and compilers. News C++ compile-time TETRIS C++ compiler front-end fixes in VS 2015 A variant for the everyday Joe JF Bastien @jfbastien JF Bastien's Github Links WebAssembly on Github C++ on the Web: ponies for developers without pwn'ing users

This episode of CppCast is sponsored by JetBrains, maker of excellent C++ developer tools including CLion, ReSharper for C++, and AppCode. Start your free evaluation today at jetbrains.com slash cppcast dash cpp. And by CppCon, the annual week-long face-to-face gathering for the entire C++ community. Get your ticket now during early bird registration until July 10th. Episode 19 of CppCast with guest JFBastion recorded July 8th, 2015. In this episode, we'll talk about playing Tetris with your C++ compiler. Then we'll interview JF Bastion about his work on the recent WebAssembly proposal. JF will talk to us about Emscripten, Panackel, and the future of the WebAssembly project. Welcome to episode 19 of CppCast, the only podcast for C++ developers by C++ developers.

I'm your host, Rob Irving, joined by my co-host, Jason Turner. Jason, how are you doing today? Doing all right, Rob. How are you doing? Doing good. Very busy right now. I have a little bit of an announcement, I guess. I haven't really talked much about my job

on the podcast, but I'm a mobile developer using C++ and for the past eight years I've been working at a company called ALK Technologies on a product called Copilot, which is a GPS navigation. Maybe some of you have used it.

It's available in all the app stores. But this is my last week at ALK. So I'm getting out of there on Friday. It's a really great company. If anyone's in New Jersey and is looking for something different, I definitely recommend going to ALK's website and looking for job openings. But I'm moving on down to North Carolina to join a different company working on similar type of products or similar type of projects. A company's called PAR Government.

And I'll be starting there next week. So I'm really excited. Uh, my family is, uh, all moving down there over the next few weeks. So it's pretty exciting. Congratulations, Rob. Yeah. Thank you. Um, and I should say congratulations to you as well. Uh, you want to give your announcement? I just made a Microsoft Visual C++ MVP. So that's exciting. That's definitely not something that I saw coming. Well, I mean, I had to submit my application for it, but I never expected to be submitting an application to become an MVP. Very cool.

And for those who don't know much about the Microsoft MVP program, it's basically, you know, for people who are contributing, you know, their own time and effort into, you know, enhancing the community. So, you know, C++ developers who use Visual Studio and write blog posts and work on open source libraries and things like that are the type of people eligible for that program. So congratulations, Jason. Thank you. So at the top of every episode, I like to read a piece of feedback.

This week, I'm going to read a comment from episode 15, which is the episode with Neal Douglas. And Paul Omta wrote in with this comment saying, this was a great episode. Someone coined the idea to make a small sidestep into D and or Rust and get guests to give an introduction about those languages. I would certainly

be interested in that. So we actually are going to have someone from the Rust community on next week. His name is Steve Klabnick, and I think he's a bit of an evangelist for the Rust language, so he's going to give us an overview of it and answer

some of our questions. So that'll be a good episode. Should definitely be interesting. Yeah, definitely. And maybe we'll get someone to represent Dee at a future episode. We always like to hear your feedback, though, so you can email us at feedback at cppcast.com, reach out to us on Facebook at facebook.com slash cppcast, or tweet at us at twitter.com

slash cppcast. So, joining us today is JF Bastion. JF is a compiler engineer and tech lead on Google's Chrome web browser, currently focusing on performance and security to bring portable, fast, and secure code to the web. JF is a member of the C++ Standards Committee, where his mechanical engineering degree serves little purpose. He's worked on startup incubators, business jets, flight simulators,

CPUs, dynamic binary translation systems, and compilers. JF, welcome to the show. Hey, guys. Thanks for the intro. It's a great intro. So we're obviously going to talk about WebAssembly in a little bit because you're the author of that spec. Is that correct?

Well, I'm not the author. It's actually a collaborative work with a bunch of other people right now mainly working on web browsers from different companies. But I'm one of the authors, you might say. Okay. We'll get to that in just a minute. First, just touch on a couple pieces of news. The first one is this kind of interesting article, blog post by Matt Bierner about C++ compile time Tetris. It's a rather long article. I'll be honest, I did not read the whole thing. But he basically built a Tetris game using the C++ compiler.

Do you guys have any thoughts on this one? It's a neat trick. I don't know if I could see using this in my regular work. Yeah. Yeah, it's a pretty cool trick, honestly. Yeah, it is. I'm not really sure if there are many lessons learned out of this one

that anyone could go and apply to everyday C++ code, but it's definitely interesting that he was able to pull off a Tetris game with the C++ compiler. What I would really be curious about, and I don't see here,

is what kind of FPS he manages to get with this. Yeah, it seems that every frame requires a recompile, so I would imagine pretty low. Yes, I would too. Could be an interesting test for compiler developers to try to speed up their compilers, maybe. I don't know. I'm not sure we'd be providing

the right incentives if we did that, though, right? Do you really want people to write code like that? I'm not sure. That's a good point. Anyway, the next article is from the Visual C++ team blog. They're getting very close to releasing Visual Studio 2015 RTM,

and they just posted this list of all the compiler front-end fixes that they've made in VS 2015. Apparently, since they first released the early beta versions of 2015, they have fixed over 750 submitted bugs in Visual Studio Connect. So congratulations to the C++ compiler team. They've obviously done a lot of work in resolving all these bugs. That's a lot of interesting things on that list. Yeah, certainly are.

I'm not sure if there are any specific ones you wanted to call out. Well, I mean, it's 750 items, so I didn't get through all of it. But this is completely random, but one of the things that stood out to me the most was noticing that they had alphabetized it by the name of the user that submitted the bug. Yeah, and some of these users are submitting a lot of bugs. They are. So congratulations to all these users for finding these bugs and obviously resulting in getting them fixed.

I just realized what it was that stood out to me. There's one in here that says a return from a switch statement wasn't calling the destructor of an object, and now it is. They fixed that. That seems like a pretty important one. Oh, it's the very first... No, where is it? Oh, never mind. No, I lost it.

It was something like that. Oh, here it is. Destructor not called when using goto statement. There we go. Oh, okay. That's interesting. Who's still using go to's i saw some interesting stuff um on some of the talks from last year's cvp con about how there's sometimes it's just the fastest best way to exit from a function when you need to call

code that i i don't do it personally. Okay. Anyhow. Okay. And the last article is from David Senkel, former guest of the show. And he wrote this pretty in-depth analysis of standard variant and why the Lenexa C++ group came to the version of Variant that they're now proposing. Now, Jeff, you're actually involved with the C++ Standards Committee, right? Yeah, correct. Did you take a look at this article? So I started looking at the Variant stuff,

but people who know way more about library feature design than I do have been staring at it a lot longer, so I've mostly been avoiding it. I honestly mostly work on the concurrency and parallelism group, so threads and atomics and things like that. But it's great work that's going on and pretty deep discussions there. Well, since you brought it up, I'm curious what work you have been doing. You said threads and atomics. We've had a lot of discussion lately about futures and Sean Parent's idea of what they should be and HPX and that kind of thing. Is that stuff you've been involved in? Yeah, and Sean has talked to me a few times about what he wants, right?

Including pointing out that code has to be able to scale to single core, which is an interesting concept, very catchy phrase. So I got involved fairly recently, maybe two years ago, so I haven't really pushed big features through. But most of what I've been doing is trying to concentrate on making sure that you can write portable code efficiently, which is fairly interesting because the C++ standard committee has also hardware vendors who kind of want the same thing, right? So it'd be nice if you could write C++ code at a high level that works very well on a GPU as well as a CPU. And there are kind of very low-level things like how do you actually implement an efficient mutex and how do you you know model

consume semantics and things like that as well as just you know usually you want to lay out your structures that follows cache layout and you want to make sure that your lock for algorithms actually are lock free and things like that so that's the type of kind of small nitty things that i've been working on either directly or talking to other people who are leading the charge there. So I have a few papers that are out, but nothing that I'm incredibly proud of or anything. So I'm curious, how much time does it take

to be a member of the committee? It really varies. I feel like my time, if I'm going to spend time on it I may as well do it for real I try to actually spend a lot of time on it when I do want to get something done and it varies

so usually it's two meetings a year although we've been upping the frequency to three I think from now onwards and those are about a week and they're pretty serious We've been upping the frequency to three, I think, from now onwards. And those are about a week, and they're pretty serious. We usually start around nine and end at six. Then there are evening sessions, and usually we code until midnight or something like that,

and then start over again for the whole week to six days. It's a lot of fun. Yeah, it's a lot of kind of, you know, adrenaline rush type of thing, as much as you get with writing C++ code and stuff like that. But, you know, it takes a while. And then outside of the meetings, we usually communicate by email. So, you know, I've been talking to, for example, Paul McKinney of IBM to try to figure out what to do with thread local storage, which is kind of a big issue. And it's, you know, it's peppered throughout the C and C++ languages. And it's kind of a tough nut to crack because, for example, if you use Erno, you're using it. If you use math functions, you're using it, but you don't really want to be doing that.

It's just kind of incidental. So, you know, it takes a while to fix these issues. Just out of curiosity, what type of like coding projects are you working on in the late hours there? Are you working on sample libraries to test out a possible feature or working on a compiler? Yeah, so me and one of my friends who also attends the committee decided that every night we would write one small fix to the language. And that involves trying to test it out before we do anything. So writing a good paper where we actually know what we're doing takes a few hours. So that's the type of thing that we end up doing,

writing some code on the side. And we've been doing that on GitHub, which works great. We just write the papers on GitHub, and it's pretty amazing. Very cool. Wow. Well, let's switch gears and start talking about WebAssembly. I guess it was

two or three weeks ago when the announcements were made, and it was pretty interesting to see, because it wasn't just the C++ community that was taking notice. Obviously, this is a pretty big deal for web developers, JavaScript developers. Do you want to just give us a high overview of what WebAssembly is?

Sure, yeah. So basically the idea was that a bunch of different people who work on browser engines and browser virtual machines got together and said, well, there's all these really interesting things that we can do with web browsers, and JavaScript keeps getting more and more powerful. But at a certain point, when you try to write really big apps or really big games or something like that, it kind of breaks down. There's only so many things you can do to deliver performance in an efficient way, because you have to remember that people writing virtual machines are also writing code, so it takes a while to make things efficient,

and it's not always the best for developers, right? Basically, we're trying to make the compiler really fast. And the more it can do, the bigger it is, the slower it is, right? So we kind of try to play around different issues and try to figure out how to make a platform that could do more than say target support JavaScript or support C++ and try to really go further so it was you know pretty pretty hand-wavy originally but but what we came to is that we we really wanted something that was you know portable obviously so works on on multiple browsers as well multiple operating systems and is a you know x86 arm MIPS

and stuff like that really small so size and load time efficient and ideally something that's pretty close to a binary format while still being you know the web really likes having textual representations for things and so having a really good textual representation is something that we care about a lot and one of the things is we also wanted to work really well on mobile. Nowadays, if you compile C++ code using Emscripten or Pinnacle to the browser, it doesn't work that well on mobile or kind of smaller footprint devices. So that's really kind of how we came together around that.

And the idea isn't to replace JavaScript. It's really to supplement it. And what's great is we have Brendan Knight, the creator of JavaScript, who's fully behind us and really supportive. And the idea is to really create something incremental. So we'll start off with very small things that are effectively pretty close to what Emscripten can do today. So basically compile C++ code to the browser with a limited subset of features, and then evolve that to compile basically any application,

all the C++ features you'd expect, as well as what other languages would expect, including functional languages or more dynamic languages. So that's the high-level ideas of what we've been doing. And so we wrote a little GitHub spec to kind of agree on what we're doing, then we just opened it up. And what's confusing a lot of people

nowadays in the last three weeks is we don't have any code. So we just kind of started and said, hey, we want to do this thing. Here's what we're doing. And we started writing the code basically in the last few weeks. So right now, there's no compiler to download. You can't run it. It's just an idea.

And the whole point is, well, browser vendors can ship the VM, but we can't do that work alone. If we want to create a good platform, we have to do it by taking into account what different developers need. And also, we can't write all the toolchains ourselves. We're compiler geeks. We like writing compilers. But there's only so many hours in a day and so many of us to do that.

So we really need the help of other people to be able to do that efficiently. That's kind of the high-level idea. It's a very open platform. There's a W3C working group that anyone can join. And we have, you know, an IRC channel and a GitHub repo, and people send us pull requests. And that's about it. You know, we've been just coding away since then. Very cool. So I believe I read that, you know, obviously you're from Google and you have other engineers from Microsoft and Mozilla working on this as well, which I think is a pretty impressive partnership to have engineers from these different browsers working together. Does that sort of thing happen often or is this fairly unique? So in the browser world, it's actually not that unique. When we create web standards, the goal is usually you want them to work in every browser. Otherwise, it gets kind of annoying, right? Fragmentation-wise. And so there are standards on the web that exist in isolation that only one browser implements.

Those are often pretty unfortunate, but they serve as useful kind of showcases of what you can do. So often they're very well intended, and at some point things break down. For example, quite a while ago, there was an attempt of designing kind of sandboxed file systems that would work on the web, and there were kind of a bunch of different attempts, none of them really came through, and then things kind of cleaned up later. So the way the web evolves is kind of in the growths and stuff like that. And when people come together, we usually end up working, you know, three, four companies together. So it's actually not that rare. And for example, the Pinnacle team, which I'm on, a portable native client,

and the Emscripten team of Mozilla have been meeting pretty regularly for well, well over a year now, just to discuss how you do compile to the web, how you supplement JavaScript, how we can improve JavaScript to meet those use cases and to meet what developers need. And pretty often the people from other teams,

like the V8 team or the Blink team, join us to just, you know, have a beer and discuss that type of stuff. So it's honestly not that rare on the browser world, at least. There does seem to be a major browser vendor missing from this list, though. I mean, Apple does still make Safari, right, as far as we all know? Yeah, well, we do have some participation from Philip Pizzolo, but Apple likes to do things in its own way. They're definitely watching, and I don't think Apple's going to lag at all.

They just have a different approach on how they create new technologies and how they adopt them. So, you know, we kind of leave it up to them to get to that in their own time. I think that's pretty fine. And, you know, we actually want them to work with us at some point in time. It's not like we exclude them or anything. Right. And also, correct me if I'm wrong, but Chrome and Apple Safari are both based on WebKit.

So if your team is working on WebAssembly in WebKit, then Apple might be able to benefit from that. Is that correct? Yes and no. WebKit kind of forked maybe two years ago or something like that for a bunch of different reasons. And I think nowadays people who work on WebKit, so what Apple still uses and Blink, which is the Chrome fork of WebKit, are actually pretty happy about the situation. It removes a lot of baggage that both sides had to maintain

for the other side's sake and stuff like that. So I'm not familiar enough with how the APIs are set up to know whether, you know, Apple can benefit from the work that would go on in Blink. But at the same time, there's actually not that much code for WebAssembly that would go on in the rendering engine. It's mostly in the virtual machine that code would go on. And on that side, Apple has their own JSC compiler, which has kind of interesting features, including an LLVM backend for very high-level optimization code. And Chrome itself uses V8. So it's completely different virtual machines.

And so most of the code would go there. And there is room for collaboration there again, but I don't think that there will be that much just because of the way the VMs are built. And that's a good thing, right? It means that we're not developing a one implementation standard. It actually can work in multiple platforms, right? So that's actually pretty good. Okay. Do you have a question, Jason? I was wondering if you could talk about the relationship between asm.js, which I think some of us are familiar with, and WebAssembly.

Is it fair to say WebAssembly is related but a binary version of asm.js? Yeah, it's actually a pretty good qualification of that. So the people working with us from Mozilla are from the Mozilla research team. We have Luke Wagner and Alon Zukai and Dan Goeman. And both Luke and Alon were two of the original authors of Asm.js itself. So Alon created Emscripten, which is a C++ JavaScript compiler, and Luke maintains most of the big parts of the virtual machine, SpiderMonkey, that runs JavaScript code inside of Firefox. And so, a lot of the ideas inside of Asm.js live on inside of WebAssembly. And a lot of the approach also does in that as MGS is an evolutionary standard, where they standardize something that can work today inside of JavaScript, it's a really neat trick, where you basically, you know, JavaScript being a dynamic language, you trick the

virtual machine into creating a static language by using type coercion. It's a beautiful trick, a neat hack, and it happens to work very well. It's mostly just JavaScript, except you have to be a bit clever. The compiler has to recognize those type coercions and say, oh, well, actually, there is no dynamic typing. This thing can never become a string because I know it's always an integer, for example.

And the idea is to kind of have a shortcut around JavaScript, never go through type coercion or anything like that, and have a binary format instead that the virtual machine understands directly. So that means we can shed a lot of the legacy that asm.js has to deal with for JavaScript integration and just kind of go directly to the virtual machine. It means it'll parse much faster. It'll decode in a much smaller memory footprint.

We can compress it way better. And it also means that eventually we can add features faster than JavaScript adds them or features that JavaScript wouldn't want to support anyways, right? So, for example, SIMD is a feature that we want to support so that you can do kind of vector computation and use the hardware that your machine contains. And that's actually being added to JavaScript. Same thing with threads, but things like stack control from the user space, right? So being able to do stack unwinding or cooperative thread switching or something like that, right? Something like coroutines at a very, very low level

is probably not something you want to add to JavaScript, whereas it's tremendously useful to support garbage collected languages or to support something like Go, right? So like very lightweight Go routines is something that would be possible. And I'm not sure you want to change JavaScript to support a very efficient implementation of Go.

So there's a lot of similarities with HasmJS and some amount of divergence, right? The goal is that the initial version of WebAssembly would just work in any browser, but eventually we can work with the rest of the web platform to add new features, and we can also add new features for the sake of WebAssembly itself. So that's kind of an interesting aspect of WebAssembly.

So Emscripten has come up several times now, and correct me if I'm wrong, but it compiles C++ to Asm.js, basically. Is that correct? Correct. So Emscripten was actually created before Asm.js, and it used to just compile to JavaScript. Oh, I didn't realize that.

And later on they figured out, oh, hey, well, we can be even more clever and tell the JavaScript engine, here are the static types. Stop adding polymorphic inline caches and stuff like that. So Emscripten is pretty interesting it's it was originally kind of an interesting fork of lvm that did a lot of of bitcode massaging and uh it eventually it turned into kind of you know a prop most mostly of a proper lvm backend that generates uh javascript code right so it's it's it's, and it has a nice tool chain around it that makes it easier to use different libraries also, right?

Because obviously targeting a browser means you don't have access to the raw file system or to the raw GPU or something like that. So there are a bunch of libraries like SDL that developers use to do video and things like that that that Enscriptum offers a port of that just kind of works out of the box. So at some point, we'll expect to see WebAssembly be the or an output format from Enscriptum? Well, yes and no.

So LLVM itself has a certain way of being developed, right? You don't want to just add any random code that anyone wants to add to LLVM itself has a certain way of being developed. You don't want to just add any random code that anyone wants to add to LLVM. And Pinnacle as well as Emscripten were started as somewhat experimental projects and didn't quite always follow the best recommended practice of LLVM itself, the compiler project. And so even today, both of them are semi-forks of LLVM. They share most of the code base, and they're actually pretty close to tip of tree, but they have diverged from LLVM.

And the goal with WebAssembly is to just do it right instead. Oh, okay. So right now, the work that myself and Dan Gohmert are doing just goes straight into upstream LLVM. We've talked to a lot of people in the community to make sure that we don't add maintenance burden to LVM. The goal is to actually be a net positive for the LVM community because the main difficulty is we're not targeting a specific CPU and that's not necessarily something that compilers are used to doing, right? We're targeting a general purpose CPU that eventually will execute on x86

or ARM or MIPS or Power or something like that. And that's a bit tricky to do well in a compiler, especially in LLVM. There are a few other targets that do this, but they're mostly fairly recent. There's a PTX backend for NVIDIA GPUs. There's BPF filters for Linux. There's a PTX backend for NVIDIA GPUs, there's BPF filters for Linux, there's a few other things like that. There's been discussion of things like Spear V and a few other things that have this kind of virtual ISA, right? So it's kind of a fake CPU that we're making up. And basically teaching LLVM about these types of targets is one of the big things that we signed

up to do once we asked the community, can we do WebAssembly inside of LLVM about these types of targets is one of the big things that we signed up to do once we asked the community, can we do WebAssembly inside of LLVM? Here's the advantages we'll try to bring you. We won't just be a maintenance burden for you guys and always break your code or something like that. Because the more code you have, the more bugs you have, the more you change one part of the code, it's so much harder to maintain.

So eventually, yes, then Script and Toolchain will be able to use WebAssembly, but it'll be very different because it imported a new version of LVM that can target WebAssembly. Emscripten will likely still be kind of its own fork and so will Pinnacle, I think. The goal is really to create something way better than either of them ever were.

But we don't want to spur any users that already exist of Emscripten or Pinnacle. We want them to be able to continue to use whatever they had that was working for them. So it's kind of a complicated landscape here. I want to end up this discussion for just a minute to bring you a word from our sponsor, JetBrains.

For over a decade, ReSharper has been helping.NET developers be more productive and write better code in Microsoft's Visual Studio. Starting this year, it expands the list of languages it supports by adding a dedicated edition for C and C++ developers. To put it simply, ReSharper C++ makes Visual Studio a much better IDE for C++ developers. It provides on-the-fly code analysis, quick fixes, powerful search and navigation, smart code completion, automated refactorings, a wide variety of code generation options, and a host of other features to help increase your everyday productivity. The list of things that ReSharper C++ can generate for you include definitions, missing and overriding members, equality and relational operators, hash and swap functions, add dozens of customizable templates, and you'll deal with boilerplate code faster than ever.

Code refactoring for C++ helps change your code safely, while context actions let you switch between alternative syntax constructs and serve as shortcuts to code generation actions. With ReSharper C++, you can instantly jump to any file, type, or type member in a solution. You can search for usages of any code and get a clear view of all found usages with grouping and preview options. Visit jetbrains.com slash cppcast dash ReSharper dash cppcast dash resharper dash cpp to learn more and download your free 30-day evaluation. And if you're a student or an open source project, get your license for free, courtesy of JetBrains. I was just going to say, you've mentioned Pinnacle a couple times. We haven't actually gone over that one yet. Can you give an overview of Pinnacle? Yeah, sure. Pinnacle is an evolution of a project that was called

NACL that was developed around 2008 or something like that. NACL is basically a security product. The main target is to offer a secure way of running very low

level code that you completely don't trust. And the way it actually does this is you download an x86 binary or an ARM binary, and you just execute it. And the properties of the sandbox make it so that that's very secure. And so it's not using virtualization. It's not just using an operating system-level sandbox, something like Seccom BPF or anything like that. It's using something called software fault isolation, which basically looks at the executable and proves properties of the execut is very, very small. And if you prove that property, you know for a fact that the executable can't do anything malicious. And so that's used mostly just for Chrome extensions, and it's also usable outside of browsers. And what's wonderful, it's covered

by the Chrome Vulnerability Reward Program. And as far as I know, nobody's ever collected on that, which is pretty amazing. Usually Chrome pays out a lot for exploits because we actually want to fix them. We actually want to learn from people who are good at finding exploits. Unfortunately, NaCl has never been the target of an exploit. It's been used as stepping stones, right? You can use it to compute really fast or talk to the GPU fast or something like that. The sandbox itself has never been broken as far as we know. That's kind of interesting.

The problem with NaCl is it's not portable. You get x86 on the wire. That's not great because it doesn't work on a different machine. Pinnacle, the original idea was to do that but portably. What it does is it has a kind of stable version of the

LVM bytecode. And what we call stable is a bit complicated. The idea, basically, is that we can upgrade the version of LVM and old code keeps running. And because it's an intermediate representation, we can generate code that targets the NaCl sandbox and execute it pretty efficiently. So the overheads that you see from running inside a NaCl sandbox are maybe 10, 15, 20 percent depending on your code and which ISA you're running on. So that's what Pinnacle is. In a way, it's very similar to Emscripten, and it's very different. It has very divergent, low-level details in its approach. But in general, it's mainly the same goal, run different languages that are cross-compiled into this bytecode format and execute them inside the browser.

Maybe I'm just having a hard time wrapping my mind around this. So we've discussed Emscripten, which compiles to Asm.js essentially through LLVM. And Pinnacle that compiles using LLVM to just using LLVM's backend bitcode, correct? Correct. And regular old compilers that compile, well, I guess LLVM in any case, it compiles to its bitcode and then that gets linked to CPU-specific instructions. Is that correct? for you to give us an overview of how compiling to WebAssembly is different than compiling to, say, JVM or some other machine architecture. Right. So initially, what we'll try to do is only support

C and C++ because we know how to do it efficiently. And it's actually not too difficult to build with the code we already had existing today inside browsers. But the idea is you have a portable interchange format, just like the JVM has or the.NET VM or anything like that. But where it changes a bit is, well, first in the low-level capabilities it provides, right? So you can see it as basically the ABI that we provide to applications. And then the way it's kind of bound inside the browser or, you know, outside of the browser execution engines is left unspecified for now. The idea would be that eventually when we have things like dynamic linking

or something like that, the same WebAssembly executable could just execute the same way inside Chrome, Firefox, IE, as well as outside the browser. So being able to execute, say, a Node.js module or something like that with the same APIs. So you start accessing file module or something like that with the same APIs, right? So you start accessing file systems or something like that in the same way. So in that sense, it's very similar to running the JVM, right? You could, if you had it installed, run the JVM inside a browser as well as a server product, right,

in the same JAR file or whatever, often can just run in the same place. Okay. Where the differences come in is in the set of features that we aim at supporting, right? So we really want it to be as efficient as possible. If anything, we want it to be as fast as if you'd compile directly to your machine, right? So if you just use regular LVM, target x86,

we want it to execute as fast as possible, as fast as you could get there. And that includes being able to do zero cost exception handling in C++, being able to use signals, and being able also to use threads. That's something that today you can't really do in JavaScript. There's no way to efficiently use any type of threading besides doing kind of IPC communication or post message. So that's one aspect that we have. But we also want to support non-C++ uses, like being able to do garbage collection or

being able to do kind of fast stack switching or other things like that. So the basic APIs that we aim at offering to the platform enable a lot more. And the goal would be to be able to run languages like Rust or Go or C Sharp, or if anyone wants to implement the Java also. So it's fairly similar, yet somewhat different. We're not ignoring the 40, 50 years of computer science that have come before us. We actually have a lot of people who have very varied experience in these fields. The goal is to actually put it together in a cohesive way that makes a lot of sense. And one of the big difficulties there is offering APIs that work portably, right?

So we've decided that for the very first version, APIs aren't really well-defined. We'll do the basics to get the languages working, and we'll figure out the libraries afterwards. So that's kind of an evolutionary approach that we've taken to making that happen. Okay. So, you know, three weeks ago, you made the announcement with WebAssembly,

and your team, along with those from Microsoft and Mozilla, had the paper, and it sounds like now you guys are actually starting to write code. What do you think are the next steps or the timeline that we're going to see for WebAssembly? When are developers going to be able to start using this? Yeah, so we kind of purposely don't have a timeline yet. There are a lot of still very open questions. If you go to the GitHub issue tracker, there are a bunch of bugs that we have open where we're basically just missing data to really figure

out, well, there are five different approaches, which one should we actually take, right? And some of it is just, well, just read a bunch of academic papers, try to implement a few of them, figure out what works best, right? Or invent something new. And some of it is just, well, we need to implement the virtual machine, or to add features to the virtual machine and implement a compiler backend that allows us to generate C++ code

to really convince ourselves that that's feasible, right? There's no point in creating a binary standard that can't execute and that doesn't have a way to generate it. So I'm an engineer. I'm awfully bad at estimating time. I have no clue how long that will take. And the idea then is we actually want to have a binary format that's not really final.

We want to be able to execute it within browsers using something that browsers call a polyfill, which is kind of maybe some amount of JavaScript that translates the binary to JavaScript, right? So it's kind of a shortcut that basically is similar to Asm.js. And if you go on the GitHub repos we have right now, we have kind of an experimental version of that

that kind of works. But the idea is we can create all this technology and then have different people try to use it to see if it actually works well, if it meets their use cases. And also to kind of plan ahead to say, well, we support C and C++, do we believe that we can support garbage collection

or something like that in the future? It won't be in the first version. We want to make sure we don't paint ourselves in the corner. And the last step there is we actually want to standardize it. And standard bodies tend to take a while. So that's kind of the last step that we want to take. So I think that maybe within a year, it will be possible to execute stuff really natively without a

polyfill. Uh, but I'm fairly optimistic there. Uh, it may take a short while longer. I, you know, I hope it doesn't take five years, but, uh, yeah, I think a year is probably doable. Is the hope that, you know, because engineers from Google, Microsoft and Mozilla are all kind of working on this together, that we might see new versions of Chrome, Firefox, and Edge come out around the same time that have some WebAssembly support?

Well, so I don't know if we're going to synchronize our watches, right? I mean, once it's standardized, we will synchronize our watches and support it in the stable version of browsers. But, I mean, we all kind of release on a fairly frequent schedule. Chrome releases about every six weeks. Firefox does the same, although I heard that they were looking at changing that recently. And so does Safari and Internet or Edge now. So we can trickle out features

in the development versions of the browsers, right? So if you use the beta versions, you can probably use it pretty early. And there it'll be just, you know, whatever we've implemented is there in the beta versions. You just flip a flag and there you have it. But the stable versions, I assume will only ship once it's standardized, right?

Because otherwise if we change the standard, then, you know, older browsers don't work correctly anymore. So that gets kind of annoying. Right, right. With this all being open source, are you looking for contributors to help out with WebAssembly? Yeah, definitely. So, for example, the work we're doing on LLVM is still fairly early, but a lot of what we're doing, as I was saying, pertains to virtual ISAs, right?

So not really targeting the CPU, but targeting a general platform. And we've actually talked to people who do pretty much the same thing with an LLVM. And they've told us like, yeah, this part of the code was never written to handle our use case. And it's kind of a pain to develop for. Or, you know know we're all doing this thing maybe we should all share one code base or something like that so it's the type of thing that we'll do specifically within lvm but then um right now we don't have for example experts at gcc it'd be great if eventually there were a gcc backend for webassembly as well as you know

any other compiler right and then within browsers, we do have contributors who send code, for example, to Chrome to implement things in V8 and so does Mozilla. And I expect that at some point in time, people will start creating benchmarks or something like that, point out that things are slow and contribute code there. That's the type of contributions we're looking for code-wise. Now, making sure that use cases work, we've had a ton of great feedback since we started talking about this. There's a bunch of people who joined the community group,

sent us issues on GitHub, pull requests, things like that. And just on IRC, a lot of people asked great questions of, like, you know, have you thought about X? And we're like, Oh, well, we never thought about that. Like, that makes a lot of sense, right? And both just in the public, as well as users that we have internally at our own companies have told us, like, we love your project, but it's missing this one critical feature, right? And that's, that's what's great about going open very early. People just tell us really early, well, have you designed this? And it means that we're,

we're avoiding making mistakes. So that's, that's, you know, even without sending us code, we've had great feedback also. Okay. Bring it back to Inscriptum for a minute.

When I think of Inscriptum, I think a lot about WebGL or I've heard of various hobby projects where developers create like an OS emulator and run it in the browser. Will WebAssembly be primarily used for that type of application or do you think it will be used more broadly? So we actually kind of scoped out a bunch of use cases if you go to the original design and there are kind of two breakups in the use cases we have we have some inside the browsers and some outside the browser right so being able to use WebAssembly as a portable and secure platform is something we really care about and the

idea is you know within a server you run untrusted code securely and really fast or have a hybrid application on mobile or on a little Internet of Things type device that, you know, you don't have the source code for, but you want to be able to execute it in a secure sandbox. So that's one type of use case that we have. But inside the browser, we have a really long list. And basically, you know, there are things like gaming that care about being really fast, having access to the whole hardware, as well as image and video editing, right? That's something that you'd want to just work well in the browser. And there are some examples of that today in JavaScript, but you could do a whole lot better if you had access to more capabilities. And then there's, you know, a bunch of existing code, right? You were alluding to just having an emulator or something like that.

It'd be a shame if all the code that's been written over the last tens of years doesn't just work inside of that platform. And then there's kind of new types of applications like virtual reality, where if you miss a frame, it's pretty uncanny, right? And you get kind of sick. So that's the type of feature

that very low latency applications that we want to be able to meet with our platform. It's fairly ambitious, right? But scientific computing may not be the thing you think of in your browser, but once we've met these other use cases, there's no reason you couldn't just compute, I don't know, protein folding or something like that

inside the browser if you want to. And just use POSIX APIs in general or do fast encryption, VPNs, web servers, whatever. Yeah, so it's the type of thing we're aiming for. It's really exciting. It is. Well, I think we've probably taken enough of your time, Jeff. Is there anything else you want to talk about before we let you go?

Yeah, no, I mean, thanks for the time to talk about this. I'm really excited about the project and love your show. So it's a great place to talk to C++ developers here. So hope to hear more from you guys. Yeah, thank you. And where is the GitHub page for WebAssembly right now? So if you go to github.com slash WebAssembly should be there. And there's a design repo where you can look at the high level design. There's a few other repos with ideas. But again, this is very open. If you look on GitHub in general, other people have started projects that I, you know, sometimes I Google for it and I just find new things. Or recently

I was looking on NPM, the Node Package Manager, and there's already two things that do something related to WebAssembly. I don't have a clue what they are, but that's there, right? So that's pretty amazing. Like, I have no clue what's going on, and I'm one of the contributors to the project.

So it's pretty interesting. That's awesome. I want to make a comment here for any of our listeners to check out the talk you gave in Oslo two weeks ago at NBC. Yeah, that was actually the day after we announced it. So it's fairly light on WebAssembly content because I was still answering questions and trying to figure out what I can talk about, like where we are in the design process and everything. But yeah, I'll be giving a similar talk at CppCon in September, which will be more solidly built.

Yeah, and the talk is C++ on the Web, Ponies for Developers Without Poning Users, which is one of my favorite titles for a talk I've ever seen. Yeah, thank you. Thank you. The talk was mostly on Pinnacle, is that right? Correct, yeah. Sorry, go ahead. I was just going to say it's a little bit of a mind-blowing

demo for what kinds of things are possible with this technology, these technologies. Yeah, thank you. Okay, and where can people find you online, Jeff, if they want to read more about your stuff? Oh, well, I'm obviously on GitHub, though I don't

really have that many projects that are public, but I'm also on Twitter, just JeffBestSan if you want to look me up. Okay, thank you so much for your time. Yeah, great, thank you. Thank you. Thanks so much for your time. Yeah, great. Thank you. Thank you. Thanks so much for listening as we chat about C++. I'd love to hear what you think of the podcast. Please let me know if we're discussing the stuff you're interested in, or if you have

a suggestion for a topic, I'd love to hear that also. You can email all your thoughts to feedback at cppcast.com. I'd also appreciate if you can follow CppCast on Twitter and like CppCast on Facebook. And of course, you can find all that info and the show notes on the podcast website at cppcast.com. Theme music for this episode is provided by podcastthemes.com.