Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
1–10 of 24 posts
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#2Discussions on Andy's related blog posts:
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#3Not only that, but guile just got a 2-4x speedup in the 2.9 branch (what will become guile 3).
It is a really nice scheme implementation and very capable. The stuff the guix people have done is amazing!
Concurrent ML is my favourite way of writing multi threaded parallel programs. It is a bliss! One can say that reagents in multidirectional ocaml is another step downwards in that it in most regards generalises CNL, but in its base form it is not as simple to work with.
Guile fibers is amazing to work with, and has good repl integration. The performance I am able to get out of it is nothing short of amazing.
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#4I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#5I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.
How does go select over N channels where N is not known at compile time these days? I remember the helper API as clumsy and unintuitive. I am sure this has changed since I last used go. Back then (about 2014?) I found go's concurrency model lacking, or at least a little bit too opinionated when compared to CML. Sure, it was possible to work around the limitation, and the extra performance you got from utilising all cores was worth it (parallel CML is a rather new thing, but is getting more common.).
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#6Not only that, but guile just got a 2-4x speedup in the 2.9 branch (what will become guile 3). It is a really nice scheme implementation and very capable. The stuff the guix people have done is amazing! Concurrent ML is my favourite way of writing multi threaded parallel programs. It is a bliss! One can say that reagents in multidirectional ocaml is another step downwards in that it in most regards generalises CNL, b…
What are you using it for? Is any of the work publicly available?
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#7I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.
Modula-2 already had co-routines in 1978.
Concurrent Pascal had them in 1976.
And there are plenty of other examples gaining digital dust.
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#8The speaker's article on the topic: https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#9I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.
Pony's new novel lock-free Actor model is of considerable note. Sylvan (https://github.com/sylvanc) has since joined MSR Cambridge and is working on the distributed model now...
https://github.com/ponylang/ponyc
Re: Channels, Concurrency, Cores: A New Concurrent ML Implementation (2017) [video]
#10I just want to say that I'm so glad people are developing concurrent languages. The day that concurrency became of paramount importance to computing, all of the old languages became obsolete! That's also why we have Go; goroutines are a major innovation upon threads.
How does go select over N channels where N is not known at compile time these days? I remember the helper API as clumsy and unintuitive. I am sure this has changed since I last used go. Back then (about 2014?) I found go's concurrency model lacking, or at least a little bit too opinionated when compared to CML. Sure, it was possible to work around the limitation, and the extra performance you got from utilising all c…
Here's one way:
func fanin(out chanYou can also use reflect: https://golang.org/pkg/reflect/#Select