Hacker News Comments on
Andy Wingo - Channels, Concurrency, and Cores: A new Concurrent ML implementation
Curry On!
·
Youtube
·
86
HN points
·
1
HN comments
- This course is unranked · view top recommended courses
Hacker News Stories and Comments
All the comments and stories posted to Hacker News that reference this video.⬐ a-nikolaevThe speaker's article on the topic: https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml⬐ sctbDiscussions on Andy's related blog posts:⬐ julesHow does this compare to Reagents? If I understand correctly, Reagents are the successor of Concurrent ML.⬐ bjoli⬐ jacinaboxReagents generalise CML, but is also not as opinionated in that it is more a set of building blocks that can be used in many different ways. It gives you more flexibility, but at the cost of having to do a bit more yourself.Reagents are more comparable to STM I would say, even though it is slightly less expressive in some areas, but on the other hand is always lock-free.
⬐ julesApparently I also answered my own question a year ago as a comment on the associated blog post:Reagents do generalise CML. The main difference is that CML only allows you to combine operations with select (op1 OR op2) while Reagents also allow you to combine operations into a transaction (op1 AND op2 for independent operations and op1 THEN op2 for dependent ones). Reagents are lightweight in that the library analyses the combined operation and then figures out an efficient CAS scheme to execute it. Reagents also include some more low level operations, such as CAS as a reagent. -- https://wingolog.org/archives/2017/06/29/a-new-concurrent-ml...
I hope that's correct...
> Reagents are more comparable to STM I would say, even though it is slightly less expressive in some areas, but on the other hand is always lock-free.
What is the difference in expressiveness between STM and Reagents? Is it that STM provides monadic bind, whereas Reagents only provide applicative, i.e. Reagents cannot dynamically decide to update different locations based on values read in the transaction?
⬐ bjoliWell, after having used reagents I have found that for most things so use it to more or less implement CML anyway. I have never been limited by the CML way, but I do appreciate the power that reagents give you.In comparing STM and reagents I will probably just regurgitate what Aaron Turin says in his paper "Reagents: Expressing and Composing Fine-grained Concurrency" which you can find using a short Google. I only seem to be able to copy the Google link, so you will have to Google it yourself.
I 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.⬐ pjmlp⬐ bjoliModula-2 already had co-routines in 1978.Concurrent Pascal had them in 1976.
And there are plenty of other examples gaining digital dust.
⬐ bakul⬐ bjoliConcurrent pascal didn't allow unsafe concurrent access to shared data structures. Go allows safe concurrent access but doesn't stop such access. Its authors encourage people to use channels but this sharing is intrinsic -- one can start a nested function as a concurrent goroutine & it has full concurrent access to its environment. Go tools can check for race conditions but ideally such support should be in the language itself. So in a sense Go is worse than Concurrent Pascal for the main feature it touts!⬐ teamfrizzallows and doesn't stop are the same thing.⬐ kazinatorMaybe OP means "allows safe concurrent access but doesn't stop unsafe concurrent access".⬐ bakulIndeed.Meant to write "Go allows safe concurrent access but doesn't stop unsafe concurrent access to shared data structures"
Thanks & sorry for the confusion.
⬐ espeedAnd that capabilities model is one of the big differences in Pony and was the key to achieving Pony's parallel lock-free provably correct concurrency model.Most lang/system capability models (including Go's) are open from the start -- where anyone can do anything -- and then when designing the lang/system you try to restrict access between some things at some of the time, but this gets messy fast and it's hard to get right and thus it's almost never optimal.
So rather than trying to start with an open model that's inherently flawed by definition, Pony flips the model on its head and begins from the perspective that everything is denied unless specified. You would say Pony has a deny-first capabilities model, which you can see explicitly defined here in Pony's capabilities matrix...
https://soyyomakesgames.wordpress.com/2016/10/10/ponys-capab...
And if you listen to Sylvan's talks, he is emphatic that solving the capabilities problem upfront was key that made everything else possible. All the other cool stuff you hear about in Pony like the provably correct runtime and finally achieving something approaching Hewitt's elusive Actor model that's been theoretically true for 40 years but never fully realized. Well the key to solving that mystery and unlocking the door was to take a new view on the capabilities model and building everything off that from the start.
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.).⬐ cdoxsey⬐ abrookewoodHere's one way:https://play.golang.org/p/9KNkheXHUBrfunc fanin(out chan<- int, ins ...chan int) { switch len(ins) { case 0: case 1: for msg := range ins[0] { out <- msg } case 2: for { var msg int select { case msg = <-ins[0]: case msg = <-ins[1]: } out <- msg } default: go fanin(out, ins[:len(ins)/2]...) go fanin(out, ins[len(ins)/2:]...) } }
You can also use reflect: https://golang.org/pkg/reflect/#Select
Arguably, new styles of programming are making concurrency less important. You won't always need a concurrent language when you can spin up a thousand instances of your function on platforms like AWS Lambda etc.⬐ espeed⬐ YorickPeterseNo, don't think like that. Concurrency is becoming more important, that's just the new reality on the other side of Moore's Law. Concurrency doesn't just happen. Someone has to design the AWS Lambda concurrency model and build the system to scale even if it's not you. And unless the system's design is improving over time and approaching optimal, eventually no one's going to use it because it will cost more than it should so people will move on toward the optimal one. And just like we have multi-layer caching models, distributed means we now have multi-layer concurrency models. Message passing Actors might be optimal between nodes, but within nodes matrix-multiply tensor models running on GPU/TPU accelerators is where optimal's at. And unless you understand it, you won't even be on the map.Not exactly, Erlang has had them for almost three decades.> goroutines are a major innovation upon threads.
⬐ dragonwriter⬐ espeedGoroutines are not Erlang processes; they are similar in that each is multiplexed M:N style onto native threads, but goroutines aren't shared-nothing, and they communicate with channels rather than each process having a mailbox.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
Not 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.
⬐ dmanWhat are you using it for? Is any of the work publicly available?⬐ bjoliI have started using it to do every single task that I would previously use threads for, and for a lot of other things that I would otherwise have done sequentially.Two days ago I made my own very shitty static site generator parallel using fibers.
I have a POC for a irc-like server with proof-of-work to send messages depending on current message throughput. (Not online yet)
I am not really a programmer, so I mostly do stupid things with it. I made my smart home server (written by me, using ZigBee to communicate with devices) scale to thousands of parallel authenticated connections. Just for fun (or at least to be able to say that my WiFi and ZigBee dongle gave up before my own ZigBee controller software did).
I have even used it for fully cooperative multitasking (by setting the "Hz" in guile-fibers to 0).
It is not my favourite talk, but it is the one I almost happy about discovering:Andy Wingo's talk "Channels, Concurrency, and Cores: A new Concurrent ML implementation" https://m.youtube.com/watch?v=7IcI6sl5oBc
Because it made me discover that concurrent programming can actually be nice.