2 ms·
>"OSv has been designed to run unmodified x86-64 Linux binaries as is , which effectively makes it a Linux binary compatible unikernel (for more details about
by peter_d_sherman 6y ago
>"OSv has been designed to
run unmodified x86-64 Linux binaries as is
, which effectively makes it a Linux binary compatible unikernel (for more details about Linux ABI compatibility please read this doc). In particular OSv can run many managed language runtimes including JVM, Python 2 and 3, Node.JS, Ruby, Erlang, and applications built on top of those runtimes. It can also run applications written in languages compiling directly to native machine code like C, C++, Golang and Rust as well as native images produced by GraalVM and WebAssembly/Wasmer.
OSv can boot as fast as ~5 ms on Firecracker using as low as 15 MB of memory.
OSv can run on many hypervisors including QEMU/KVM, Firecracker, Xen, VMWare, VirtualBox and Hyperkit as well as open clouds like AWS EC2, GCE and OpenStack."
Related: http://seastar.io/futures-promises http://seastar.io/futures-promises
>"Paradigms for parallellization
Solutions for coordinating work across multiple cores are many. Some are highly programmer-friendly and enable development of software that works exactly if it were running on a single core. For example the classic Unix process model is designed to keep each process in total isolation and relies on kernel code to maintain a separate virtual memory space per process. Unfortunately this increases the overhead at the OS level.
Software development challenges
[...]
Hardware has changed to the point where the assumptions originally made on small numbers of CPU cores are no longer valid.
Processes are extremely self-contained but have high overhead.
Threads impose additional coordination costs on both the programmer and the application infrastructure, and are notoriously difficult to debug.
Pure event-driven programming can result in codebases that are difficult to test and extend."
- ttul 6y agoEffectively, event-driven programming puts the task of sorting out process scheduling into the hands of the developer, rather than the OS, which would otherwise have to guess at the best scheduling approach. Yes, there are also speed advantages from losing the context switch overhead, but fundamentally, I believe it is the programmer-controlled scheduling that makes event driven apps faster, all other things being held equal.