
Multicore OCaml: Feb 2020 update - sadiq
https://discuss.ocaml.org/t/multicore-ocaml-feb-2020-update/5227
======
pdimitar
I'll say it again every time OCaml is mentioned here: there are programmers
who are eagerly awaiting for it to become more friendly to the modern hardware
realities and then they'll use it a lot. Like myself.

(I am mainly waiting for multicore but SIMD/AVX would be nice as well.
Transparent parallelization of code without the programmer doing anything
about it except supplying a compilation flag would be a game-changer but eh,
we can dream right? After all, pure functions can be detected part of the time
so I don't see why not.)

I get the vibe that the current community that's driving it forward is small,
dedicated and overworked. Sad to hear that but rest assured that the community
will grow once OCaml has multicore support. People will want to contribute
once they can suddenly replace their Python or Go codebases with OCaml.

(I'd probably also ask to throw away the C strings and only leave the UTF-8
ones in but I am aware that the OCaml developers are very committed to
backwards compatibility so likely not going to happen.)

Great work and progress! Keep it up! <3

~~~
Ono-Sendai
You may be interested in our functional programming language Winter. It does
auto-parallelisation (WIP) and auto-vectorisation:
[http://forwardscattering.org/post/22](http://forwardscattering.org/post/22)

It's not open sourced yet but will be soonish.

~~~
pdimitar
Really cute. :) Liked the article.

That being said, I'm not looking to get back to C++.

Your work is interesting though. I'd like to see things like these upstreamed
in Rust.

------
abacate
Algebraic effects are going to put OCaml on a next level in terms of
expressivity, abstraction and decoupling capabilities of separate tasks. It
would be like going from a type system like C, with only concrete types, to
parametric polymorphism and/or generics.

Multicore is a very nice addition, but the fact that it is going to be coupled
with an effect system is a game changer for the language as a whole.

~~~
rixed
I, for one, would gladly trade threaded GC and unchecked effects for checked
exceptions... Unless there is a way to implement some kind of poor man checked
exceptions with unchecked effects?

~~~
ameixaseca
Please see [1]. Around 28:45 the talk moves to effect types. At around 29:25
the proposed mechanism (with throw) is literally described as "checked
exceptions".

AFAIK, this is all part of the roadmap.

[1] [https://www.janestreet.com/tech-talks/effective-
programming/](https://www.janestreet.com/tech-talks/effective-programming/)

~~~
rixed
Yes thank you, exactly what I was looking for.

------
eatonphil
Good to get an update on multicore. On the other side of the pond, parallel
MLton [0] is making solid progress. And Poly/ML [1] has had pthreads for a
while.

[0] [https://github.com/MPLLang/mpl](https://github.com/MPLLang/mpl)

[1]
[https://www.polyml.org/documentation/Reference/Threads.html](https://www.polyml.org/documentation/Reference/Threads.html)

------
msvan
Languages like Haskell and Go already have multicore GCs. How does OCaml's
multicore GC compare? Is the work taking a long time because it is doing
something brand new in the design space, or is it simply hard to integrate it
with a mature language that was designed to be single core?

~~~
sadiq
Disclaimer: I don't speak for OCaml or OCaml Labs but I am a contributor to
multicore.

It is indeed that it is hard to retrofit parallelism on to an existing
language while trying to retain backwards compatibility _and_ performance.

Backwards compatibility is tricky because there's lots of C code using the C
API.

Performance is hard because OCaml users are used to well performing code, with
low and predictable pause times from the GC (<10ms).

The community is small and it seems like there wasn't appetite for maintaining
two distinct runtimes with very different performance characteristics.

The current implementation for multicore GC ([https://github.com/ocaml-
multicore/ocaml-multicore](https://github.com/ocaml-multicore/ocaml-
multicore)) is reasonably close to upstream in performance on single threaded
code and yet will scale up to multiple threads. It requires a change to the C
API though.

There's a modified multicore GC ([https://github.com/ctk21/ocaml-
multicore/tree/stw_minor_gc](https://github.com/ctk21/ocaml-
multicore/tree/stw_minor_gc)) that doesn't require the C API change and we're
currently writing up a paper that contrasts the two wit a fairly substantial
amount of benchmarking
([https://github.com/ocamllabs/sandmark](https://github.com/ocamllabs/sandmark)).

Happy to answer any questions.

~~~
throwaway894345
> Performance is hard because OCaml users are used to well performing code,
> with low and predictable pause times from the GC (<10ms).

I would expect that low pause times are easy enough (or relatively easy
considering the difficult domain of GC optimization), but keeping the
allocations cheap is (one of) the key constraints, no?

~~~
sadiq
Yes, it's very easy to make pause times low if you're willing to make
allocation expensive - it's all trade-offs.

In multicore's case it's about keeping low pause times while also keeping
allocation cheap _and_ maintaining throughput.

~~~
chrisseaton
Why would _allocation_ become more expensive in parallel? Surely you’re
allocating in thread-local space? It’s like two machine instructions. Where
does the extra overhead come from?

~~~
throwaway894345
If you want conventional shared memory parallelism, then your allocations
can't assume thread-locality.

~~~
chrisseaton
> If you want conventional shared memory parallelism, then your allocations
> can't assume thread-locality.

I don't really understand why not. Can you expand on it? Doesn't the JVM for
example do thread-local allocations in a conventional shared-memory parallel
environment?

~~~
throwaway894345
I was mistaken; wasn't thinking clearly as I responded. JVM can get away with
this because it's generational/moving; bump allocator works in the young
generation and then objects are subsequently moved. Generational/moving is
tricky, especially with C APIs (if the GC moves an object that C has a pointer
to, the C code dereferencing the pointer will find potentially garbage data)
and I believe they make it difficult to get good STW times, but at this point
I'm pretty well out of my depth.

------
sideeffffect
Could somebody, who's familiar with both worlds, please compare OCaml's
Multicore, Algebraic effects, Reagents with Scala's Monix or ZIO?

I'm familiar with the latter, but would love to learn more about OCaml.

------
risk2030
I created an account just to ask, what is the fetish and obsession with OCaml
and functional stuff on here? Does anyone actually write it (besides Erlang)?

OCaml specifically is such an obscure language you'd have a hard time
explaining it to most people who are software engineers.

Who cares?

~~~
wk_end
Facebook uses Ocaml in the form of Reason, they're a pretty big deal. I think
they also use Haskell?

Lots of financial companies, including some serious heavy-hitters like
Bloomberg, use functional languages like Haskell and Ocaml. I suppose the
blockchain folks are pretty enamoured with it too.

Plenty of big companies like Twitter use Scala, which is plenty functional.

Even on the front-end side: JavaScript was directly inspired by Scheme;
TypeScript was hugely inspired by languages like Ocaml and Haskell; React and
Redux's inspirations fall directly out of the functional programming
community.

Rust, out of Mozilla, is also a descendent of the functional programming
world; its compiler was originally written in Ocaml.

Just the other day there was a conversation on here about type-system enforced
optionals. Almost every "modern" language has grown these in the past decade,
often including monadic combinators to help minimize boilerplate. All of this
comes from what ML and Haskell were doing as many as 30 years ago.

Speaking of monadic combinators: these are also frequently used in modern
languages with async libraries to avoid what the JS community termed "callback
hell".

TBH if you've developed software in the past ten years, it's unlikely you
haven't been hugely affected by what the FP community has been doing, and it's
not impossible that watching what they're doing now give you a glimpse of
where mainstream programming will be a decade or more down the line.

~~~
terminaljunkid
> "TBH if you've developed software in the past ten years, it's unlikely you
> haven't been hugely affected by what the FP community has been doing."

Apart from HN / reddit bubble, not many people know about FP, and not to imply
that's their fault. FP is still weird, difficult for mere mortals, and ivory
tower elitism is holding some of its useful ideas back.

~~~
sideeffffect
people are doing FP, or using ideas originating in FP without even knowing it:

* Java/C# generics

* sealed interfaces and record classes

* pattern matching

* first-class functions with closures

* even type system itself (eg Python is gaining a type system)

* ...

The world of programming languages is converging, no matter how slowly,
towards ML

[https://www.cs.cmu.edu/~rwh/talks/mlw13.pdf](https://www.cs.cmu.edu/~rwh/talks/mlw13.pdf)

~~~
terminaljunkid
Half of those things aren't even specific to FP. And I bet most people don't
even use pattern matching outside HN / reddit bubble, not to say it isn't
cool.

