61–70 of 106 posts
Earlier quoted context omitted.
An AOT compiler would do a one-time translation to a platform-specific binary. If the environment you run on doesn’t support JIT compilation (iOS for example), AOT compiling WASM is useful.
At that point, what's the purpose of using WASM at all?
For those wondering, Wasm3 describes itself as "the fastest WebAssembly interpreter". Other webassembly runtimes are JIT based, rather than being interpreters. The project's readme ( https://github.com/wasm3/wasm3 ) talks more about this decision. For more on the difference, and an explanation of what JIT is, check out this section of the book Crafting Interpreters ( https://craftinginterpreters.com/a-map-of-the-terr…
Wasm3 calls its interpreter design a "meta machine": https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md... It is heavily based around tail calls. I recently wrote a blog article about how we applied a similar tail-call-oriented strategy to accelerate protobuf parsing to 2+GB/s: https://blog.reverberate.org/2021/04/21/musttail-efficient-i... I also recently landed a change in Clang trunk that offers guarante…
Earlier quoted context omitted.
Agreed. An interesting example is the new Microsoft Flight Simulator, which uses WASM[0] as a sandboxed language to create airplane gauges and custom flight models (HN discussion[1]). [0]: https://forums.flightsimulator.com/t/getting-started-with-wa... [1]: https://news.ycombinator.com/item?id=24281400
Very Cool!
Earlier quoted context omitted.
In general I agree with your points, but: > What WASM will never be good at is being used for the whole experience. The Flutter team would disagree. They are leaning on WASM for browser builds of Flutter apps, with the whole app rendering in a canvas. They do accessibility via separately created accessibility trees. The experience far from great at the moment, but give it a few years and I think it will get there. (b…
Flutter feels so strange to me. In many ways, it's reimplementing major parts of a browser, compiled to (web)assembly, running inside a browser compiled to assembly... Watch five years from now someone add a low-level programming framework to Flutter and then soneone else reimplement the browser using that
Earlier quoted context omitted.
Wasm3 calls its interpreter design a "meta machine": https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md... It is heavily based around tail calls. I recently wrote a blog article about how we applied a similar tail-call-oriented strategy to accelerate protobuf parsing to 2+GB/s: https://blog.reverberate.org/2021/04/21/musttail-efficient-i... I also recently landed a change in Clang trunk that offers guarante…
How do guaranteed tail calls work when you needs to put arguments on the stack, which usually prevents tail call? (and whether a specific call needs to pass arguments on the stack depends on the platform, and the number and type of arguments)
These rules guarantee that the tail call is possible to perform on every platform. They end up being more strict than is necessary on some platforms and calling conventions.
Earlier quoted context omitted.
How can a platform not support j.i.t. compilation? In what way does a platform need to coöperate with that?
A JIT generally means it compiles parts of the program to machine code on the fly before running them, as needed. To support that, the environment must allow the JIT to write machine code to memory, and then execute that same code. CPUs have memory protection flags to control which memory areas can be written, and which can be executed. The OS is in charge of setting those flags, on request from the application. Eg.…
Earlier quoted context omitted.
> Other webassembly runtimes are JIT based, rather than being interpreters. Do none of the notable ones do normal compilation?
I worked on one as an undergrad: https://github.com/gwsystems/aWsm Full AoT compilation, C programs run within 10% of native
Lost information about e.g. aliasing?
I'm a newer dev so pardon my ignorance. Is webassembly the new, more open JVM? Feels like that write once, run everywhere but this time with any(most) mainstream language.
It lacks most of java's ‘batteries’—there are projects like WASI that try to resolve this at a low level, but they miss the point somewhat. On the other hand, wasm is saddled with fewer assumptions about the type of code that will run on it. Wasm has generally poorer performance, which is mostly (though not entirely) an artifact of its design, and hence not easily rectifiable[0]. It's not clear to me the extent to which the jvm suffers similarly[1].
Socially, I think wasm is not as interesting as java. Write-once-run-anywhere was solved in practice not by java but by open source; by compatibility libraries like sdl; by standards, like posix and opengl; and by static linking. (Yes, it's not quite as convenient as just plopping in a jar, but it's close enough.)
I don't think we're ever going to see a desktop full of wasm apps. Despite stated goals, the point of wasm was always to be an evolution of the web as a platform for applets. The Birth and Death of Yavascript[2] has many insights thataways (even though it failed to predict wasm as such).
0. https://www.usenix.org/system/files/atc19-jangda.pdf
1. It's also difficult to directly compare the performance of the two systems in their current state. A number of proposals for both (gc for wasm, value types for java, simd for both) are yet pending and are likely to change the runtimes' respective performance profiles.
2. https://www.destroyallsoftware.com/talks/the-birth-and-death...
Earlier quoted context omitted.
Flutter feels so strange to me. In many ways, it's reimplementing major parts of a browser, compiled to (web)assembly, running inside a browser compiled to assembly... Watch five years from now someone add a low-level programming framework to Flutter and then soneone else reimplement the browser using that
Flutter is a UI framework on top of a low level programming framework, Dart. Sort of like UIKit and Cocoa.