History of WebAssembly (Chrome University 2019)
Great. So let's talk a bit about the history of webassembly. So. I think you've heard about it briefly in a previous talk but just, to, set. Up what we're talking about so the. Web has two. General, purpose, languages. Javascript. And web assemblies so web assembly was added much much later after JavaScript. And. It's an interesting story I think and we. Edited because it does. Different, things in JavaScript in particular, the stuff, noted, on the slide here it's binary formats, which much smaller, more, compact. It's. A compilation target, so you typically don't write it by hand you compile, to it and, it's. Designed, to be fast from, the basic, from. Basic principles, essentially. So. The stuff is kind of how we, came to, standardize, something, like that and specifically, web some it. May. Be the place to start is way. Back in 2008. So. Back then suddenly, JavaScript, started to the common fast before. It was just an interpreted, language so, it was quite, slow but all you did was write little strips on pages it was flying, but. In 2008, chrome locks, so obviously that happened with its v8, and also Firefox and Safari launched. Two bits, as well so, by the end of that year there was a big speed-up. And this. Kind of the arrow tries, to show it. For. Many many years after this constant. Speed ups were happening, so these, were very, exciting. Years in. JavaScript. Space. But. Kind of getting back to the. 2008-2009. Times I mean there was no question of how fast will, it get, it, was starting to speed up but. If we want to run something like a game or a, photo. Editor, or something that requires a lot of heavy computation, will it be festa I think it was very reasonable to be skeptical at that time and. Maybe. Chavez good won't be fast enough in us maybe we need something. Else. So. One possibility, of something else is. Native. Client which we'll talk about about now. So. Native, Client basically, defines a safe subset. Of a, particular, CPUs, code. So. You can actually run normal, code for the CPU normally a machine. Code but it's in a safe, subset you know is not going to cause. Any problems and, this. Was started in 2008, at Google by Brad Chen Benny and David Sarah and it. Was quickly announced publicly and, open source which is great because we want something to be part of the web it makes sense to work on it in the open. We, made a lot of good progress in 2009. There was a research paper and it. Sort of graduated, from research into a plan towards, becoming a product. Okay. So this is some data on speed, the key. Thing is the, column, on the right. Which. Shows sort of the extra, overhead of running a Native Client as opposed to running the same code natively, maybe, it's a little hard to see the numbers but anyway it's. Essentially. In all the benchmarks it's single digit overhead, so you're running maybe 5% slower, than the full possible. Maximum speed so this is very very low overhead very very impressive, that, you can do this in a safe way. And. Safety. Is really a super high priority, here I mean ice you just had a talk, about safety and security, on the web so the timing is good, you're. Running content from that. People are sending over the network you don't know what it is you have to be very careful Knakal. Had two layers of, sandboxing. So one is sort of what you see an application code. That's. Sort of by running in a subset, that you can prove is safe that. Sort of one layer of sandboxing. The. Other layer is you actually, all. That code can do is communicate with the neckl runtime, and all of that is in a process, again. Kind, of mentioned, in the previous, talk and that. Process is sandbox as well so you have a second layer of sandbox. One. Issue that you might have been thinking about is portability.
So I said it's specific, to a CPU architecture. Obviously, that's not great because we. Don't want a ship Nick a just native x86. Or native arm we need to ship something portable you need to able to view a website no matter what CPU you have, so. Of course this was not a surprise, and in 2010, portable, Native Client was, launched so pinnacle, and. It, basically replaces. That. Sort of native machine code what's, with some. Something else in this case LV Mir Alabama, is a compiler, IR. Is the internal representation. In, the compiler. So. You can kind of imagine that you compile, the code halfway. Then. You ship that over the network and then you finish the compilation on, the, user's machine where you know the, architecture, of their CPU. That's. Kind of the model and on the client you finish the compilation to knackles, so same as before the same sandbox same same safety. There. Were some initial controversy. With pinnacle. Over. The use of LV Mir, because. Lb Mir was actually not portable, and undefined behavior but. Over time these issues were fixed. Okay. Something we're, spending time on is the fact that neckla read in a separate process has already mentioned this is great for security. But. It had a large impact I think on sort of the. The. Overall, what. Happened with technology, because it prevented, calling, web api's. You're. In a separate process than, JavaScript on the Dom you can't actually just call in through the normal things. That JavaScript would. What. You can call is a plug-in, API so. This was initially the NPAPI, the Netscape, plugin API the thing that was used by flash and Java back in the day later. A new plugin api was made a pepper, the pepper. Plug-in API ppapi. So. Pepper salt. Etc. And. This. Worked, however, a criticism, was that it overlaps with existing web. Api so the web already had api's for, rendering. And audio and network and this was, basically a bunch of new api's that do similar things. Another. Of criticism, was that the éclairs weren't fully specified, so there was an implementation, of pepper in chrome and ducks. But other browsers were a bit what whether the Ducks were SPECT. Enough weather or corner cases whether if they try to implement it they'll run into issues it's, a little hard to say how valid, those concerns are but these are things that people were worried about at the time. Okay. So more, sluggard. Context. Here so. Again this is around like 2008. 2010. Etc, this is about the time when the, web is trying to move away from plugins. So people, are being told web devs are told don't, use flash don't use Java just use HTML, Javascript. Etc, and, that's. Good in general, for. Native Client this was sort of a problem in that it began as a plugin again. It used NPAPI, or, PP, api. It, was later, integrated. Into the browser, at which point it's not a plug-in it's just part of the chrome platform. But. I think that by, running in a separate process by. Having a new set of API eyes that are very different than the existing web api they still felt more like flash in Java to. Other people. And. All.
This Had an impact on the adoption, of the technology so early neckl ran in other browsers using NPAPI, so, the, same way that flash ran in other browsers, it. Just used the plug-in API but in 2011 Mozilla, and Opera announced. That they opposed Knakal. And pepper, and since. That point NACO only ran in chrome essentially. So. Adoption was an issue. Still. The technology, made huge huge strides over the, years for example in a few, milestones. Are, mentioned here, in the slide so in 2010, unity, was ported to neckl, unity. Is a massively, important, game engine extremely popular. 2011. Mano was ported which is a sort. Of CLR. Implementation. It's also very important. For games among other, things it. 2011 there was a lot of noise around Bastion, and a bunch of other popular games at the time being ported to neckl, a. Big. Milestone is 2013. When. Chrome. Decided. That pinnacle is safe enough and stable enough to be shipped on the web that is to be enabled for web content to, use until then it was just sort of on the Chrome web store which is very limited and the. Idea was local ship its web. Devs will use it and we'll show how useful the technology, is and other browsers will welcome it that was the help, yes. So. That launched 2013, and, of course over the years the technologies just kept getting getting, better and better example, 2016. Sub-zero, was launched as the slide says which, it's. Basically a super, fast compiler, for pinnacle, this. Kind of addresses the issue that as I said you kind, of finished, compiling the code on the user's machine if, it's a very large project that, can be slow so, sub-zero. Was, very. Fast faster, than building, with - from zero. Ok. So we've talked a bunch about Knakal. You. Know, meanwhile. Other events were happening in a parallel, world. So. There's another path that involves, things like s and J s and M scripting. And this. Is kind of a path, that I was, involved. In so. Maybe a good place to start is 2010. Where. I gave up on a startup that you never heard of and I. Moved to work on fabrics for Android in the US and, that. Was fun at Mozilla. And. A. My spare time I kept incurring with the game engine from the start up so the started was kind of like this game engine that could run. On the web and it would download games and stuff and so. I tinkered with the game engine for fun it was open source and I, wanted to run on the web cuz I liked the way but the question was is how so, remember. This is 2010, so kind. Of. Natural. Was quite new pinnacle, was just announced, it. Wasn't through what the induction would be of these technologies. So wasn't. There what would. Be a good way of running a, large C++, code base on the web. So. I was thinking well JavaScript is fast now let's. Maybe, compile, to JavaScript. So. Jokes with has no explicit, types, you just write far it's. And. That's it. But. I was thinking when you compile sequence bus to JavaScript, it would maybe preserve, the types. That were there. Original. And sort, of maybe a way to look at it is in this. Super, simple code here so if in, in, C++, we write x equals 10x plus plus obviously it's an integer and it, stays an integer and JavaScript, just replace, the end with the VAR just kind of drop the types and, it's. A valid JavaScript and you can imagine that the compiler would actually see well this, begins, as 10 begins as an integer all the operations, on it preserve the fact that it's an integer and then it could drop too much. And. It's some experiments, in this area in particular using, pi pi which is pretty, good at compiling, large. Amounts of code with no types and inferring those types but. I, don't. Have time to get into the details but, anyway convinced, at least myself that this could work so I bet, on JavaScript, and started, writing compiler. From C++ to, JavaScript, and. I called it and I'm, scripting, as we said because.
It Turned out p.m. IR into JavaScript, and. It's kind of a Simpsons, reference the. Episode with crummy lint if anyone knows now, you can look, at him. And. This was kind of a fun weekend. Evening. Side. Project, for me just tinkering any code to run it was just fun. Around. A year later it became more, than fun became kind of part of my job. So. By. That time obstructed, could compile quite a lot of things like Python, and doom, I kind, of showed that this could work so we're compiling to JavaScript, which you never intended, as a compiler, target. But. It turns out you can't compile stuff like C C++ to. It of course there have been other compilers like, wit from Java but, I think this was the first for C++. Ok. So this year I gave a talk at Jess Khan you, about, it and I published a paper on the V, looper algorithm, that it uses so. Very, very briefly a compiler. Typically has very very, low level view of control. Flow but. JavaScript of course has ifs and loops so you need somehow to bridge that gap, anyway. So I made, up to something that helps them. And. Later, in the year, Mozilla basically, gave. Me the option to join the research team and to work on full-time basically, is my day job so, it's super happy to say yes, to that. And. Kind. Of why, did they do that I think. Because they felt that they understood, that native, code on the web matters, we want to run in games other, high-performance things. There. Were worries about NACA like we sort. Of the ones that I mentioned earlier, they. Felt that compiling to JavaScript is just the safe option, it felt web friendly uses Java C it uses web made API is normally. JavaScript. Already runs in all browsers it doesn't need a plug-in and, of. Course a belief was well JavaScript, business getting faster and faster so. Mmm. Scripting, shows this can work and we'll just make JavaScript fast, and everything would be great. Well. It turns out not everything will be great because. Normal. JavaScript speed is actually not quite enough to get to. Native, speed. The. Issue of course is that javascript, is just in time or JIT up. To optimizations, it's, fun it's kind of unpredictable, it's.
It's. Not a consistent. Thing between browser to browser even, different versions of browsers so. We wouldn't when t13, hey. Luc Wagner David Herman and I made. Up something called S&J, yes. Which. Is a subset, of JavaScript so. This is a little sample. Of massive, J yes if, you, know JavaScript then you know what this does, what. Might look under, these kind of or zeros. So. The or operator in JavaScript, converts. Both, inputs, to a 32-bit, integer, when. You do an order with a zero it changes no bits so, writing or zero is a very concise way to say turn this thing into a 32-bit, integer, and. Therefore, when you see a function like this. The. Inputs are turned into integers, the. Output of the ad is turned into an integer. So. The JavaScript VM if it thinks about it it can easily see that we're. Not writing the types but these, kind of annotate, the types for me and I can optimize these as integer. And. In fact we added use a some kind. Of a convention, that if the. Browser, is that. String it can use the S&S type system, which formally specify how this works and it, can do ahead of time, a ot compilation. If. It wants to so when it does that it literally sees the types of every variable and. It can generate very efficient code. Here's. Some data from the first launch. Of SJS in, firefox. So. The key, thing here is to. Look. At so, in kind of orange on the bottom in each of the three benchmarks, is native which is normalized one, lower. Values, are better and you. Can see that in the blue, bars, in. Firefox without asanchez it's kind of like 10 12 times slower five times slower with. Assam jeaious it gets to about two, times slower than native, so. It kind of reaches half, of native speeds that's a pretty big jump using this, äôt, approach, it. Did get a much faster later but to be fair it never quite got to the speed of network, but, it did kind of get to the right ballpark. It. Did have some serious issues though so one issue is startup, speed it's. Parsed. Because, it's JavaScript so it's it arrives it's text in the browser and the, browser needs, to parse it and figure out what to do with it, it's. Never going to be as fast as an actually efficient, binary format there's. No way to solve this not, with something that is in JavaScript, so the benefit is named Java is where that it runs everywhere but. The downside is it's in text. And. Also it's, a heck so.
It's, Maybe a fun hack but. It's a hack those, or zero things are weird. Heythere's. If you get the slides later there's a link there. To a blog post that's. Very. Smart. Hey, so. It's it's it's it's weird a lot of people didn't like it I can definitely understand why they didn't like it but. What I want to say more about on this slide is that it's it's sort of a psycho being kind, of weird it's it also had serious downsides, that it's a hack. So. We added things like matza imal and matza, F round to. The JavaScript language. That made it a better, compilation. Target, so those two things helped with sort of low level math, and the, standards bodies we're happy to work with us because, this actually helps normal JavaScript. To in some ways. But. You can imagine if we try to get closer and closer to native speed we. Will eventually. Need, more. Hackish. Things from the language, which, was never designed to do so you can imagine the standards bodies would understandably. Eventually, not be so happy with this. This. Was also a problem for us writing, messages type system, so. It. Got hard her to add more complicated, things because, in, essence. Yes it has to run as JavaScript. Because, the browser might not use that suggest type system. But. It also has to be easy when doing a ot compilation, to sort of see what it's supposed to be doing and to optimize it so it's there's kind of this tension there and. For. Example we added memory growth which means that you can sort of adjust the size of memory over time and it had this convoluted pattern, it, was so complicated and annoying that we ended up getting rid of it from Firefox, and we got rid of it from the spec so. The, hex had a cost. Despite. That it did new quite well for a few years so as, I think I said it was announced in 2013. Unreal. Engine was ported that, year a. Realist. Another very. Important. Game engine. Used. It for tonight's 2-day for for example a. Benchmark. Started to take a look at sha s around that that time so for example in octane, there was sort of a sub benchmark, that used it in. 2014. The Unity game engine that we already mentioned earlier, announced. Support, for S&J, s and M, script them and in. 2015, two more browsers joined, Firefox. And doing the äôt path a so edge and chrome. Okay. So we've talked for a while without. Native. Client and for a while about. SMGs. And and, Miss, Krypton and he. Was a kind of two separate, parallel. Paths we've talked about what, has, done but, of course they're not really that separate, in that, they. Competed, and cooperated, and interacted, in various ways so let's talk a bit more about that. Obviously. They competed, that I don't really have much to say to say about, that it's they, both kind of hope to be the future of native.
Code On the web, what. I think is we're interesting it may be less obvious and so I want to spend more time on is that there is increasing cooperation -. So. In 2013 we. Started. To have lunch dinner meet ups between Google, and Mozilla. Tools, this, was just a lot, of fun and also helped us work. Together. On things get to know each other. We. Started to share code between the two projects, Hey. M-miss, scripting started to adopt the pinnacle, legalization. Passes, so it's the code, in lbm that sort of handles some crucial things. We. Started to share a triple and Elvia sort of the definition of the target machine we compile - and. There was also peppered betrayus which. Basically. Let you compile. A Native. Client application using. And M, scripting, -, s and J s you could take the same codebase compile, it either to. Native clients, well, to pinnacle at the time or to. S&J. S. And. There was more and more cooperation, on the browser and, DM side -, so. In 2014, they. See. The. End, people that is the people working on the JavaScript engines, talk, to more about us and she is because they were each optimizing. It in their own way but they start to talk more about hey how should we optimize, this what's the future in this area in the, particular, one I mentioned Luke Wagner, from, Mozilla, and Bengt exit from Google that that, I know talked quite quite a lot about this and, sort. Of the idea of a. Bytecode. A more proper solution, keeps coming up so you're talking about SaaS and how to optimize it but. It's a natural thing to think about how to do better in this space. And. In. 2015. Mozilla. Google and others. Met during GDC the Game Developers. Conference, to, talk more about what we called at the time web Azzam. And the. Plans got increasingly, concrete. And, in, fact we announced, webassembly. In that year 2015. So. I think it might, have been around April that we came up with the name that it we found some emails that mentioned, it. Replacing. Some other names, that. Were thrown around and. Then we spent a few weeks working. Behind the scenes so this one we had agreement, between all the major browsers that were going to standardize a new thing called webassembly and, you sort of prepared, a website and a process etc and then we launched it that. Is we announced it publicly that, we're starting the, process of speken and designing, this thing so that was in June 12. Okay, so what. Changed, in 2015, a by. Which I mean, for. Many many years people have asks for native code on the web, why. Don't growl servers just ship the VM you ship a bytecode let us use whatever language we want why, are we forced to just use JavaScript. These are very common, complaints. From web developers, and developers in general and. I think it's a reasonable question why, did, browsers, finally, end up doing, this at all and why, in 2015, and not earlier, why not later. So. At least my theory, is we've. Kind of mentioned this. Browsers. Had to optimize SaaS, it runs as JavaScript, in your browser so, you're already running this and there's. So much competition on JavaScript, speed you have to run it fast so you're very motivated, to optimize. Essence yes and use the essence yes a OT path. Etc. But. Once you're. Optimizing essence, yes you realize how much of a heck it is you see all the downsides, and you. Naturally want to do something better something, cleaner a more proper solution. And. There, was an increase in collaboration, between browsers, as I mentioned, and you think just that we were all talking together. More working together on smaller, things helped, us finally, get to a point where we could work together on standardizing, and do big, thing. And. I think that kind of shows in webassembly that is the history that we have these two paths that eventually ended up working together. So. Just. Like natural web, assembly is not based on JavaScript, it's a new design its, proper, it's in binary this, is very much the right thing and this is something natural very much got. Right. Like. Essence yes it runs in the same process as JavaScript, used it normal JavaScript sorry, normal web api's, so, I think that's something that SAS, got right. This.
Kind Of also shows that our tool chains so we use, MS. Krypton which basically, had the right Java scripts, and Web API model it. Compiled to Assam J's before and now, we just made it compile to web assembly, and it's basically, calling the same API etc. So he could keep using it and. M. Scripting uses the new LVM webassembly, Beca and that was written in collaboration, between tools, people from Mozilla and Google's, kind of the people that used. To work on a suggest nice work on pinnacle kind, of are working together on this stuff. Okay. Thank, you have one or two more slides or just very briefly just to mention a few more. Milestones. Along the way here so as I mentioned we announced, web assembly in 2015, before. The end of the year we already could start to run sort of the work-in-progress, version, of it's in our tool chain and scripting, well in. 2016. We showed multiple browsers, running, a bunch of large demos like angry bots that sort of proved that we were all in sync, and working together, effectively. And. We reached a consensus, sunrise in 2017. And. All. Major browsers, ships, it is supported a stable version by November so you could say wasn't 1.0 kind of arrived. By, the end of that year we. Also published a paper unwise npnp LDI and. We. Announced, the, deprecation, of pinnacle in favor of web assembly and. You could also say SMGs, is deprecated. Effectively. Essentially, since we don't really need it in fact in. Script. And we plan to stop, and then again in just a big lesson. Okay. So getting back to this picture so these two pests, seem, to go on forever but not converge so. It turns out they do converge just past the hill where you can't see it in the picture and they, converge to webassembly, obviously. And. That's, it thank, you.
2020-02-15 03:43
