5 ms·
... in browsers. Which at best JIT compile. There are several WASM runtimes that AOT compile and have significantly better performance (e.g. ~5-10% slower). Th
by turbolent 11mo ago
... in browsers. Which at best JIT compile. There are several WASM runtimes that AOT compile and have significantly better performance (e.g. ~5-10% slower).
The title is highly misleading.
- astafrig 11mo agoIt’s not misleading to measure the performance of WebAssembly in a web browser.
- bjconlan 11mo agoYeah, but it's specifically testing things that implement against a posix API (because generally that's what "native" apis do (omiting libc and other os specific foundation libraries that are pulled in at runtime or otherwise) I would suspect that if the applications that linked against some wasi like runtime it might be a better metric (native wasi as a lib/vs a was runtime that also links) mind you that still wouldn't help the browser runtime... But would be a better metric for wasm (to native) performance comaparison. But as already mentioned we have gone through this all before. Maybe we'll see wasm bytecodes pushed through silicon like we did the Jvm... Although perhaps this time it might stick or move up into server hardware (which might have happened, but I only recall embedded devices supporting hardware level Jvm bytecodes). In short the web browser bit is omitted from the title.
- wffurr 11mo agoWebAssembly is neither web nor assembly. It’s a low level byte code format most similar to LLVM IR.
- pyrolistical 11mo agoJust means the browsers can catch up. Initially slower but then faster after full compilation
- padenot 11mo agoBrowsers have been doing (sometimes tiered) AOT compilation since wasm inception.
- chalcolithic 11mo agocould you please name them?
- wffurr 11mo agoWAMR (WebAssembly Micro Runtime), wasm2c in WABT (WebAssembly Binary Toolkit), Wasmtime.
- chalcolithic 11mo agothank you very much!