Це відео не доступне.
Перепрошуємо.
A WebAssembly Deep Dive 🔎 - How Wasm works under the hood
Вставка
- Опубліковано 8 січ 2024
- Join us for our weekly coding livestreams. This week we're going to explore the inner workings of Wasm w/ Caleb Schoepp
Check out developer.fermyon.com to get started
Nice explanation on WASM, thanks
Great video and great presentation -- very clear and easy of understand explanation by Caleb 👍
Thank you!
Wow, that was the best explanation for wasm
Thank you! Do check out Spin
Great presentation, thank you. Example at 31:47 is confusing. I think a custom function should have been imported instead of console.log. How does built in console.log is supposed to conjure a string out of two numbers?
How did you do those code window visualizations? They look awesome! 🙂
Thanks! That's just Google Slides / Powerpoint :-D
You know what I am missing in all talks (I have already found) on the internet? The explanation of "what can be done with wasm". If it is so secured.. how the hell can they run Doom in it? How for example Figma website, Google Earth does use wasm? Can Wasm create whole GUI on the web? Because for an beginner trying to understand wasm, it seems like I can do whole Figma, Google Earth, Doom in wasm, right? But in the end.. isn't Figma (or any similar website) still fuuuuull of javascript and only small portion is in Wasm (the math performance oriented things)?
The security in Wasm is about the sandboxed environment. Each WebAssembly module executes within a sandboxed environment separated from the host runtime using fault isolation techniques. So you can run Doom in a Wasm module which will execute independently, and can’t escape the sandbox without going through appropriate APIs. At the same time, no buggy or malicious modules can access this Doom app unless explicitly given permissions to do so.
"RISC Vee" 😔
Glad I'm not the only one who noticed that one
What is confusing for me is, that the first definition says that Wasm is "portable binary-code format" and few moments later you say it is "another bytecode format". I thought, that binary = machine code. And bytecode is something higher level. But maybe I am wrong?
A binary format does not necessary mean machine code. It just means that it is not text-based. For example wasm and protobuf (used grpc) are binary formats, the underlying bytes do not conform to a text-representation. On the other hand wat and json are text formats, if you look at them in a text editor, you see textual characters that should means something.
So wasm is both a binary-code format and a bytecode format. It is binary-encoded and represents some sort of machine-understandable computation, although on a higher level that machine-code itself, but lower level that programming languages.
Wat would be a text-based bytecode format. It still represents some sort of computation, but now encoded in a textual-representation.
Keep in mind that these terms are not perfectly defined and there are a lot of edge cases that would break these definitions. For example most people would assume that a bytecode format also is encoded as binary, but if you look up wikipedia for a definitions, it did not say whether a bytcode as to be binary, just that it needs to be efficiently interpretable by machines, whatever that mean. But then its just wikipedia, and binary encodings are usually faster for machines than textual.
Firstly great presentation.. Caleb has this uncanny abiility to explain things clearly. Please invite him more :)
Confused about AOT and JIT.. Please validate my understanding
AOT: In server-side usecases, generally we are aware of the processor architechture so instead of interpreting unopinionated wasm bytecode, we could compile the wasm bytecode to machine code of a known architecture. The runime like wastime need not do everything from scratch and can directly execute the AoT compiled instructions.
JIT: I am assuming JIT compilation can implement more advanced techniques branch prediction, inlining etc.. based on the stats collected when the AoT compiled wasm module is actually running.
The dividing line between JIT and AOT is whether you're compiling code while executing. Wasm's AOT is basically classical compilation but delayed a bit, but still before the program starts. JIT comes out of the land of interpreted languages, as a way to make interpreters faster.
You can JIT everything, while not everything can be AOT compiled. AOT has less runtime overhead but also less flexibility, in the end restricting wasm to features supported by AOT means that implementations can choose between both approaches. It also makes supporting heavily dynamic languages (say, lua or python) quite a bit more involved but that can be dealt with by extensions to the AOT-capable core, no need to make everyone use JIT which would be rather pointless if your source language is C or Rust or such.
As to JIT being faster due to being able to collect stats: Not really. Java is blazing fast for a dynamic language (reflection and everything) but it still doesn't compete at the very top end. Your CPU is already tracking lots of stats, including what's necessary to predict branches. If you want to exploit that kind of thing to get faster than plain AOT native code an off the shelf JIT probably won't gain you anything, you have to roll something specific to your algorithm so that it can exploit domain knowledge.
@@aoeuable Thanks a ton for the detailed response.
> while not everything can be AOT compiled.
Is this because the target architecture is NOT known in advance? I am assuming that wasm bytecode does not have any dynamic behaviour (like JVM bytecode which poses a challenge for AoT compilation)
> no need to make everyone use JIT which would be rather pointless if your source language is C or Rust
This is interesting and definitely makes sense. For languages like Java, JS because of their dynamic nature JIT can generate actual machine code based on the invocations stats (dynamic dispatch for eg). Definitely not needed for C / Rust as the targets are known during compilation time.
@@GK-rl5du wasm bytecode indeed isn't dynamic and in the video they're kinda mixing up AOT and JIT (or at least not making the same distinction as I). While wasm doesn't know the architecture in advance it still compiles everything before starting execution, which is AOT, just a bit later than usual.
Or, differently put: While native compilation usually goes source -> intermediate representation -> native code, WASM does source -> (probably intermediate representation) -> portable interchange format (i.e. .wasm files) -> (possibly intermediate representation) -> native code.
@@aoeuable When we execute a wasm module via a wasm runtime (wasmtime for eg) the runtime interprets the wasm bytecodes? Or would it compile wasm module to native code, put it in some tmp dir and fork a process out of it?
@@GK-rl5du That depends on the implementation. But wasmtime compiles directly into memory and then executes it.
You are going to compile the Python interpreter to WASM and run that on a WASM runtime and then have that towering inferno run Python? This is horrifying!
UDDI was essentially abandoned in 2005, for good reason ... please don't revive it