6 ms·
Can someone explain what this is actually useful for, if you're not a kernel developer? Would people in userland care about anything like this?
by tree_of_item 8y ago
Can someone explain what this is actually useful for, if you're not a kernel developer? Would people in userland care about anything like this?
- IshKebab 8y agoYou can run safely userland code in the kernel context. Makes it faster. Does make Spectre rather more potent thought!
- traverseda 8y agoGary Bernhardt explains it better in this talk: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... But to summarize, jumps between kernal-space and user-space are expensive. Instead of doing that, we can run a well-vetted interpretor in kernal-space, and run "userspace" programs in kernal-space, in the interpretor. This actually isn't slower (or so it is claimed), because a JITed interpretor can be native speed on hot-code paths, and the inefficiencies for most workloads are more than made up for by not having expensive syscalls. So what you end up with is something that is about as fast as normal compiled code for cpu-intensive workloads (maybe faster sometimes), much faster for workloads involving a lot of syscalls, and interpreted languages like python/javascript end up much faster as well, presuming they can take advantage of the efficient JIT implementation. Personally, what most exites me about this technology path, is that it should reduce the cost of interprocess communication to near zero. Combined with a shared object model, and a capabilities system, it could be pretty awesome.
- solidsnack9000 8y agoThe most important applications are likely data processing -- batch and real-time -- and very high performance web applications. These are environments where: * Different applications are typically isolated from one another by being on different machines. * Application and hardware failures are handled with the "let if fail" philosophy, where individual machines are treated as disposable. * Components are written in-house and typically are quite trusted (even if they don't deserve to be). People in "userspace" do, on occasion, care a lot about the overhead of syscalls. Userspace networking -- https://lwn.net/Articles/713918/ https://lwn.net/Articles/713918/ -- is a different approach, where a functionality is moved wholly out of the kernel.