Multicore OCaml: March 2020 update | Hacker News Reader

Multicore OCaml: March 2020 update

discuss.ocaml.org

124 pointssadiq37 comments

I've been hacking on the OCaml multicore GC recently and am happy to answer questions anyone has.

It's been really nice to see these updates from the multicore team. I'm looking forward to the systhread support using the Domain/Atomic modules. Being able to build recent versions of dune is something i'm looking forward to. That'll make it really easy to try (and hopefully contribute/port examples and benchmarks) to the multicore project.

When is it expected to be released?

(Speaking personally and not for OCaml Labs who are driving most of the multicore work at the moment)

You can use multicore right now: https://github.com/ocaml-multicore/ocaml-multicore though it's currently at an older version of OCaml, 4.06.1.

There's work currently going on to rebase on to OCaml trunk, show-stopping bugs aside there should be a more up to date version of multicore in the next couple of months - then the focus will be on upstreaming.

Hard to give a reasonable timeframe for release because that's going to depend a lot on how things get upstream.

As asked before:

In what form will Multicore OCaml support the, you know, multicore stuff? Will it be native OS threads? CSP? Actors? Something else?

(I work on Multicore OCaml)

Multicore OCaml separates the notion of concurrency (overlapped execution) and parallelism (simultaneous execution). You can have one without the other but also have both. The main principle that we're going for is that the compiler should expose just enough support for concurrency and parallelism such that interesting features can live outside the compiler as libraries. This permits the library evolution not to be tied with the language evolution but also permits diversity of libraries beyond what the language developers can aim to achieve. That said, we will build and maintain a few core libraries for concurrency and parallelism.

For concurrency, Multicore OCaml exposes effect handlers [1,2,3] which allows you to build generators, async/await, coroutines, etc as library functions (as opposed to primitives natively supported by the compiler). For example, have a look at aeio [4] which permits the construction of scalable asynchronous I/O in direct-style (no callbacks). aeio is also discussed in [1]. We also plan to extend Lwt to support parallelism.

For parallelism, the compiler exposes Domains, which are a wrapper over OS-threads [5]. Domains expose a low-level API that is not suitable for end user consumption. On top of domains, we support channels with bounded buffers [6] (similar to channels in Go, Mvars in GHC Haskell) as well as software transactional memory (STM) that supports shared memory and message passing concurrency and which can take advantage of hardware transactional memory [7].

[1] Concurrent System Programming with Effect Handlers: http://kcsrk.info/papers/system_effects_feb_18.pdf

[2] CUFP effects tutorial: https://github.com/ocamllabs/ocaml-effects-tutorial

[3] Effects Examples: https://github.com/kayceesrk/effects-examples

[4] Aeio: Asynchronous Effect-based IO https://github.com/kayceesrk/ocaml-aeio

[5] Domains: https://github.com/ocaml-multicore/ocaml-multicore/blob/para...

[6] domainslib: https://github.com/ocaml-multicore/domainslib

[7] Reagents: https://github.com/ocaml-multicore/reagents

Thank you for the extremely informative answer! It was very helpful.

Another question, if you allow me:

Will you provide preemptive scheduling primitives? Or will they be possible through the more low-level interface you described?

IMO preemptive scheduling is something that's very necessary nowadays, especially with the explosion of CPU core count.

I am not sure I understand the suggestion that preemptive scheduling is important with the explosion of CPU core count. You may need preemptive scheduling even on a single core if your application expects some fairness of scheduling guarantees. Am I missing something?

We can do preemptive scheduling of user-level threads by registering a timer interrupt with the OS and preempting the currently running user-level thread in favor of another one. This is up to the individual libraries to implement. These issues are discussed in [1] Sec 4.3.

No, you're not missing anything -- I was just saying that it would be a shame if people still can't code preemptively scheduled parallel apps when the average home gaming machine is going to have 16 cores soon and that many devs (me included) are looking to buy a 32/64-core workstation. Nothing else. :)

Really exciting that preemption is possible. Thanks for your insights!

I'm very excited about this because it means ReasonML will be able to take advantage of multi cores for server apps :)

I don't understand the Reason hype when F# / Fable already offers this

As an outsider. F# seems not to get the full blessing. ReasonML is a big thing at Facebook. F# kind of keeps you on the Microsoft stack. Reason has both OCaml based native and JS based interpreted. Reason integrates very well with JS-land. React bindings are maintained by FB itself. Bit-by-bit transitions from JS to Reason are feasible.

Fable, I had to take a look again, but it seems a lot more mature then I remember it was a few years back.

To be honest, ReasonML doesn't seem to have not even half of the community than F# has, nor the IDE tooling for that matter.

Reason is new. F# is not

It thought it was supposed to be a big thing.

I don't know why someone would think that, Reason is actually pretty niche ;-)

Of course, I would love to see it go mainstream, but realistically speaking that will need to happen slowly.

Would say that keeping you on the Microsoft Stack vs the ReasonML/OCAml stack would be more often an asset than a liability especially for most corporations? The .NET Core stack has a better story than OCAml in terms of popularity, library ecosystem, tooling (VS Code/Rider/VS), technology/cross-platform support and general adoption from what I can see. Fable these days is not too bad either from the guide I recently saw online in building applications with it although haven't tried it myself (https://zaid-ajaj.github.io/the-elmish-book/#/).

