5 ms·

WebASM really only makes sense in the context of embedding untrusted code, which outside of the browser is a concern that largely doesn't exist. Otherwise you

WebASM really only makes sense in the context of embedding untrusted code, which outside of the browser is a concern that largely doesn't exist. Otherwise you are severely crippling yourself for no real gain. You're going to lag the hardware features by years if not decades, you're not going to get arch-specific optimizations as readily, and you're going to have huge startup costs. You're also stuck with sandbox restrictions that you've self-imposed, making it harder to do things that would have otherwise been trivial or needs to be re-invented. You could maybe squint and claim you need a portable IR, but given there's only really 2 ISAs in widespread use (x86 & ARM) does that _really_ matter? Similarly you could claim cross-OS support, but again as there's only _really_ 2 OS's for each target (Windows/Linux for server, Android/iOS for mobile) does that _really_ matter? Critically does it matter to such a degree that you'd rather severely cripple your own app to get it instead of just compiling it 2, 3, or 4 times?

pjmlp 8y ago
That is how IBM i, IBM z, Unisys ClearPath work, how a large majority of Android and Windows apps, some iOS ones (mostly watchOS actually), Garmin devices, SIM cards, Blue Ray, Ricoh copiers, ... If anything the industry is increasingly adopting bytecode as distribution format, kind of returning to the early 60/70's designs with microcoded CPUs just with another approach to the final execution.
tannhaeuser 8y ago
In addition, WASM lacks bindings to the browser environment (or any API for that matter), as its original pitch was improving performance-critical code paths in browser apps; but like you said, it won't be able to reach native ARM ISA speeds nevertheless. At most, in a couple years, it could hope to do what JavaScript has been doing for over a decade. But the browser rendering model and WebGL will just be the same. And then you still have an upstream battle and hope Apple and Google will open their mobile platform APIs to WASM apps, and agree to a common standard which I don't see happening. I can't understand for the life of me what people are projecting into WASM. A new bytecode format for code delivered over the network doesn't solve any problem we're having that isn't solved much better using a native platform API/ABI.
- fbender 8y ago
  I think nobody is saying WASM is better than a „native platform API/ABI“ at solving all problems. It‘s simply a (potentially) viable alternative for scenarios that are way more common than everyone thought at first. And in some situations, it‘s the only solution (e.g. you won‘t get native APIs on the Web).
raphlinus 8y ago
I agree that WASM is only really interested for embedding untrusted code, but am not sure that the browser is the only place where you need that. A good example is Cloudflare's workers, which they talked about at the last SF Rust Meetup. Once you get a _good_ solution to embedding untrusted code, you might find it turns out to be pretty useful.
- kllrnohj 8y ago
  Do you really need embedded code for things like Cloudflare's workers, though? It doesn't seem like it does, seems like each worker can just be its own process using normal process isolation mechanisms. Switching to embedded untrusted code for things like that would actually make a lot of stuff a lot harder - scheduling, resource monitoring, etc... would all need to be re-invented from scratch. Is it really useful to re-invent the kernel in userspace to use a bunch of embedded webasm contexts instead of just a bunch of processes?
  - kentonv 8y ago
    Hi. Cloudflare Workers tech lead here. No, process isolation does not work for us, because it does not scale well enough. The point of Cloudflare Workers is to distribute your code across Cloudflare's entire edge network -- 154 locations and growing -- so that you can respond to requests at the closest location to your end user. We want to put every customer's code in every location, rather than forcing you to choose a handful. Meanwhile, obviously, not every one of our locations is a mega-datacenter. This means we need a way to support extremely large numbers of tenants per machine, with relatively low traffic per tenant (because each tenant's traffic is spread out over the world). We need this to be efficient. This means, we need low memory overhead (to support many tenants per machine), very fast cold-start time (since cold starts are a lot more common in a decentralized scenario), and low overhead to switch between workers (because we're mixing traffic from all our customers everywhere). Using embedded V8 isolates within a single process gives us 10x-1000x better performance on all these metrics than if we gave a whole process to each customer. Relatedly, here's a talk I gave at Heavybit about the neat things you can do when you have fine-grained server compute: https://www.youtube.com/watch?v=YZSvJNBZsxg https://www.youtube.com/watch?v=YZSvJNBZsxg
int_19h 8y ago
For the vast majority of code that runs on either desktop or mobile, the latest and greatest hardware features don't matter, and neither do arch-specific optimizations. Startup costs are trivially solved by an OS-level precompilation and caching mechanism. And we already have sandboxes for apps, even on the desktops (both macOS and Windows store apps). Besides, why can't WebAssembly have a different, less limiting sandbox outside of the web? The real benefit is having a portable bytecode that 1) can accommodate any language out there without constraining their object and memory model, and 2) is guaranteed to be compiled to native code by an optimizing compiler when deployed. Add some basic APIs, and we could have a situation that has heretofore has been enjoyed pretty much only by x86 - the ability to compile code, and run it 30 years later as is.
cm2187 8y ago
In what language can you just “compile 4 times” to target android, iOS, windows, linux, macos and any future platform?
- chrisweekly 8y ago
  JavaScript.
