4 ms·
So they are using the same strategy as Erlang (partitioned heaps), with a nice twist of adding hierarchy. That is great, but runs into the next problem with co
by grandinj 5y ago
So they are using the same strategy as Erlang (partitioned heaps), with a nice twist of adding hierarchy.
That is great, but runs into the next problem with concurrent programming - shared data - where, for performance, you absolutely have to share memory between heaps and pass ownership between heaps.
Erlang has specific escape hatches for that, I wonder how that would in a functional language.
- shwestrick 5y agoAuthor here. One of the cool things about the property we're using here---disentanglement---is that it specifically allows for shared data, under only mild restrictions. This allows us, for example, to implement fast libraries which utilize shared mutable state for efficiency under the hood. A good example is our parallel arrays library (https://github.com/shwestrick/sml-parseq https://github.com/shwestrick/sml-parseq), which is "purely functional" in terms of its interface, but not its implementation. It's helpful here to distinguish parallelism from concurrency. Disentanglement naturally emerges in data-race-free parallel programs, which have no concurrency. But certainly, you bring up a good point for programs that are highly concurrent in addition to being highly parallel. There's lots of work already on concurrent functional programming, for example CML (https://en.wikipedia.org/wiki/Concurrent_ML https://en.wikipedia.org/wiki/Concurrent_ML), and we think these ideas could be adapted to work with disentanglement really well.