Multicore, Async, and Lwt

multicore
lwt
async

#1

I am curious, when OCaml multicore is finished and merged mainstream, will programs written with Async and Lwt (or similar) libraries become multithreaded automatically? Will it require major changes in Lwt and Async libraries? Or is it totally impossible and will require rewriting programs themselves?


#2

It will require rewriting programs. Right now, Async programs at least rely on the fact that they can mutate state in a region between binds without fear of interruption. This would simply not be true if the Async scheduler automatically just scheduled jobs on different cores.

We’ve thought a bit about this; maybe you’d have one Async scheduler per core, and have ways of shipping jobs between them explicitly? But no auto-parallelization is likely.

y


#3

We’re currently designing an entirely new multicore IO library based on effects, that should support high-performance direct-style I/O. I anticipate (subject to the emerging design) that there will be some manual migration path between this library and existing monadic concurrency libraries. But nothing that is automatic, as it requires careful understanding of the underlying concurrency semantics of both the new implementation and the existing libraries.


#4

I can probably write an auto parallelizing compiler for this. At least, it’d be nice to do some basic profiling to find the hot blocks, and try to unroll loops, etc. Like some basic passes of an auto parallelizing compiler. The hard part is the memory distribution stuff, that’s a little difficult, I didn’t have a great solution to that. But it can probably be solved by a combinatorial optimization model as usual.


#5

I can probably write an auto parallelizing compiler for this.

:laughing: Famous last words.


#6

Haha yeah, I was thinking I should have said I wouldn’t do it for free, though. :stuck_out_tongue: :joy:


#7

More seriously, I think the advances are really exciting here, I would love to try an explicit parallel programming alternative to Haskell for multicore programming. It’s unfortunate that some semantics will be broken but it sounds like that’s a necessary evil. Multicore reagents, algebraic effects, concurrency are all state of the art approaches to functional explicit multicore programming. I was worried how shared memory would be used, but now that I can see it takes very short code to write common multi-threaded programming idioms, I’m quite pleased. It’s a pretty comprehensive solution, possibly better than typical imperative API’s, because this is just awesomely succinct.