- kllrnohj 8y ago
  Literally all of them? Since you scope creaped to add macos to the list even though it doesn't exist in the server or mobile space you'll need to increase that to 5 compiles instead of 4, though. But C, C++, Rust, Go, D, etc... all support compilation to those platforms. This is a really common thing to do.

pjmlp 8y ago

That is how IBM i, IBM z, Unisys ClearPath work, how a large majority of Android and Windows apps, some iOS ones (mostly watchOS actually), Garmin devices, SIM cards, Blue Ray, Ricoh copiers, ... If anything the industry is increasingly adopting bytecode as distribution format, kind of returning to the early 60/70's designs with microcoded CPUs just with another approach to the final execution.

tannhaeuser 8y ago

In addition, WASM lacks bindings to the browser environment (or any API for that matter), as its original pitch was improving performance-critical code paths in browser apps; but like you said, it won't be able to reach native ARM ISA speeds nevertheless. At most, in a couple years, it could hope to do what JavaScript has been doing for over a decade. But the browser rendering model and WebGL will just be the same. And then you still have an upstream battle and hope Apple and Google will open their mobile platform APIs to WASM apps, and agree to a common standard which I don't see happening. I can't understand for the life of me what people are projecting into WASM. A new bytecode format for code delivered over the network doesn't solve any problem we're having that isn't solved much better using a native platform API/ABI.

fbender 8y ago
I think nobody is saying WASM is better than a „native platform API/ABI“ at solving all problems. It‘s simply a (potentially) viable alternative for scenarios that are way more common than everyone thought at first. And in some situations, it‘s the only solution (e.g. you won‘t get native APIs on the Web).

raphlinus 8y ago

I agree that WASM is only really interested for embedding untrusted code, but am not sure that the browser is the only place where you need that. A good example is Cloudflare's workers, which they talked about at the last SF Rust Meetup. Once you get a _good_ solution to embedding untrusted code, you might find it turns out to be pretty useful.

kllrnohj 8y ago
Do you really need embedded code for things like Cloudflare's workers, though? It doesn't seem like it does, seems like each worker can just be its own process using normal process isolation mechanisms. Switching to embedded untrusted code for things like that would actually make a lot of stuff a lot harder - scheduling, resource monitoring, etc... would all need to be re-invented from scratch. Is it really useful to re-invent the kernel in userspace to use a bunch of embedded webasm contexts instead of just a bunch of processes?
- kentonv 8y ago
  Hi. Cloudflare Workers tech lead here. No, process isolation does not work for us, because it does not scale well enough. The point of Cloudflare Workers is to distribute your code across Cloudflare's entire edge network -- 154 locations and growing -- so that you can respond to requests at the closest location to your end user. We want to put every customer's code in every location, rather than forcing you to choose a handful. Meanwhile, obviously, not every one of our locations is a mega-datacenter. This means we need a way to support extremely large numbers of tenants per machine, with relatively low traffic per tenant (because each tenant's traffic is spread out over the world). We need this to be efficient. This means, we need low memory overhead (to support many tenants per machine), very fast cold-start time (since cold starts are a lot more common in a decentralized scenario), and low overhead to switch between workers (because we're mixing traffic from all our customers everywhere). Using embedded V8 isolates within a single process gives us 10x-1000x better performance on all these metrics than if we gave a whole process to each customer. Relatedly, here's a talk I gave at Heavybit about the neat things you can do when you have fine-grained server compute: https://www.youtube.com/watch?v=YZSvJNBZsxg https://www.youtube.com/watch?v=YZSvJNBZsxg

int_19h 8y ago

For the vast majority of code that runs on either desktop or mobile, the latest and greatest hardware features don't matter, and neither do arch-specific optimizations. Startup costs are trivially solved by an OS-level precompilation and caching mechanism. And we already have sandboxes for apps, even on the desktops (both macOS and Windows store apps). Besides, why can't WebAssembly have a different, less limiting sandbox outside of the web? The real benefit is having a portable bytecode that 1) can accommodate any language out there without constraining their object and memory model, and 2) is guaranteed to be compiled to native code by an optimizing compiler when deployed. Add some basic APIs, and we could have a situation that has heretofore has been enjoyed pretty much only by x86 - the ability to compile code, and run it 30 years later as is.

cm2187 8y ago

In what language can you just “compile 4 times” to target android, iOS, windows, linux, macos and any future platform?

chrisweekly 8y ago
JavaScript.
kllrnohj 8y ago
Literally all of them? Since you scope creaped to add macos to the list even though it doesn't exist in the server or mobile space you'll need to increase that to 5 compiles instead of 4, though. But C, C++, Rust, Go, D, etc... all support compilation to those platforms. This is a really common thing to do.