3 ms·

> 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 ap

> 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.

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.