Pushing the limits of the Web with WebAssembly
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 490 | |
| Autor | ||
| Lizenz | CC-Namensnennung 2.0 Belgien: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/46905 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
|
FOSDEM 2020150 / 490
4
7
9
10
14
15
16
25
26
29
31
33
34
35
37
40
41
42
43
45
46
47
50
51
52
53
54
58
60
64
65
66
67
70
71
72
74
75
76
77
78
82
83
84
86
89
90
93
94
95
96
98
100
101
105
106
109
110
116
118
123
124
130
135
137
141
142
144
146
151
154
157
159
164
166
167
169
172
174
178
182
184
185
186
187
189
190
191
192
193
194
195
200
202
203
204
205
206
207
208
211
212
214
218
222
225
228
230
232
233
235
236
240
242
244
249
250
251
253
254
258
261
262
266
267
268
271
273
274
275
278
280
281
282
283
284
285
286
288
289
290
291
293
295
296
297
298
301
302
303
305
306
307
310
311
315
317
318
319
328
333
350
353
354
356
359
360
361
370
372
373
374
375
379
380
381
383
385
386
387
388
391
393
394
395
397
398
399
401
409
410
411
414
420
421
422
423
424
425
427
429
430
434
438
439
444
449
450
454
457
458
459
460
461
464
465
466
468
469
470
471
472
480
484
486
487
489
490
00:00
Open SourceBenutzerbeteiligungOpen SourceZusammenhängender GraphSystemplattformComputeranimation
00:43
Inhalt <Mathematik>BenutzerbeteiligungMereologieMultiplikationsoperatorDynamisches System
01:15
InterpretiererCodeMechanismus-Design-TheorieProzess <Informatik>BefehlsprozessorAdditionApp <Programm>InterpretiererGeradeTypentheorie
02:22
Just-in-Time-CompilerFormale SpracheMultiplikationsoperatorCodeMechanismus-Design-TheorieFunktion <Mathematik>
02:51
Just-in-Time-CompilerInterpretiererLeistungsbewertungFunktion <Mathematik>CodeProzess <Informatik>GeradeInterpretiererJust-in-Time-CompilerMultiplikationsoperatorHalbleiterspeicherZusammenhängender GraphRückkopplungFunktionalPhysikalisches SystemInformationsspeicherungMatchingComputeranimation
04:25
SchnelltasteDifferenteComputeranimation
04:48
Just-in-Time-CompilerInstantiierungGlobale OptimierungGraphische BenutzeroberflächeRechter Winkel
05:12
Just-in-Time-CompilerDialektInterpretiererInterpretiererVersionsverwaltungMultiplikationsoperatorVererbungshierarchieZeichenketteParametersystemFunktionalComputeranimation
05:58
VorhersagbarkeitCodeBrowserLaufzeitfehlerParametersystemZahlenbereichFormale SpracheVersionsverwaltungClientInverser LimesCompilerGlobale OptimierungBimodulMobiles EndgerätTeilmenge
08:12
Virtuelle RealitätVirtuelle MaschineClientServerMobiles EndgerätSampler <Musikinstrument>BinärcodeDateiformatCASE <Informatik>SchnittmengeHöhere ProgrammierspracheServerZwischenspracheSampler <Musikinstrument>DateiformatBinärcodeVirtuelle MaschineBenutzerbeteiligungProzess <Informatik>SystemplattformClientMobiles EndgerätFormale SpracheSoftwareentwicklerMereologie
10:00
Mobiles EndgerätFormale SpracheBimodulSystemplattformFunktional
11:08
VersionsverwaltungComputeranimation
11:45
DiagrammCodePunktComputeranimation
12:12
Sampler <Musikinstrument>Syntaktische AnalyseÜbersetzer <Informatik>ThreadSampler <Musikinstrument>ThreadBrowser
12:42
ThreadThreadSampler <Musikinstrument>BrowserComputeranimation
13:06
RobotikDifferenteZahlenbereichTouchscreen
13:36
Mobiles EndgerätKernel <Informatik>BimodulDateiverwaltungCodeBrowserVersionsverwaltung
14:10
Interface <Schaltung>CodeBrowserNetzbetriebssystemPhysikalisches SystemFormale SpracheStandardabweichungBimodul
14:44
NetzbetriebssystemPhysikalisches SystemUmwandlungsenthalpieInterface <Schaltung>Bimodul
15:06
Kernel <Informatik>DiagrammPhysikalisches SystemLaufzeitfehlerBrowserBimodulInterface <Schaltung>SOLOMON <Programm>Twitter <Softwareplattform>ServerStandardabweichungVerschlingungNeuroinformatikTask
15:49
Dienst <Informatik>CodeFunktionalHardwareNetzbetriebssystemDefaultComputeranimation
16:14
App <Programm>ProgrammSchnittmengeBinärcodeCodeResultanteProgrammierungAutorisierungSystemverwaltungMalwareRechter WinkelSchlüsselverwaltungComputeranimation
17:16
SystemprogrammierungProgrammPhysikalisches SystemSchnittmengeSchlüsselverwaltungTaskProgrammierungMultiplikationsoperatorMalwareComputeranimation
17:48
Prozess <Informatik>ResultanteBimodulHalbleiterspeicherSoftwareComputeranimation
18:35
Physikalisches SystemDefaultProzess <Informatik>TelekommunikationProzess <Informatik>CodeResultanteBimodulPhysikalisches System
19:08
BimodulComputeranimation
19:33
Gewicht <Ausgleichsrechnung>BenutzerbeteiligungTeilmengeBimodul
19:58
Front-End <Software>Kartesische KoordinatenSchreiben <Datenverarbeitung>Gewicht <Ausgleichsrechnung>VerschlingungBrowserFramework <Informatik>
20:25
Kartesische KoordinatenVererbungshierarchieFront-End <Software>Programmbibliothek
20:53
CodeDefaultInternetworking
21:17
ZwischenspracheService providerPerspektive
22:32
BinärcodeBrowserDateiformatBimodulAssemblerLastBitInternetworkingRechter WinkelPhysikalisches SystemInterface <Schaltung>Computeranimation
26:26
FacebookPunktwolkeOpen SourceDiskrete-Elemente-Methode
Transkript: Englisch(automatisch erzeugt)
00:06
Hi everyone, welcome to this talk. My name is John. I'm an open source engineer at Hackages. And during the next 25 minutes, we are going to talk about the web. In my opinion, the web is an amazing platform.
00:22
And I think that we can all agree on one fact is that the web has evolved a lot since its beginning. We went from sending simpler text over the wire to providing a full experience to the end user. And I think one key component within the web that has brought this experience is JavaScript, right?
00:48
So JavaScript, built in 1985, shipped within the Netscape browser, was aiming to provide some dynamism to the static content of the web. But what we were trying to achieve
01:02
with JavaScript at that time, it's a much smaller part of what we are doing with it now. So the way that it was executed at that time is quite different from the way it is executed nowadays. So at that time, JavaScript was interpreted, okay? And to take a closer look at what interpretation is,
01:21
for example, here we have in the middle, our interpreter, JavaScript interpreter, okay? And on the right side, we have kind of like the bare metal machine, the CPU. On the left, we have a bunch of JavaScript code lines calling add functions, passing numbers. And when the execution hits the first line, the line is sent to the interpreter.
01:41
The interpreter does his job, okay? Evaluates both parameters, their type, what we are trying to achieve, and then outputs some matching code that gets directly executed by the CPU. Next line, same process. Again, evaluating both parameters, saying what kind of types they are, and then outputting some matching code.
02:01
And the thing here that this mechanism worked until kind of 2005, when big JavaScript apps started to come onto the scene. And one example is Google Maps, which browser started to hit kind of like a performance issue with those JavaScript app.
02:21
And why? Because at the end, doing a simple addition in JavaScript is not trivial. You have to check both operands, types, and regarding the evaluation, you will output some different code. So you cannot really count on the language by itself.
02:42
You have to wait until run time. So one of the mechanism that browsers applied to solve this issue, it's a very well-known mechanism, which is called just-in-time compilation. And if we take back the same example, we still have both items there, but you have a third one, a third component within the system
03:01
which is the just-in-time compiler, okay? We take again the same lines. First line is sent to the interpreter. It does the same, evaluates, interprets, outputs some matching code, and that's it. Second line, same process. Evaluate it, both parameters, and then output some matching code.
03:21
But this time, the interpreter has monitored the code and the execution, and it has some feedback about the execution. So you can see that, okay, we try to execute twice the same function, passing twice numbers. So it marks that function as hot,
03:43
and then pass it to the just-in-time compiler to compile it and output the same matching code that it was previously outputted, store it somewhere in memory, and lock that memory region so we cannot override it. Third line comes to execute it.
04:02
And then there, the interpreter say, okay, I know this add function. It's not the first time. I just asked the just-in-time compiler to compile it and put it somewhere in memory. So all still are still both parameters, numbers? Yes? Okay, you can then take the one that I just compiled it
04:22
and directly execute it. And if you see this here, what we have done, what the engine have done is just that he made a shortcut for the execution of a function. And we call that the fast path, okay? And that's when JavaScript gave us his top speed.
04:45
And just to show you the difference between non-JITed code, so non-JITed JavaScript and JITed JavaScript, I just launched an instance of Chrome disabling the optimization of JavaScript. And you can see for 8-Robot Dancer, it's kinda laggy on the left side,
05:02
but on the right side, it's kind of going very well. I think I increased until 15, and it's still okay. But then, well, we had the performance issue with JavaScript, with interpretation. We compiled it, and it works pretty well. Why do we want to go further? Well, the thing is that I didn't tell you the whole story.
05:25
If we go back to example, and this time I'm sending instead of two numbers, one string and one number, the interpreter will try again to say, okay, I know this function. I just store it somewhere. But are still those two parameters numbers?
05:44
Nope. So what he's doing is that he is going to fall back to interpretation and erase the compiled version that he had. Yeah, super animation. So at the end, what's the problem with JavaScript?
06:01
Well, I mean, not the problem. I don't want to offend you. I'm sorry. I'm sorry. And then what's the thing? What JavaScript is lacking to be optimized before execution? Well, JavaScript is just lacking predictability. If you take two versions of the same code,
06:24
one written in C and another in JavaScript, you can clearly see that in C, the language provides some hints to the compiler so he can optimize code before runtime. If you look at the JavaScript side, there's not much going on there.
06:40
Even the number of parameters are not really fixed. So you can pass more than two if you want. So if we quickly recap what we learn here, or no, maybe what we have to. So we can optimize JavaScript, and it's cool. And you can have really good performance
07:01
where it's not a problem. But the thing is that JavaScript is not predictable. So the industry, browsers have tried to solve this problem. I mean, to solve that, to fix this. And they tried to run some more predictable code within the browser. And one of the initiatives is, for example,
07:20
portable native clients from Google, which was to run some C++ modules within the browsers, sandboxed, so it's secured. But it didn't really took off. After that, MoziLab came with an idea of just taking a subset of JavaScript
07:42
which was more predictable. And they call it asm.js. But it wasn't enough, because it was still JavaScript at the end. And in 2015, browsers reunited and tried to come up
08:02
with something that they could agree on to go a step further, to push the limit of the web. And that's where WebAssembly came onto the scene. And what is WebAssembly? If we take quickly just the text from the official page, which is quite dense, I'm gonna read it. So WebAssembly, abbreviated WASM,
08:20
is a binary instruction format for a stack-based virtual machine. WASM is designed as a portable target for compilation of high-level languages like C, C++, Rust, enabling deployment on the web for client and server application. A lot of things, huh? We are going to try to read it again, but step by step.
08:41
So WebAssembly, abbreviated WASM, is a binary instruction format. So it just means that it's a set of instructions encoded in a binary way. So it's quite efficient to load it. Designed as a portable target for compilation. So two things here. Portable, it means that WebAssembly is not just designed for the web,
09:01
but it's also designed to run outside the web on other platforms. And target for compilation means that you don't have necessary to write WebAssembly. It's quite low-level. You are more likely to write in higher-level languages like C, C++, Rust, Go, C-Sharp, Java, whatever,
09:21
and you compile to WebAssembly. So how the process goes? Simply, you take a bunch of files, C, C++ here, I just, okay, I mentioned just C and C++. You compile it to intermediate representation. It's almost always LLVM.
09:40
I will skip the details about LLVM, okay? But normally this part is quite hidden from the developer perspective, okay? And then you compile as a backend compilation to a simple, .WASM in this case is the name, but it was a module, okay? And with which tool, for example, one of the main tool to compile to WebAssembly
10:00
is InScriptor, which first mission, mainly mission, is to brings other languages on the web. So then how do you consume this simple .WASM? Well, you fetch the resource. I think you all know this. You fetch the resource, and then you just call the JavaScript API,
10:20
WebAssembly APIs that are nowadays available in all the browsers, the major browsers, and then you receive a .WASM module which you can call function on it. Here, exported from, and those function were originally written in another language.
10:41
So what are the goal of WebAssembly? WebAssembly wants to be performant, run at nearly native speed. After that, WebAssembly wants to be portable, okay? So not only running on the web, but also running in all the platforms. And secure, secure by default. It's one of the main concern of WebAssembly,
11:02
being more secure than JavaScript. Performance. Well, I might disappoint you, but WebAssembly is not so much faster, so more faster than super optimized compiled JavaScript.
11:23
At the end, they quite run nearly at native speed, sorry. But the thing is that JavaScript, I mean, WebAssembly will more likely to stay on the fast path when you have an optimized version of it while JavaScript will kind of de-optimize easily
11:43
and falls back to interpretation. And to illustrate my point, here you have a multiple, just diagram showing multiple execution of the same code in JavaScript and then the same code in WebAssembly in blue. WebAssembly is faster, okay, but the point here is to show that
12:00
for multiple execution of the same code in JavaScript, you cannot predict the performance. While in WebAssembly, it's quite almost the same. Also, WebAssembly can be decoded, validated, and compiled in a fast single pass, equally with either just-in-time or ahead-of-time compilation.
12:23
If you check how JavaScript is handled within a browser, you first fetch the whole resource and then you parse it, compile it, and execute it. All that in the main thread. There are some exceptions, okay? Not everything happens sometimes in the main thread, but that's kind of the regular way of doing it.
12:42
But browsers handle WebAssembly in another way. So while fetching the packets, while fetching the resource, the WASM modules, the browser will directly compile the bytes that are on the fly. And when it's done, it will execute on the main thread.
13:00
And the compilation doesn't happen on the main thread, so it does not block users. Just to show you the difference of performance, you have 30 robot dancers here, and you can see that JavaScript is quite laggy. When you switch the execution to WebAssembly,
13:21
it goes back to normal. And you can even increase the number. And I go there until, I think, 120, but you will not see the difference because the screen is too short, yeah. Okay, so portable. At the beginning,
13:41
the first version was meant to at least work on the browser. So the way of execute was to provide some GS glue code that when a WASM module was trying to do something that the browser couldn't handle, at least the JavaScript will handle the code
14:01
and simulate something, emulate something. For example, calling a file system. You cannot call a file system within the browser. So when folks tried to run WASM outside of the browser, what they tried to do is just to run the existing WASM module outside the browser. And so they were kind of emulating GS glue code
14:23
that was emulating a system interface. So it's not really the most optimized way to do it. So a need of, as much as WASM is a language for a conceptual virtual machine, it needed a system interface, a standardized system interface
14:42
for a conceptual operating system. That's when WebAssembly system interface came onto the scene. It's just a specification that WebAssembly modules can call to make some system APIs call. It's just an operating system.
15:02
Let's say it's kind of like a POSIX way of doing, okay? So then the diagram becomes like that. You have the non-browser or browser runtime that implement WASI and expose some system interface API that WASM modules can interact with.
15:22
I wanted to show you one tweet of Solomon Hikes, which is the founder of Docker that is saying that if WASM was existing in 2008, we wouldn't have needed to create a Docker. That's how important it is. It is WebAssembly on the server is the future of computing.
15:43
A standardized system interface was the missing link. Let's hope WASI is up to the task. Also, folks from CleverCloud, a French company that is, I think here, maybe you have met them, are running function as a service in WebAssembly directly on the hypervisor.
16:03
So no operating system between the code and the hardware. Okay, WebAssembly wants to be secure by default. Nowadays, when you code, the result set of binaries is just 20% your code
16:25
and 80% dependencies that you haven't written. Then what happened is that the way that we execute programs nowadays is just, they execute within the ambient authority. So me as an admin of my machine,
16:40
I'm going to ask my program to run, and then I'm going to provide him my whole set of keys, the permissions that he can, so he can run. Maybe he doesn't need it, but it's okay. I just wrote the code, so I know it will not do some malicious things. The problem is that it also passed the whole set of keys to its dependencies, okay?
17:04
And sometimes you have a malicious dependency, okay? So that malicious dependency can then use all the rights that you provide to execute some malicious code. WebAssembly wants to execute itself as a capability-based systems.
17:22
So it means that I still have this whole set of keys, but when I'm going to run the whole program, I'm not going to pass all the permissions. I'm just going to pass the permission that I think my program needs to perform his task, okay? So I'm just passing here kind of one key, and then this key is passed to all the other dependencies,
17:42
but this time the malicious code is quite blocked and cannot really perform the malicious task. Also, one obstruction that WebAssembly wants to provide is called nano processes. So the idea here is to execute competing modules,
18:01
wasm modules in the same process. So kind of the result is kind of like that. So you have the whole process, which is like the big blue box, and then inside you will have like the first one is like your main module, the one that you have written, and it has dependencies to other modules,
18:22
but they all run within kind of in a sandboxed way, and they think that they are alone within the memory space, the process. It's just a software fault-implemented isolation. So why wasm wants to be secure?
18:41
Because first it provides capability-based systems. Also, it's sandboxed by default, okay? So you can run low-level code in a secure way, and also nano processes provide a way to communicate between different modules
19:00
a lot much faster than inter-process communication, okay? And the end result is kind of like that. So you write your main module in, for example, Rust, and then you consume some dependencies that were originally written in other languages,
19:22
like C++, Go, and so on. I mean, there are not only these languages, huh? There are a lot of more, but voila. So projects. I just took two examples. There are a lot, okay, but you can check. As you are all JavaScript developers,
19:42
I wanted to show you AssemblyScript, which is just, it's a subset of TypeScript that does not compile to JavaScript or transpile to JavaScript, but compiles directly to wasm modules and web assemblies, okay? And because I'm a .NET guy, I wanted to show you,
20:02
I'm also a .NET guy, I wanted to show you that you can run now the CLR, so the .NET, on the browser through WebAssembly, and they provide now kind of a framework which is quite similar, like Angular, to write front-end applications in C-sharp.
20:24
Go check this link. It's really interesting. There are a lot of things, and that guy, M. Basu, I think he's Italian, and he's doing a C++ front-end library to write front-end application that compiles to WebAssembly,
20:42
and it has also provided kind of like GA6 syntax for C++. It's super interesting. The bytecode aliens. So big companies reunited and tried to push WebAssembly and secure it by default web,
21:02
and they call themselves bytecode aliens. These are the four founders of the aliens, and you see pretty big names, and just to tell you, Fastly is running 10% of the internet. And I will end up my talk with one quote that I think can kind of resume what I feel about WebAssembly,
21:25
is that WebAssembly is the first fast multi-language, retargetable, and safe intermediate representation that we have ever agreed upon as a community. CTO of Fastly. Voila. Thank you.
21:47
Okay. Any questions? Yes? Yes? Yes, of course.
22:00
Is better to run on Node.js? Vasm or C++ and why? It's a question that a lot of folks are asking. To be honest, I think that for now it's C++ that will continue to be like the major solution to provide native performance within Node modules, but at the end it will switch to WebAssembly modules,
22:23
because I don't know, in my humble opinion, I think it's kind of like the future of the industry in this perspective. But they both solve your issues, which is giving you performance and so on.
22:43
WebAssembly is a fairly young language. Do you have an overview of the tools and debugging tools around it? Because as it's a binary format, I guess it's a bit harder to debug than let's say vanilla JavaScript. Yes. Okay, so there are already, I think,
23:02
some browsers that provide debugging tools to work with WebAssembly modules. You have, I think within Mozilla Firefox, you can already kind of work with it and debug. The thing is that I didn't mention, and you're right, WebAssembly has two representation.
23:23
It has the one that browsers use to execute it, which is the binary format, because it's load efficient and so on. But for human readable, it's not the most human readable format. So they also have a text representation, which is WebAssembly text, I think, what, or something.
23:42
It's called what. And then you can really clearly see that it's low level, it's kind of like an assembly code. I have a question about the micro-frontend and how WebAssembly will do in this architecture. Assembly?
24:01
Yeah, WebAssembly. WebAssembly will do in which architecture? In the micro-frontend. The micro-frontend architecture. Okay. WebAssembly are quite, I mean, it's composed of several modules. So if your concern is to say,
24:21
do I have to download the whole module, a big, big, big module to execute it? No, you can kind of speed it. And in the future, you will be able to lazy load it. So yeah, I think you can already do that now. Because at the end, as you see, as you saw, I mean, you're just fetching a resource on the internet
24:42
and then you can fetch it whenever you want. If it's, sorry? Yes, I will say yes, yes. There is no really, they're not competing. I mean, if they're loaded into your browser, you can run it on both sides.
25:01
But maybe you will struggle a bit to make them work together. But I think it's completely feasible, of course. Okay, is WebAssembly able to access to the GPU? Okay, so this talk that I've done, it's normally much, much larger and I've covered all the topics.
25:23
One thing that, so your question is, is it possible to call some GPU APIs from WebAssembly? Right now, no. Because the only thing that provides, that is standardized is WASI, which is kind of like a system interface to call some, the OS APIs.
25:43
The thing is that WASI wants to extend itself. And so you, in the future, you would be able to call some specific, domain-specific low-level APIs. Can, for example, GPUs, okay? Or you will be able to call, I don't know, something related to blockchain or whatever.
26:01
So, go check WASI, go check it on the internet. WASI, they really want to extend themselves and they're open to feedback from the community. Thank you so much. Thank you. I'm, I'm, I'm very grateful. So, if you don't have,
26:20
he might be available just outside for questions. Yes, yeah. The exit, look at.