Google Bringing WebAssembly Extensions To Network Proxies

[phoronix]

Phoronix: Google Bringing WebAssembly Extensions To Network Proxies

In addition to WebAssembly's growing presence outside of the web browser thanks to various desktop run-times and interesting use-cases, WebAssembly is also popping up in other areas. Google has been working on WebAssembly support for extensions within network proxies typically reserved for C/C++ or the likes of Lua scripts...

http://www.phoronix.com/scan.php?page=news_item&px=Google-WASM-Net-Extensions

[Ardje]

But why?
Lua is extremely good for this, and at least Lua is tiny and very very fast. There is a reason kmod_webassembly does not exist, but kmod_lua does.

[ssokolow]

There is a reason kmod_webassembly does not exist, but kmod_lua does.

Because Lua has had 27 years to gain market penetration while WebAssembly has had only three?

[grigi]

OK, so let shove a webassembly runtime into critical software, which is significantly larger than said critical software.
Nah, increasing complexity THAT much won't hurt us a bit? eh?

PS: a lua runtime can be as small as 4k, and luajit is surprisingly fast (and still only 200k runtime)

[ssokolow]

OK, so let shove a webassembly runtime into critical software, which is significantly larger than said critical software.
Nah, increasing complexity THAT much won't hurt us a bit? eh?

PS: a lua runtime can be as small as 4k, and luajit is surprisingly fast (and still only 200k runtime)

The problem is that, when you start to need to squeeze the kind of performance that Google does out of their hardware, the "Auto-vectorization is not a programming model" effect applies to JIT compilation. You need a language which provides more ways to say "falling off this aspect of the fast path is a compile-time error".

Cloudflare has been doing something similar since 2018.

Also, from the perspective of the host software, the complexity is in the WebAssembly loader, not the runtime. Does the weight of GCC or LLVM make optimized C or C++ slower than LuaJIT?

The complexity in a WebAssembly runtime is down to it containing the arch-specific optimizers and IR-to-machine-code translation stage that would normally be performed inside GCC or LLVM. Once the machine code is generated (something which can be done once and then cached on non-volatile storage until the hash on the input WASM file changes like the extracted contents of a Zip file), the result is lighter than Lua because it has a comparable approach to sandboxing (make the language/bytecode unable to describe accessing resources outside what are granted) but it's compiled machine code and needs no garbage collector or JIT engine.

WebAssembly has the same flat, un-GCed memory model that things like malloc and free expect. If you want a GC in a WebAssembly app, you either compile it to WebAssembly and run it inside the sandbox or you wait for extensions currently being worked on, like "opaque reference types" which allows WebAssembly applications to interact with objects managed by a Garbage Collector external to the sandbox. (That's why WebAssembly in the browser currently needs to be paired with JavaScript code. Only JavaScript can interact with the DOM currently, because the base 1.0 version of WebAssembly only communicates with the outside world through passing messages containing sequences of 8-, 16-, or 32-bit integers or floats. 64-bit support is also on the near-future roadmap but wasn't considered necessary for the 1.0 release to be useful and, to pass a string between JavaScript and WebAssembly, you need to serialize it to something like UTF-8.)

[qarium]

Can we have Browser based web-PTS (Phoronix-test-Suit) ?

it would be very nice and it would bring PTS to a bigger market all the smartphones could be benchmarked.

[NotMine999]

A picture of Google's response to user complaints about Web Assembly:

https://www.instagram.com/p/B736trpniOt/?utm_source=ig_web_copy_link