4 ms·

This sounds like an awesome and fun project to hack on! However, optimizing around context switches and task preemptions is something you would usually do if y

This sounds like an awesome and fun project to hack on! However, optimizing around context switches and task preemptions is something you would usually do if your application is actually bound by IO/context switching, is extremely latency sensitive or when you are trying to squeeze the last bits of performance out of a machine. Why did you choose to build such a microoptimized system in a garbage collected language? Doesn't this defeat the purpose of the whole exercise? I feel the need for more powerful types and built-in/standardized exception handling too, but since performance seems to be one of your major goals, wouldn't something like C++ be a better fit here? You'd get proper error handling and a good type system (with some tradeoffs) without a significant performance penalty. On a sidenote, I agree that code written in a functional language with a strong type system tends to be easier to get right than bare C, but this doesn't imply that all low-level code is bug ridden and unsafe. In fact the linux kernel is one of the most stable and reliable pieces of software I've had the pleasure to work with so far. Suggesting there is a problem with the linux kernel because it contains "a large amount of C code in security-critical places" seems a bit dishonest.

andolanra 12y ago
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.
baruch 12y ago
OSv does something similar to Mirage it seems and is written in C++. They also can run different languages, I believe I saw lua support and they commercially target Java too.
lucian1900 12y ago
> You'd get proper error handling and a good type system Except you wouldn't, which is a major reason to not use C++.

andolanra 12y ago

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.

baruch 12y ago

OSv does something similar to Mirage it seems and is written in C++. They also can run different languages, I believe I saw lua support and they commercially target Java too.

lucian1900 12y ago

> You'd get proper error handling and a good type system Except you wouldn't, which is a major reason to not use C++.