Hacker News Reader

Comment by jezek2 | Hacker News Reader

Such speedup is not plausible at all. It had to be a flawed benchmark relying on some API being very slow in userspace (probably on purpose, not using it the right way). The raw execution speed of WASM can't change much just because it is in a kernel.

View on HN

That's probable, though if we want to give them the benefit of the doubt, it could be a non-optimised benchmark, ie, something that may be written during the average devoper might ordinarily write, rather than hyper-optimised code specifically for that benchmark.

What they had done was wiring kernel level operations, without any of the userspace security checks into the wasmer. Their logic was that given the sandbox of wasmer; what would happen if you removed the sandbox of the OS? And I remember their article was featured in HN for two days or so as well. It was interesting. It wasn't that WASM ran faster than C, it was the API calls. And I keep wondering about an architecture where you have a highly sandboxed universal assembly with some API hardening; a middle ground, and so imagine an app that ran everywhere and was 10~100 times faster. Could be really cool.

Yes, it's not a new idea. See Microsoft Singularity research OS for a more recent example.

You would still have slower than native execution speed, security problems with Spectre attacks (in HW process isolation it's avoided by not having other memory mapped at all, other mitigations exist but they cost a lot of performance).

Syscall speedups affect only specific programs or stupidly written SW like some games that are checking current time many many times per frame.

It's not just syscalls. If you trust all of the running code, you can use a single address space for all applications and even the kernel, which lets you avoid TLB flushes.

Whether that's still a good idea given Spectre is another question.

Reply on news.ycombinator.com