virt-v2v VS ocaml-multicore

In virt-v2v we eventually enforced that every module file also has a corresponding interface file: https://github.com/libguestfs/virt-v2v/blob/master/check-mli...

You can look at the project yourself: https://github.com/libguestfs/virt-v2v I've been writing OCaml for 20+ years and C for 40 years.

I develop in OCaml from time to time, and it's pretty practical. Separate compilation, makes small-ish binaries that most people wouldn't know weren't written in C/C++, easily call out to C if you need to. We steer clear of the more complex language features like functors because they confuse most programmers.

Here's an example of one very widely used production application: https://github.com/libguestfs/virt-v2v/tree/master/v2v

XPath is the real killer feature for XML. I don't think it's possible to use it in this particular example, but in the more generally useful cases where you want to pull (eg) all subnodes with key matching a particular string, XPath is great.

Here's it being used in real code (search for "xpath_"):

https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse...

https://github.com/libguestfs/virt-v2v/blob/master/v2v/parse...

1. Domains are the unit of parallelism. A domain is essentially an OS thread with a bunch of extra runtime book-keeping data. You can use Domain.spawn (https://github.com/ocaml-multicore/ocaml-multicore/blob/5.00...) to spawn off a new domain which will run the supplied function and terminate when it finishes. This is heavyweight though, domains are expected to be long-running.

2. Domainslib is the library developed alongside multicore to aid users in exploiting parallelism. It supports nested parallelism and is pretty highly optimised (https://github.com/ocaml-multicore/domainslib/pull/29 for some graphs/numbers). The domainslib repo has some good examples: https://github.com/ocaml-multicore/domainslib/tree/master/te...

3. We've not tested against other forms of parallelism. There isn't anything stopping you exploiting SIMD in addition to parallelism from domains.

4. No, we've not compared performance by OS.

5. No plans for the multicore team to look at accelerator integration at the moment.

For Algebraic Effects and Multicore OCaml specifically, I have this intro saved and they've been publishing regular updates here's October's. They have a paper linked from their repo's README but I don't remember the contents offhand.

Until recently Multicore OCaml was focused on deep handlers. The people working on the formalization of effects (either for program proofs or typed effects) were quite keen to have shallow handler integrated however. Thus, the effect module of the OCaml 5 preview contains both (see https://github.com/ocaml-multicore/ocaml-multicore/blob/5.00...) since September. I fear that non-academic literature has not followed this change (on the academic side, see https://dl.acm.org/doi/10.1145/3434314 for a program proofs point of view).

Yes, it's announcing that the next but one version, 5.0, will support multicore and effect handlers.

For what it's worth you can actually start using Multicore OCaml today, there are installation instructions on the wiki: https://github.com/ocaml-multicore/ocaml-multicore

ocaml-multicore/ocaml-multicore

Could you explain (in simple terms if possible) how the Multicore OCaml achieves a memory model which is much simpler on more efficient than in Java or C (mentioned at https://github.com/ocaml-multicore/ocaml-multicore/wiki)?

Didn't see any mentions of critical sections (mutexes) with C++ examples in the documentation ("Bounding Data Races in Space and Time"). I'm not sure I understand the comparisons the writers are presenting.

There are getting started instructions up on https://github.com/ocaml-multicore/ocaml-multicore