Bytecode Alliance

I could have better explained what I was talking about. The point of a custom kernel would be to get extremely fast startup and context switch times, and extremely low per-process memory overhead, by doing things that Linux doesn't do - either because they're unnecessary or unhelpful for typical Linux use cases, or because they require making stronger assumptions about what userland needs to do. As a relatively flashy example, if you can assume that processes don't need overlapping addresses, you can share page tables between processes and rely on PCID/ASID to ensure each process can only access its own memory. [3] But there are also simpler things like - on Linux, starting a process requires forking the parent process, creating copies of its page tables, only for `exec` to immediately throw them away. Even posix_spawn is implemented on top of vfork. That's fast enough for Linux, but it's unnecessary. A custom kernel that doesn't provide Unix compatibility could dispense with it.

To be fair, none of that may be necessary. This blog post is advertising 1-2ms startup time. Based on a little benchmark [1] I just ran, on my desktop, Linux can execute a trivial process (/bin/busybox true) from start to finish in 0.4ms. A real application executed normally would obviously take much longer to start up. But I think their 1-2ms number is based on snapshotting the process after initialization, so a fair comparison would do that on native as well. Full process snapshotting…

> I can't really square the idea that the 50-150ms time-delays in question comes down to the actual programming language, but it is absolutely believable that a longer test reduces the median latency rather than a high load test for a shorter duration.

It seems plausible to me: in Fastly's case, they're using WebAssembly via wasmtime[1] which does support AOT compilation but most JavaScript code is dynamic enough that they still need a runtime JIT engine. I believe the the current approach Fastly is using is to compile Mozilla's SpiderMonkey JIT engine itself into WebAssembly and they've done some really nice work making that load as quickly as possible:

https://bytecodealliance.org/articles/making-javascript-run-fast-on-webassembly

The catch, of course, is that this still leaves a fair amount work which a JavaScript program has to deal with at runtime compared to a Rust program which the compiler can spend minutes optimizing long before deployment. This is a classic tradeoff for dynamic languages and a lot of people are satisfied with the approach of defaulting to faster developer turnaround and later converting hot spots to something like C or Rust, but I think it's definitely dodgy to use a single example of something you know to be this complex and present the results as generally representative of the entire platform.

I have no knowledge of how Cloudflare ran their tests or reason to suspect malice but not disclosing test methodology and a “no benchmarks” license…

This paper describes how Vanessa's groundbreaking Smalltalk VM implemented in JavaScript runs historic Smalltalk images, and elegantly and efficiently integrates Smalltalk's garbage collector with JavaScript's.

I've written about her work and this paper previously on Hacker News:

https://news.ycombinator.com/item?id=40917424

DonHopkins 4 months ago | parent | context | favorite | on: Dynamic translation of Smalltalk to WebAssembly

Here's some stuff Vanessa and I discussed about Self and her SqueakJS paper:

DonHopkins 6 months ago | parent | context | favorite | on: Croquet: Live, network-transparent 3D gaming

Excellent article -- Liam Proven does it again! Speaking of a big Plate of Shrimp -- https://www.youtube.com/watch?v=rJE2gPQ_Yp8 ...

The incredible Smalltalk developer Vanessa Freudenberg -- who besides being Croquet's devops person, also developed Squeak Smalltalk, EToys, Croquet, and the SqueakJS VM written in JavaScript, and worked extensively with Alan Kay -- was just tweeting (yeah, it's ok to deadname Twitter!) about reviving Croquet from 20 years ago:

https://twitter.com/codefrau/status/1738778761104068754

Vanessa Freudenberg @codefrau

I've been having fun reviving the Croquet from 20 years ago using @SqueakJS . It's not perfect yet, but a lot of the old demos work (sans collaboration, so far). This is pretty close to the version Alan Kay used to give his Turing Award lecture in 2004:

https://github.com/codefrau/jasmine

Live version:…

Interesting to see that it has JavaScript support built in. It seems to be based on QuickJS which will work for some things but as they acknowledge quite slow.

> In the end, running v8 in a cloud-native environment often requires a full stack of software tools consisting of "Linux container + guest OS + node or deno + v8", which makes it much heavier and slower than a simple WasmEdge + QuickJS container runtime.

https://wasmedge.org/book/en/write_wasm/js.html#a-note-on-v8

Whether it's faster or not really depends on the complexity of what's being run. After reading about wasmtime 1.0's super fast 5 microsecond snapshot restore time (https://bytecodealliance.org/articles/wasmtime-1-0-fast-safe-and-production-ready) I did some experiments with QuickJS and Javy which runs QuickJS in wasmtime. Rendering a moderately complex web page with React renderToString production 30kB of html on my MacBook Air M1 took:

- Deno first iteration: 12-20ms

- Deno subsequent iterations: 2-4ms

- qjs native: 18-24ms

- javy (qjs wasmtime): 40-60ms

I've not tried WasmEdge but it's JS performance would presumably fall somewhere between that of qjs native and under wasmtime.

Firecracker claims a ~3ms snapshot restore time on ARM so might be the best way to go currently for such workloads but there is certainly a large subset of problems for which the current performance is adequate.

There has been talk of AOT compilation for SpiderMonkey.wasm…

The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt.

Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.

If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I think that's great. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime with the strongest long-term outlook), nor will it run in browsers, because they're going to follow standards.. not WASIX. I don't think anyone believes exposing POSIX fork() to WASM is a good idea, even if it lets you build existing apps 'without modification'.

Please stop accusing me of being polarizing. I just don't want to live in a world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall. I want good tech to win, not shitty power plays.

[0] https://github.com/bytecodealliance/jco/issues/247#issuecomment-1799182341

[1] https://bytecodealliance.org/articles/wasmtime-and-cranelift-in-2023

[2]…

I don't think it's fair to say this work has happened in the shadows. I work on CNCF wasmCloud, and I know how hard we try to make this content available.

- Many standing meetings organized around SIGs, all on the public community calendar: https://calendar.google.com/calendar/u/0/newembed?src=events@bytecodealliance.org

- A dedicated Zulip: https://bytecodealliance.zulipchat.com/

- Conferences organized around exactly these topics: Wasm Day, WasmCon, Wasm I/O, and the Bytecode Alliance Plumbers Summit

- CNCF projects: wasmCloud, Spin

- Blogs, many with recordings, summaries, and transcripts: https://bytecodealliance.org/articles/the-road-to-component-model-1-0, https://wasmcloud.com/community/, https://spinframework.dev/blog/index

If you want the architectural direction straight from the source, Luke Wagner's keynotes are the best place to start:

- "What is a Component (and Why)?" (WasmCon 2023): https://www.youtube.com/watch?v=tAACYA1Mwv4

- "The Path to Components": https://www.youtube.com/watch?v=phodPLY8zNE

- "Towards a Component Model 1.0" (Wasm I/O 2026): https://www.youtube.com/watch?v=qq0Auw01tH8

I mean this, though - what else would you like to see to try and make the content and process more accessible? Are there communities that are doing this really well that we could use for inspiration?