4 ms·

Don't think of it as optimizing around context switches—think of it as just omitting what you don't need, and losing context-switches as a side benefit. A multi

Don't think of it as optimizing around context switches—think of it as just omitting what you don't need, and losing context-switches as a side benefit. A multi-user OS has a lot of stuff which might not be necessary for a single virtualized service (various security mechanisms, lots of file system niceties, running other services, &c), so writing a unikernel like this allows you to select exactly as much as you need for your particular service. OCaml isn't all that much slower than C++. To use the Programming Language Shootout as a rough esimation[^1], it can even come close to matching C++ in certain programs, and is rarely more than three times as slow. And of course—your type system will catch more errors and your resulting code will be much shorter (and in my opinion, at least, easier to understand.) Finally: the article didn't say "the Linux kernel"—it said "Ubuntu." The kernel itself might be secure and reliable, but a running Linux system is much, much more than just the kernel. And while C can be security-audited, many of the properties that are important to verify in a C program come entirely for free from something like OCaml—e.g., an arbitrary piece of C code might not segfault given certain input, but a given piece of OCaml code definitely won't. So maybe a running Linux system is "secure enough", but a unikernel like this will have a much smaller attack surface and stronger inherent security properties with basically no extra work. Disclaimer: I'm not the original author, I'm just speaking generally. [^1]: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=ocaml&lang2=gpp&data=u64 http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...

paulasmuth 12y ago
> so writing a unikernel like this allows you to select exactly as much as you need for your particular service. I agree this is a big upside of the authors approach. Less dependencies lead to fewer problems caused by external/upstream changes. > OCaml isn't all that much slower than C++. To use the Programming Language Shootout as a rough esimation[^1], it can even come close to matching C++ in certain programs, and is rarely more than three times as slow. I wasn't only referring to raw execution performance but also to GC pauses and GC overhead which I think are the bigger issue. The benchmark you linked tests for compute load so this doesn't really show up. Anecdotal point; in most real world apps I have worked on the GC was a limiting factor. > Finally: the article didn't say, "the Linux kernel"—it said, "Ubuntu." The kernel itself might be secure and reliable, but a running Linux system is much, much more than just the kernel. That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system. > an arbitrary piece of C code might not segfault given certain input, but a given piece of OCaml code definitely won't. This assumes that the OCaml compiler/interpreter and the hardware are free of bugs...
- Guvante 12y ago
  > That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system. With a Unikernel there is nothing else to affect. You are running a virtual machine anyway so even if you kill the kernel you only took down yourself. > This assumes that the OCaml compiler/interpreter and the hardware are free of bugs... They are not free of bugs. For most purposes you can consider everything to have bugs in it. However there is a big difference between a compiler/interpreter bug (which usually just makes your system run differently) and a service bug (which can lead to all kinds of problems).
- avsm 12y ago
  Regarding GC pauses, remember that you already have them if your application stack is written in (Scala,Java,Go,OCaml,Haskell). But you also have other manual memory management going on everywhere! With Mirage, it's all amortised in one consistent, fast GC! To give you a sense of the malloc vs OCaml GC trade off, see http://anil.recoil.org/papers/2007-eurosys-melange.pdf http://anil.recoil.org/papers/2007-eurosys-melange.pdf Malloc and free list management is remarkably complex compared to a fast, simple GC. It would be interesting to build an OCaml runtime in Rust to experiment with these tradeoffs in a more controlled fashion.
hderms 12y ago
Additionally, Linux wasn't as secure as it is now out of starting gates. It's a very effective and well-written piece of software, but there have been high profile bugs and exploits. C code isn't impossible to make safe, but there is an argument to be made that it needs more attention towards safety (and therefore developer time) than a language that makes certain types of bugs impossible. The space shuttle software was written in assembly language, but it damn sure had a ton of people working on it who valued safety (not necessarily security as we know it now) as one of the highest priorities.

paulasmuth 12y ago

> so writing a unikernel like this allows you to select exactly as much as you need for your particular service. I agree this is a big upside of the authors approach. Less dependencies lead to fewer problems caused by external/upstream changes. > OCaml isn't all that much slower than C++. To use the Programming Language Shootout as a rough esimation[^1], it can even come close to matching C++ in certain programs, and is rarely more than three times as slow. I wasn't only referring to raw execution performance but also to GC pauses and GC overhead which I think are the bigger issue. The benchmark you linked tests for compute load so this doesn't really show up. Anecdotal point; in most real world apps I have worked on the GC was a limiting factor. > Finally: the article didn't say, "the Linux kernel"—it said, "Ubuntu." The kernel itself might be secure and reliable, but a running Linux system is much, much more than just the kernel. That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system. > an arbitrary piece of C code might not segfault given certain input, but a given piece of OCaml code definitely won't. This assumes that the OCaml compiler/interpreter and the hardware are free of bugs...

Guvante 12y ago
> That's the beauty of having a kernel though. If one of those userland processes is broken it won't affect the whole system. With a Unikernel there is nothing else to affect. You are running a virtual machine anyway so even if you kill the kernel you only took down yourself. > This assumes that the OCaml compiler/interpreter and the hardware are free of bugs... They are not free of bugs. For most purposes you can consider everything to have bugs in it. However there is a big difference between a compiler/interpreter bug (which usually just makes your system run differently) and a service bug (which can lead to all kinds of problems).
avsm 12y ago
Regarding GC pauses, remember that you already have them if your application stack is written in (Scala,Java,Go,OCaml,Haskell). But you also have other manual memory management going on everywhere! With Mirage, it's all amortised in one consistent, fast GC! To give you a sense of the malloc vs OCaml GC trade off, see http://anil.recoil.org/papers/2007-eurosys-melange.pdf http://anil.recoil.org/papers/2007-eurosys-melange.pdf Malloc and free list management is remarkably complex compared to a fast, simple GC. It would be interesting to build an OCaml runtime in Rust to experiment with these tradeoffs in a more controlled fashion.

hderms 12y ago

Additionally, Linux wasn't as secure as it is now out of starting gates. It's a very effective and well-written piece of software, but there have been high profile bugs and exploits. C code isn't impossible to make safe, but there is an argument to be made that it needs more attention towards safety (and therefore developer time) than a language that makes certain types of bugs impossible. The space shuttle software was written in assembly language, but it damn sure had a ton of people working on it who valued safety (not necessarily security as we know it now) as one of the highest priorities.