4 ms·

So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downti

by 616c 12y ago

So I have been following this stuff with a lot of interest, but I am not very familiar with Ocaml and have tried looking at Mirage docs with some limited downtime. If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? Does this mean Mirage unikernels handle only one processor/core in Amazon and elsewhere?

krat0sprakhar 12y ago
> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? +1 to this question? Any one experienced enough in OCaml to answer this?
- paulasmuth 12y ago
  One could argue that threading is not strictly necessary to utilize a multicore machine. A lot of applications (think web apps) can be implemented just fine as a single thread and then scaled up by increasing the number of processes (or the number of virtual machines in this case) rather than the number of threads. A lot of popular web frameworks follow this paradigm and I would guess that most application code running "in the cloud" is in fact single threaded.
  - hderms 12y ago
    You'd probably have to move more to a CSP type concurrency versus threads if you were to leverage multicore machines. Erlang doesn't allow individual processes to share memory with each other, but Erlang is undoubtedly a great platform to build apps in that make use of concurrency (depending on use case). Something tells me that the use cases for which one would use Mirage for would be those more likely to use Erlang-type concurrency semantics versus highly multithreaded code using shared memory.
- 616c 12y ago
  Yeah I am familiar with the theory of alternative methods in a general way (CSP, message passing between full or light procs, green threads, etc.) but what is the story with OCaml and Mirage. I am curious because if it is the same as OCaml I am curious how much performance can be eeked out of it without SMP.
bincat 12y ago
I doubt. Here is another approach: http://erlangonxen.org/ http://erlangonxen.org/
avsm 12y ago
Two answers: scaling through structured distributed systems abstractions is a key aim in Mirage. We deliberately want each VM to be predictable, single vCPU and scale via multiple VMs. It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). See our ASPLOS 2013 paper for some simple workloads on this topic. We are building this library to simplify this style of distributed programming: http://openmirage.org/blog/introducing-irmin http://openmirage.org/blog/introducing-irmin Other answer: we will be talking about our multicore ocaml implementation at ICFP in September. I still don't want to see it in Mirage though :-)
- wmf 12y ago
  It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). Are you assuming that vCPUs are scheduled or pinned? It wasn't clear from skimming the paper. I would agree that two levels of scheduling are bad but if that's the problem pinning should fix it. The situation may change if you eliminate the hypervisor. My intuition is that a single multi-threaded process with work-stealing will be faster than separate processes or VMs due to better load balance (see PX vs. 1X dynos) and faster inter-thread communication (if your app has any communication).
  - avsm 12y ago
    If you eliminate the hypervisor, you don't have vCPUs at all, so I'm not sure how this is a useful comparison. The question of IPC performance is an interesting one. We've been building up a database of open source results that show wildly diverging results on different architectures. Surf through http://fable.io http://fable.io for it, or read this work in progress: http://anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.pdf http://anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.... http://anil.recoil.org/talks/fosdem-io-2012.pdf http://anil.recoil.org/talks/fosdem-io-2012.pdf (fosdem slides) The TL;DR of these numbers is that it's very hard to make firm performance hypotheses about IPC across architectures, NUMA and hypervisors.
- 12y ago

by 616c 12y ago

krat0sprakhar 12y ago

> If Ocaml can only handle one core and does not do SMP, how does it do in the cloud? +1 to this question? Any one experienced enough in OCaml to answer this?

paulasmuth 12y ago
One could argue that threading is not strictly necessary to utilize a multicore machine. A lot of applications (think web apps) can be implemented just fine as a single thread and then scaled up by increasing the number of processes (or the number of virtual machines in this case) rather than the number of threads. A lot of popular web frameworks follow this paradigm and I would guess that most application code running "in the cloud" is in fact single threaded.
- hderms 12y ago
  You'd probably have to move more to a CSP type concurrency versus threads if you were to leverage multicore machines. Erlang doesn't allow individual processes to share memory with each other, but Erlang is undoubtedly a great platform to build apps in that make use of concurrency (depending on use case). Something tells me that the use cases for which one would use Mirage for would be those more likely to use Erlang-type concurrency semantics versus highly multithreaded code using shared memory.
616c 12y ago
Yeah I am familiar with the theory of alternative methods in a general way (CSP, message passing between full or light procs, green threads, etc.) but what is the story with OCaml and Mirage. I am curious because if it is the same as OCaml I am curious how much performance can be eeked out of it without SMP.

bincat 12y ago

I doubt. Here is another approach: http://erlangonxen.org/ http://erlangonxen.org/

avsm 12y ago

Two answers: scaling through structured distributed systems abstractions is a key aim in Mirage. We deliberately want each VM to be predictable, single vCPU and scale via multiple VMs. It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). See our ASPLOS 2013 paper for some simple workloads on this topic. We are building this library to simplify this style of distributed programming: http://openmirage.org/blog/introducing-irmin http://openmirage.org/blog/introducing-irmin Other answer: we will be talking about our multicore ocaml implementation at ICFP in September. I still don't want to see it in Mirage though :-)

wmf 12y ago
It's far more efficient to scale via lots of small VMs that are scheduled independently than having a few big multicpu VMs (which have a lot of overhead since the CPU sync also needs to be virtualised). Are you assuming that vCPUs are scheduled or pinned? It wasn't clear from skimming the paper. I would agree that two levels of scheduling are bad but if that's the problem pinning should fix it. The situation may change if you eliminate the hypervisor. My intuition is that a single multi-threaded process with work-stealing will be faster than separate processes or VMs due to better load balance (see PX vs. 1X dynos) and faster inter-thread communication (if your app has any communication).
- avsm 12y ago
  If you eliminate the hypervisor, you don't have vCPUs at all, so I'm not sure how this is a useful comparison. The question of IPC performance is an interesting one. We've been building up a database of open source results that show wildly diverging results on different architectures. Surf through http://fable.io http://fable.io for it, or read this work in progress: http://anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.pdf http://anil.recoil.org/papers/drafts/2012-usenix-ipc-draft1.... http://anil.recoil.org/talks/fosdem-io-2012.pdf http://anil.recoil.org/talks/fosdem-io-2012.pdf (fosdem slides) The TL;DR of these numbers is that it's very hard to make firm performance hypotheses about IPC across architectures, NUMA and hypervisors.
12y ago