Companies (like banks, enterprises) still often demand, especially for backends, specific language/runtimes and that tech often translates to Java/JVM or C#/.NET. It is getting to be less important, but we definitely encounter it a lot still and you really can suggest there that you ship something built with ‘ReasonML’ (what is a ‘reasonmul?’) (or ocaml); F#/Scala/Clojure you can get away with especially if you ship closed source (which is still also quite normal in those environments).

From what I've heard a lot of specialized finance applications run OCaml/Haskell/etc. because of the extreme need for safe and reliable code while also preserving performance.

I think 'a lot' is maybe a bit an exaggeration; also, besides maybe Jane Street, it is usually only a small portion of the IT department. But I love to hear more as I am in finance (only encountering Java/.NET basically).

Well for example, one of the most interesting applications of OCaml in finance (well, fintech) is implemented in OCaml and open source: https://gitlab.com/tezos/tezos

Then there's Bloomberg: https://ocaml.org/learn/companies.html

> Bloomberg employs OCaml in a advanced financial derivatives risk management application

Press release from Bloomberg announcing BuckleScript: https://www.bloomberg.com/company/press/open-source-at-bloom...

> We are not currently using BuckleScript on the Terminal, but stay tuned…

This seems to suggest that they were looking at programming Bloomberg terminal applications in BuckleScript, compiled to JavaScript, at least at one point.

There's also LexiFi: https://www.quora.com/Is-the-OCaml-language-used-in-quantita...

I think if you go looking, it's not hard to find OCaml in finance in certain niches.

I looked at the FAQ recently and it says for server side one should compile to JS rather than compiling to native:

https://reasonml.github.io/docs/en/faq

My main interest in reasonml was writing native code. Looks like it will take some time to get to the same level as the JS backend?

Yes, it will, especially in terms of ecosystem and integrations with various other technologies in your stack. But in the meantime I would recommend experimenting with it just because when you hit the sweet spot, it can be very productive. One option is a framework I'm working on: https://github.com/yawaramin/re-web/

F# is not the same thing. It's missing some of the best features of OCaml, e.g. the module system. And no, the object stuff they put into it is not a suitable replacement.

Happy Fable user here.

I think it´s easy to find some feature of a language (such as modules) and claim that every language without it is not viable. You could make the same claim about OCaml not having some of F#s best features, such as operator overloading, inline and computation expressions. But this misses the point. If you´re writing a functional-first web application, then the F# solution and the ReasonML solutions are going to look very similar.

Regarding server run-times and Microsoft lock-in, this is no longer an issue. DotNET Core is open-source and cross-platform. You can also use Fable to compile F# code for Node.

I'm not claiming F# is not viable without the module system, I'm saying F# is not a drop-in replacement for OCaml. There are good reasons people might prefer OCaml. I that that's a reasonable response to this comment:

> I don't understand the Reason hype when F# / Fable already offers this

My only point is that there are good reasons people would prefer ReasonML/OCaml over F#. I never claimed there were no reasons other people might prefer F#.

> DotNET Core is open-source and cross-platform.

The only open-source debugger available for .Net Core is a poorly implemented hack by Samsung, because the vendor-provided debugger was never open-sourced.

https://blog.lextudio.com/the-rough-history-of-net-core-debu...

WHat do you mean by reasonml for server apps? If you mean running js(output of bucklescript) then no it will likely not benefit node users.

ReasonML can target native platforms transparently by using the OCaml compiler toolchain. dune (OCaml build tool) supports ReasonML out of the box.

Checkout reason-native. It directly compiles to native.

You can compile to native and use the whole OCaml ecosystem over there (in stead of the NPM ecosystem when doing client-side or Node-based-server-side) to write your apps.

For instance this fast OCaml http server: https://github.com/inhabitedtype/httpaf

And you can even share types between client and server :)

What's the point of using a different syntax if you are going to be interacting,reading,fixing code in ocaml syntax?

ReasonML is just a different syntax that compiles to the OCaml AST format. If you're writing in ReasonML you'll be interacting, reading and fixing code in ReasonML.

There's even a browser extension which converts OCaml syntax to ReasonML and vice versa in docs.

I was going to ask; I read some discussions on r/reasonml and seems some people prefer the ocaml symtax and some the reason syntax, but both can compile on both on both sides as far as I understood.

Lower barrier to entry. Facebook is not pushing its own next JavaScript.

They lost the Flow-TypeScript battle. And they learned, they wanted even more typesafety I guess.

Since TypeScript also compiles to JS, bringing "something a little less like JS, but a lot more safe" to the table seemed a better idea that pushing "unfamiliar syntax, but heay, it compiles to JS"

Flow and ReasonML are started by completely different people/teams inside the company. From what I heard, Facebook the organization does not care that much about OSS, and software devs have to work really hard to convince to spend company time to maintain an OSS software.

If there is any battle, I predict will probably be between Flow and Reason inside the Facebook org because of competing solutions.

https://news.ycombinator.com/item?id=22443428

Reply on news.ycombinator.com