Handmade Network»Fishbowls»Approaches to parallel programming

Approaches to parallel programming

A discussion of many aspects of parallelism and concurrency in programming, and the pros and cons of different programming methodologies.

This is a fishbowl: a panel conversation held on the Handmade Network Discord where a select few participants discuss a topic with depth and nuance. We host them every two months, so if you want to catch the next one, join the Discord!
Avatar
jfs Nov 19, 2020 04:12 AM
Topic: Approaches to parallel programming (edited)
Avatar
bumbread Nov 19, 2020 04:15 AM
hello there
Avatar
gingerBill Nov 19, 2020 04:16 AM
Hellope!
Avatar
jfs Nov 19, 2020 04:16 AM
Now that the topic is "Parallel programming", what is that anyway? There is this distinction of Parallelism vs Concurrency, popularized maybe also by Rob Pike: https://www.youtube.com/watch?v=oV9rvDllKEg
04:17
But I can never remember which is which, and it seems like not everybody makes that precise distinction
Avatar
jfs Nov 19, 2020 04:20 AM
maybe another interesting distinction as a base for discussion, I found this yesterday: https://www.drdobbs.com/parallel/the-pillars-of-concurrency/200001985?pgno=2
Avatar
Wayward Nov 19, 2020 04:20 AM
according to Pike, concurrency is handling lots of things at once, whereas parallelism is doing alot of things at once
Avatar
jfs Nov 19, 2020 04:23 AM
I'm having trouble understanding that. The way I remember it is that one is about authoring code as independent "trains of thought", the other is actually running code on multiple physical cores. But not quite sure about that
Avatar
Wayward Nov 19, 2020 04:24 AM
responsiveness versus throughput? @jfs
04:26
do we have anyone in the fishbowl at all who's been playing around with parallel programming at all or are we just a big group of beginners?
Avatar
bumbread Nov 19, 2020 04:26 AM
isn't
04:27
concurrency == breaking program into tasks that are independent from each other (threads baically)
04:27
parallelism == physically running few tasks on different cpu cores
πŸ‘ 2
Avatar
jfs Nov 19, 2020 04:30 AM
If you look at "the three columns of concurrency" that I linked above, I'm mostly interested in the responsiveness pillar right now. But to make that not a pain to develop (e.g. by create a separate OS thread for each task), shared data locks (mutexes) are definitely needed
04:31
So, assuming that we're talking about both concurrency and parallelism here. Because one isn't very meaningful without the other, right?
Avatar
Wayward Nov 19, 2020 04:32 AM
i thought parallelism was more of the umbrella term given how computer hardware have developed during the last 25 years
Avatar
jfs Nov 19, 2020 04:32 AM
let's go with that then πŸ™‚
04:34
A realization that lead me into being interested in this topic recently has been how even a single machine is a concurrent and multithreaded thing. Not only do machines have multiple CPU cores, they also have a separate graphics processing unit, and all sort of other things that (for example) communicate through interrupts. It gets more pronounced of course when adding networking...
04:34
I can't really do a plain fgets() or fread() anymore, it seems so wrong to me when I'm doing e.g. GUI on the same thread (edited)
04:35
The human interacting with the GUI is like a completely separate thread as well!
Avatar
Wayward Nov 19, 2020 04:37 AM
i'm more curious about the massively parallel part of the discussion, maximizing throughput and thereby optimizing for speed (running a single big task on multiple cpu threads to optimize for time)
Avatar
jfs Nov 19, 2020 04:38 AM
the "embarassingly parallel" thing
Avatar
Wayward Nov 19, 2020 04:41 AM
yeah, monte carlo is a good example of that
04:47
@Vegard @NWDD the fishbowl has started
Avatar
NWDD Nov 19, 2020 04:48 AM
hello everyone (and thanks for the notification) (edited)
Avatar
Wayward Nov 19, 2020 04:48 AM
do we have anyone who's played around with threads and parallelism here?
πŸ‘‹ 2
Avatar
jfs Nov 19, 2020 04:49 AM
pinging you as well @gingerBill @AsafGartner
Avatar
gingerBill Nov 19, 2020 04:51 AM
Hello
blobwave 1
Avatar
gingerBill Nov 19, 2020 04:52 AM
Distinguishing between Parallelism and Concurrency is extremely important to do. They are orthogonal concepts.
πŸ‘ 1
Avatar
gingerBill Nov 19, 2020 04:52 AM
Rob Pike's distinction is a good one.
Avatar
Vegard Nov 19, 2020 04:52 AM
so @bumbread is right; concurrency is basically the go/node idea where you can have lots of "things" (threads, green threads, coroutines, goroutines, ...) in-flight at the same time, but you can still do it all on a single core if that's all you have. and parallelism is more when things run truly in parallel (on different cores).
Avatar
bumbread Nov 19, 2020 04:53 AM
well maybe let's not worry about definitions for now
Avatar
gingerBill Nov 19, 2020 04:54 AM
Concurrency is about dealing with lots of things at once. Parallelism is about doing loads of things at once.
πŸ‘Œ 1
Avatar
jfs Nov 19, 2020 04:54 AM
When does this distinction matter in practice? Except for performance, is it super important on how many cores (1 or many) I'm running my N concurrent threads?
Avatar
bumbread Nov 19, 2020 04:54 AM
it's hard to say what dealing means (edited)
04:55
or is it really happening at once?
Avatar
NWDD Nov 19, 2020 04:55 AM
concurrency doesn't need thread-safety (to start with a difference that matters in practice) (edited)
Avatar
gingerBill Nov 19, 2020 04:55 AM
In programming: Concurrency is the composition of independently executing processes. Parallelism is the simultaneous execution of (possibly related) computations.
Avatar
bumbread Nov 19, 2020 04:55 AM
well ok
Avatar
gingerBill Nov 19, 2020 04:57 AM
Purely parallel problems could be classed as idempotent. @jfs's link to "Embarrassingly Parallel" is the essence of this.
Avatar
jfs Nov 19, 2020 04:58 AM
why does concurrency not need thread-safety @Vegard? What is that thread-safety here, precisely?
04:59
Are you thinking about needing less synchronization, when you have truly independent tasks? Or things like (non-) preemption?
Avatar
Wayward Nov 19, 2020 04:59 AM
it's generally independent tasks
Avatar
gingerBill Nov 19, 2020 05:00 AM
Idempotent in this case means independent.
05:01
Processes do not effect each other.
Avatar
Vegard Nov 19, 2020 05:01 AM
@jfs I think you meant @NWDD but I can answer too πŸ™‚ first of all, I think thread safety can be many different things. You meantioned preemption, that's one part of it -- if you only have 1 CPU and you fully control when the next thread executes, then you can be a lot more relaxed about a lot of things, since you know no other CPU will be able to access your variables concurrently. in other words, you don't need locking at all.
Avatar
gingerBill Nov 19, 2020 05:01 AM
I am using the term process in the general sense here to encompass the general idea. e.g. types of processes: core, thread, os process, fibre, green-thread, etc
Avatar
gingerBill Nov 19, 2020 05:02 AM
Now I have the definitions done and over with, let's gone down the dirty stuff πŸ˜›
Avatar
NWDD Nov 19, 2020 05:01 AM
so for example: imagine you're developing a network layer which is something that is highly asynchronous by definition. there are a lot of little details you have to handle: has the connection timed out? what data have you received? was there a network error? did the user put a nintendo switch in the microwave so the network connection broke? with concurrency you can actually ditch all means of synchronization and have it still happen form a perceived point in "parallel" (edited)
Avatar
AsafGartner Nov 19, 2020 05:05 AM
Unless I'm misunderstanding what you mean, I disagree. You often need synchronization with concurrency. Many webapps have synchronization bugs even though they are entirely single-threaded.
Avatar
NWDD Nov 19, 2020 05:07 AM
ah, yeah, i meant specifically cooperative concurrency (for example fibers or lua coroutines running in a single-thread or cooperative threads pinned to one core)
Avatar
Wayward Nov 19, 2020 05:10 AM
@AsafGartner that sounds like a problem with the single threaded event driven process rather than a simple form of monte carlo where you have one thread that creates jobs and takes back the result afterwards with no interaction in-between each job thread
Avatar
Vegard Nov 19, 2020 05:10 AM
@AsafGartner can you give an example of that?
Avatar
AsafGartner Nov 19, 2020 05:11 AM
Synchronization is for shared state. If you don't have shared state then it's no problem, but if you do you still need to enforce synchronization even in non-parallel systems.
Avatar
Vegard Nov 19, 2020 05:11 AM
@AsafGartner web apps are sometimes spawned in parallel by the web server, so even though the program itself is single-threaded, there can still be multiple instances of it running in parallel. not sure if this is what you're talking about
Avatar
AsafGartner Nov 19, 2020 05:11 AM
The common bug is check state -> make HTTP request -> perform action without checking if the state changed and assuming it didn't.
Avatar
jfs Nov 19, 2020 05:11 AM
I would like to state that synchronization is needed whenever two processes (in the sense of @gingerBill 's definition) communicate. Where communication means any kind of information sharing
πŸ‘ 1
Avatar
AsafGartner Nov 19, 2020 05:12 AM
A more concrete example, which I've encountered in several apps, is you hit play in a music app, it starts buffering the song, you hit pause, and when it's done buffering it plays anyway.
Avatar
NWDD Nov 19, 2020 05:13 AM
that can happen even in a 100% single-thread application where you flip some global bools and don't check them properly though
05:14
so for example, today an user reported that on Spelunky 2 if you freeze an enemy that grabs the player in a certain point in time
05:14
and then approach the enemy, it grabs you while frozen
Avatar
AsafGartner Nov 19, 2020 05:14 AM
Exactly. That's why synchronization is not just for parallel operations.
Avatar
NWDD Nov 19, 2020 05:16 AM
the general idea is that "you don't need as much work to avoid things going bad with concurrency compared to full parallelism"
Avatar
jfs Nov 19, 2020 05:16 AM
If we're assuming preemption, I'm still not sure what's a situation where it matters if a concurrent application is being run with parallelism or not.
05:17
Non-preemption (where each process controls when it gives up control of the CPU) could be seen as just like preemption with a global mutex
Avatar
NWDD Nov 19, 2020 05:18 AM
except it's efficient, yes
Avatar
Wayward Nov 19, 2020 05:19 AM
isn't that more of a specific node.js issue as it's a preemptive event driven framework?
05:20
never went down the javascript rabbithole personally
Avatar
jfs Nov 19, 2020 05:20 AM
Javascript is non-preemptive
05:20
I would say
Avatar
NWDD Nov 19, 2020 05:21 AM
i'm not sure but i also believe it's non-preemptive?
Avatar
Wayward Nov 19, 2020 05:23 AM
classic javascript i believe is non-preemptive yes, however google chrome attempts to make it preemptive to increase speed, which was later forked into node.js
Avatar
jfs Nov 19, 2020 05:23 AM
well it added worker threads AFAIK, so that changed maybe. But fundamentally it's how I understand a non-preemptive runtime
05:25
a generally non-preemptive framework would maybe also allow a process to choose what other threads can be scheduled while this process is waiting for an I/O request to complete (edited)
Avatar
NWDD Nov 19, 2020 05:25 AM
I've seen infinite loops hang the whole execution (of a web-server) (edited)
Avatar
NWDD Nov 19, 2020 05:26 AM
but either way, I don't think non-parallel preemptive systems interesting or useful xD
Avatar
AsafGartner Nov 19, 2020 05:25 AM
Worker threads run in a separate context and you have to communicate with them over a message channel, so you don't have parallelism issues there.
Avatar
jfs Nov 19, 2020 05:26 AM
yes, this is an important point @AsafGartner . There are certain frameworks (such as actors, channels) that make parallelism much easier (edited)
05:26
they encapsulate the needed synchronization, and so dramatically reduce manual work
Avatar
Vegard Nov 19, 2020 05:29 AM
@NWDD are you saying you don't think coroutines or green threads are ever interesting, or that they're only interesting if you can (also) schedule them in parallel? πŸ˜›
Avatar
NWDD Nov 19, 2020 05:30 AM
that "preemptive non-parallel concurrency" is not interesting in general
05:30
coroutines are great (obviously mandatory everything I say is my opinion and not a fact blablablablabla) (edited)
πŸ‘ 1
Avatar
AsafGartner Nov 19, 2020 05:31 AM
But coroutines aren't always fair.
05:32
Like when your older brother hogs the controller and you have to get your mom to do some preemption.
πŸ˜‚ 2
Avatar
NWDD Nov 19, 2020 05:34 AM
but fairness is not always a desirable feature, right?
Avatar
AsafGartner Nov 19, 2020 05:34 AM
In practice I would agree. In theory I think there's almost always a limit to the unfairness you're willing to have in a system.
Avatar
Vegard Nov 19, 2020 05:37 AM
I'm not sure if the fairness is really a big issue in practice. you can kinda see when you're going to have a lot of work to do and yield manually from time to time
Avatar
jfs Nov 19, 2020 05:37 AM
it's definitely an issue when you're doing some number crunching
05:37
such as decoding a JPG
05:38
software is in some respects easier to architect when you just assume preemption
05:38
and combine pieces that you know will be run in parallel
Avatar
Wayward Nov 19, 2020 05:39 AM
the worst thing is when it's a surprise
Avatar
NWDD Nov 19, 2020 05:39 AM
if you assume preemption and combine pieces that you know that will be run in parallel, then it's hard to replace it with concurrency, yes, that sounds about right
Avatar
gingerBill Nov 19, 2020 05:40 AM
I dislike coroutines in the traditional sense of them. Because they are hard to reason about. They don't act like a separate "process". (edited)
Avatar
Wayward Nov 19, 2020 05:41 AM
i like the idea about them, you can go say i need that later but it's big so please start reading and caching it from disk now so it'll be ready later
05:42
although i haven't toyed around with them so i'll have to see in practice when i get around to that
Avatar
jfs Nov 19, 2020 05:42 AM
the idea of coroutines might be that we want to write linear code (top-to-bottom) while still interacting with other threads in a totally synchronized fashion
05:42
what you describe sounds more like asynchrony to me @Wayward
Avatar
Wayward Nov 19, 2020 05:43 AM
for reading from disk, i think that's a great thing
Avatar
NWDD Nov 19, 2020 05:43 AM
it's kind of easier describing a transition like "change opacity during X time, then change scene, then change opacity during X time" than pretty much any other alternative
πŸ‘ 1
05:44
they are really hard to follow and debug and everything if you use them a lot in a dogma-like way, yes
Avatar
Vegard Nov 19, 2020 05:46 AM
@jfs coroutines are very often used to implement that asynchronicity
Avatar
Vegard Nov 19, 2020 05:55 AM
there are so many concepts and nuances to this whole parallel/concurrent thing πŸ™‚ would be cool to have an infographic or something relating all the terms to each other
Avatar
jfs Nov 19, 2020 05:56 AM
Yes. I didn't really understand what you meant @NWDD . And what is it anyway, that is "acting like a separate process" (like @gingerBill sasys)?
05:56
In my mind, coroutines are something that the OS is unaware of
05:56
basically I'm thinking of fibers
πŸ‘ 1
05:57
Fibers btw. are seen as a failed experiment (edited)
05:57
POSIX removed their implementation, and Microsoft deprecated them long ago
05:58
because with them, we not only have process-global and thread-global storage, but also fiber-global storage (edited)
05:58
and all the related confusion that comes with it
05:58
also when scheduling a single fiber on multiple OS threads
05:58
and so on
Avatar
Vegard Nov 19, 2020 05:58 AM
glibc still has setcontext/swapcontext/etc. I think the reason it was deprecated in POSIX was because it had a bunch of requirements WRT signals, which meant that you need 2+ syscalls per fiber switch, which is slow.
05:59
so it's still fully possible to define your own semantics and get good performance out of them. just not with an implementation following the POSIX specification
Avatar
jfs Nov 19, 2020 05:59 AM
fibers can also block other fibers that are run on the same thread
Avatar
NWDD Nov 19, 2020 05:59 AM
that's the point of having fibers (blocking other fibers that are run on the same thread) (edited)
Avatar
jfs Nov 19, 2020 06:00 AM
right, that was actually my initial point
06:01
Though, another intended use case for them was to be more resource friendly and to involve the kernel less
06:01
(In Windows, they then tried to introduce this other thing, called User mode scheduling) (edited)
Avatar
AsafGartner Nov 19, 2020 06:02 AM
I'm curious to know if UMS is actually useful.
06:02
Apparently it was made specifically for the MSSQL team.
Avatar
gingerBill Nov 19, 2020 06:09 AM
Fibres were a failed experiment because they were not what people actually wanted.
06:10
Effectively, people usually (not always) wanted a form of green thread be it N:1 or M:N.
Avatar
NWDD Nov 19, 2020 06:10 AM
That I can agree, but now again, people usually (not always) wanted OOP and we know how that went :)
Avatar
gingerBill Nov 19, 2020 06:25 AM
@NWDD People rarely know what they want before trying stuff out.
Avatar
Vegard Nov 19, 2020 06:10 AM
aren't fibers and green threads synonyms?
Avatar
NWDD Nov 19, 2020 06:11 AM
fibers are always cooperative and something that is controlled by the programmer (so the programmer has to decide when does the fiber start, where does it execute, at which point it is stopped, if/how is it scheduled...) (edited)
Avatar
Vegard Nov 19, 2020 06:14 AM
well, okay. so you can use fibers to implement green threads
Avatar
jfs Nov 19, 2020 06:15 AM
green threads being "user scheduled threads"?
06:16
I looked up how Haskell does its runtime - they have sort of M:N green threads as well
06:17
basically they can do it because they have a lot of allocation going on (edited)
06:17
so each allocation is potentially a fiber switching point (edited)
Avatar
Vegard Nov 19, 2020 06:17 AM
that's a bit sad.
Avatar
jfs Nov 19, 2020 06:17 AM
that only falls flat in tight loops where all the allocation has been optimized out
06:18
I don't think there is another way of doing scheduling in userland, or is there? How would that UMS work, anyway?
Avatar
Vegard Nov 19, 2020 06:20 AM
on Linux at least you can register a timer that will send a signal, then you can context switch from the signal handler. but this does go through the kernel as well, so it's not that great for performance
Avatar
NWDD Nov 19, 2020 06:20 AM
well, in the end everything is semantic, that depends on what you consider "doing scheduling"
Avatar
jfs Nov 19, 2020 06:21 AM
I mean (pseudo-) preemptively scheduling a fiber in place of another fiber
06:21
to get what OS threads are implemented at a lower cost (with fibers)
Avatar
NWDD Nov 19, 2020 06:22 AM
yeah, but like, you can implement coroutines or continuations without fibers
06:22
and if it's just swapping rsp and a couple of things, can it be considered scheduling?
Avatar
jfs Nov 19, 2020 06:22 AM
wouldn't coroutines always involve switching out the call stack?
Avatar
NWDD Nov 19, 2020 06:23 AM
there are also stackless coroutines, right?
Avatar
jfs Nov 19, 2020 06:23 AM
Switching out the call stack is basically how I understand "Fibers". Though, the term is also associated with the Win32 Fiber API
06:23
stackless coroutines is something else
Avatar
NWDD Nov 19, 2020 06:23 AM
and that's why it depends on semantics :)
Avatar
NWDD Nov 19, 2020 06:24 AM
also you could like, code in continuation passing style without a stack itself
Avatar
jfs Nov 19, 2020 06:24 AM
Stackless coroutines can be done when the compiler can compute the max stack size that a particular function call (hierarchy) needs
Avatar
jfs Nov 19, 2020 06:26 AM
The compiler can then place that "process" in an arbitrary memory location. It could be allocated as a "value type". (edited)
06:26
Well yeah, I'm not sure, I guess it's still implemented using rsp
Avatar
Vegard Nov 19, 2020 06:47 AM
since it's quiet -- I'm just curious if anybody here is doing game dev and if so, what kind of parallel code do you see in practice in whatever games/engines you're working on?
06:48
I assume most people have a separate audio thread at the very least. what else? do you scale number of threads with number of CPUs?
06:48
what kind of synchronisation do you use?
Avatar
jfs Nov 19, 2020 06:49 AM
I'm doing a GUI for industrial automation. I also have a little jigsaw puzzle game that I intend to network (match making, cooperative gaming)
06:50
I have background processes as well, and I want to be able to cancel them quickly
06:50
The background processes do file and networking I/O
06:51
so I've been experimenting with layering them on top of async IO
06:51
and trying to find a way to write them in a linear top-to-bottom fashion - basically in a conventional blocking style, with the exception that they should react to custom cancellation signals (edited)
06:52
and trying to make that code not be a mess
Avatar
NWDD Nov 19, 2020 06:54 AM
since it's quiet -- I'm just curious if anybody here is doing game dev and if so, what kind of parallel code do you see in practice in whatever games/engines you're working on?
@Vegard In indie games it's quite rare for something other than loading / audio and sometimes input And when done it's usually not worth it
Avatar
Wayward Nov 19, 2020 06:55 AM
@NWDD what do you mean with "when done"? remaking the whole game after release to implement threading?
Avatar
NWDD Nov 19, 2020 06:56 AM
Meaning that on games than I've worked, removing multi-threading has often provided better performance
06:57
I'm not sure how much into detail I can go? but for example in a game we worked on that used a parallelized scripting language with a reference counting gc
06:58
removing all forms of threading and replacing it with concurrency, provided better performance
Avatar
Vegard Nov 19, 2020 06:58 AM
@Wayward I think it was meant as "when people do write their games to make use of multithreading it doesn't give you any wins in terms of performance"
Avatar
jfs Nov 19, 2020 06:59 AM
which I'm sure is not true for AAA where they do have e.g. separate render threads (edited)
Avatar
NWDD Nov 19, 2020 07:01 AM
but AAAs are usually not CPU-bound by stuff that is often associated with CPU (AI, pathfinding, networking, world generation...)
Avatar
Wayward Nov 19, 2020 07:05 AM
to me it sounds like the bottleneck is the kernel switching/synchronization when working with threads or am i wrong?
Avatar
NWDD Nov 19, 2020 07:05 AM
also cache thrashing
Avatar
Wayward Nov 19, 2020 07:06 AM
that's being bound by the cpu cache?
Avatar
gingerBill Nov 19, 2020 07:06 AM
removing all forms of threading and replacing it with concurrency, provided better performance
That doesn't mean anything.
07:07
If your problem was parallelizable and also concurrent, you can do both. (edited)
Avatar
gingerBill Nov 19, 2020 07:08 AM
But how much of both is a complicated question
Avatar
NWDD Nov 19, 2020 07:07 AM
indie-games are more often than not cache-bound/access
Avatar
NWDD Nov 19, 2020 07:08 AM
yes... it's complicated, most parallelizable tasks end up taking less than what the context switch may take. (edited)
07:09
Big things that are parallelizable, like the zombies in they are billions or collisions in physics engines it ok (edited)
Avatar
gingerBill Nov 19, 2020 07:09 AM
I have noticed a lot of beginners to parallelizing things (and I am by no means an expert either), do it because they think it will make things faster, when in reality their problem could be made extremely fast on a single thread and multiple threads would slow things down.
Avatar
Wayward Nov 19, 2020 07:10 AM
your point being multithreading primarily having benefits assuming the code is already optimized?
Avatar
gingerBill Nov 19, 2020 07:10 AM
Yes.
07:10
For "beginners", at least.
07:11
Sometimes naΓ―ve multithreading can help a lot too.
07:11
e.g. multithreading a parser
07:11
A basic parser for a language can have a parsing queue for new files to parse and then workers to parse each file.
07:11
The only synchronization point is when one worker add a new file to parse to the queue.
Avatar
NWDD Nov 19, 2020 07:12 AM
multithreading always has a higher cost than running in single-thread
Avatar
NWDD Nov 19, 2020 07:12 AM
so it's better to use it when needed rather than by default
Avatar
jfs Nov 19, 2020 07:12 AM
As with other non-multithreaded problems, it's a lot about reducing the overhead by doing more work per cost
Avatar
jfs Nov 19, 2020 07:12 AM
i.e. batch the shit out of it
Avatar
gingerBill Nov 19, 2020 07:13 AM
If you want to use multiple processes by default, you will require some sort of system that can schedule things efficiently for the numerous amount of works e.g. M:N threading (e.g. Go)
Avatar
Wayward Nov 19, 2020 07:16 AM
what's the pros and cons of multiple processes in the task manager (google chrome) vs a single process with multiple threads?
Avatar
gingerBill Nov 19, 2020 07:18 AM
To be clear, I am using the term "process" in a very general sense.
Avatar
jfs Nov 19, 2020 07:18 AM
The benefit is process isolation
Avatar
NWDD Nov 19, 2020 07:21 AM
@gingerBill but even if you have efficient scheduling you still need to layout things in a way that it doesn't thrash, then use algorithms that are thread safe and slower or pay for the extra cost of locking (and either annoy the scheduler to get kicked earlier or pay the context switch)... And in the end you end up with something that makes a worse use for a system if that system is shared by other programs
Avatar
gingerBill Nov 19, 2020 07:21 AM
Exactly!
πŸ˜† 1
07:21
A generic algorithm cannot know how to optimize your specific problem.
07:21
Computers are dumb!
Avatar
Wayward Nov 19, 2020 07:22 AM
so basically, for it to be useful, you either need a huge cache or really optimized memory usage?
Avatar
NWDD Nov 19, 2020 07:23 AM
no, well, or really separate tasks
07:23
for example, in a game we recently released we were running liquids simulation and particles in threads separate from the main loop
Avatar
gingerBill Nov 19, 2020 07:24 AM
Optimized memory usage is a different problem.
07:24
That still exists in single threading problems.
07:24
And not really a parallelism specific problem
Avatar
NWDD Nov 19, 2020 07:24 AM
yes, I mean you could have theoretically a game fit in a single cache-line (edited)
07:24
but not be parallel-friendly
Avatar
Vegard Nov 19, 2020 07:25 AM
a 64-byte game? πŸ€”
Avatar
NWDD Nov 19, 2020 07:25 AM
it's a theoretical exercise xD
07:25
not daring anyone to do so
Avatar
Vegard Nov 19, 2020 07:26 AM
it's not a bad dare.
Avatar
NWDD Nov 19, 2020 07:26 AM
just saying that not being cache friendly (when doing multithreaded stuff) isn't related to using a huge amount of memory or optimizing (edited)
πŸ‘ 1
Avatar
Wayward Nov 19, 2020 07:27 AM
@NWDD can we just jump straight to the long version?
Avatar
NWDD Nov 19, 2020 07:27 AM
what long version?
07:27
oh that's right, the game
07:29
regarding that game I was talking about, we're now changing it so that instead of running separate systems on separate threads everything will end up running in the same thread in order this allows us to free cores so that we can actually run a separate game simulation on each core which solves a harder problem regarding online multiplayer point being: using multithreading for things that do not require it might actually prevent the program from reaching its full potential
Avatar
Wayward Nov 19, 2020 07:33 AM
single threaded applications are recommended until no longer viable, what about the latter case?
Avatar
NWDD Nov 19, 2020 07:34 AM
I can imagine a lot of cases where you actually want multi-threading eh? I mean for example: a compiler, a baking process, a simulation that can go faster than realtime... It just feels a bit sad to have a thread switched out because someone decided that browsers need to have an insane level of parallelism and the gpu driver decided to spawn 30 threads in your game. (edited)
Avatar
jfs Nov 19, 2020 07:36 AM
as long as those 30 threads are all pinned to the same core that's fine, no?
Avatar
NWDD Nov 19, 2020 07:39 AM
maybe, I think so... It didn't happen on any of our machines so we couldn't investigate it enough
Avatar
gingerBill Nov 19, 2020 07:46 AM
One thing some people in the audience are wanting to be discussed is the relation between parallelism and concurrency, and how that relates to different "models".
07:47
The relation is with regards to how the separate processes/threads communicate together.
07:48
Be it either communication through shared memory or communication through message passing.
07:49
Shared memory communication (usually) requires a form of locking (semaphores, mutexes, monitors, etc) to coordinate the processes/threads.
07:49
Whilst message passing based communication does so by exchanging "messages" between the different processes/threads.
07:50
What is interesting is how these "messages" interact, whether its asynchronously or synchronously.
Avatar
jfs Nov 19, 2020 07:51 AM
let's say that message passing does not require explicit locking
Avatar
NWDD Nov 19, 2020 07:51 AM
I'd argue that the serialization (copy) required to exchange "messages" is a form of locking where you prepay instead of pay-by-use
Avatar
jfs Nov 19, 2020 07:51 AM
it might still be implemented using locks under the hood
07:51
especially synchronous message passing
Avatar
gingerBill Nov 19, 2020 07:51 AM
@jfs I was about to say that the message-based models may still require "locks" of some sort, but they are not explicitly handled by the user.
πŸ‘ 1
07:52
So the model difference is if the locking is implicit or explicit. (edited)
πŸ‘ 1
Avatar
jfs Nov 19, 2020 07:52 AM
there are similar mechanisms for shared data
07:52
I believe Java's synchronized might do such a thing, although I've never used it
Avatar
jfs Nov 19, 2020 07:53 AM
you could just mark any object as "must-be-locked"
07:53
but shared data synchronization tends to needs locking hierarchies, which are pretty complex. I believe
Avatar
jfs Nov 19, 2020 07:53 AM
while message passing is always an interaction with a single mailbox - that's simple
Avatar
gingerBill Nov 19, 2020 07:53 AM
And many of these mechanisms/patterns will arise in the different models too.
Avatar
gingerBill Nov 19, 2020 07:53 AM
A good example of this would be having "a queue + a monitor", the monitor is used to synchronize the queue. In certain models, this has a special name depending on it handled.
Avatar
gingerBill Nov 19, 2020 07:54 AM
Two common family of models are: Actor model Process Calculus (includes CSP, CCS, pi-calculus)
07:54
In a way, these two families can be seen as duals of one another
07:56
The actor model works very well in object orientated languages because of the "object" nature of the "actors". They are opaque to each other actor.
07:57
When these "actors" send messages, it is completely asynchronous, which means that no blocking on the receiver end.
07:58
So for the "actors", the "mailbox" (the thing holding the "messages", i.e. queue) might need to be potentially loads of messages, so it's a lot harder to reason about.
07:58
CSP (a form of Process Calculus, which Go uses a slightly variant of), is fully synchronous in nature.
07:58
The message is flipped from being the unit of communication to the channel.
07:59
A channel is effectively a message queue with a monitor applied to it.
07:59
The channel is the thing that referenced to, where messages can be sent to it or received from.
08:00
Most channels will block, and thus synchronous, until a channel receiver reads.
08:00
This has advantages of that the blocking mechanism is that the channel only needs to "hold" one message.
08:01
Go extends this to allow for buffered channels (of fixed capacity), so that you can have stuff similar to the Actor more, but the channel is the focus, rather than the sender/receiver (i.e. the actor).
08:04
So the in Process-Calculus family of models, the processes communicate (and synchronize) through channels, whilst the Actors are themselves the processes.
08:05
One interesting thing is that the actor model does have the advantage of being "modelable" across multiple machines e.g. each machine an actor which then communicates over a network.
08:05
So because the models are effectively duals of each other, they can be applied at different levels for different problems.
08:06
But because these are generalized models, they will not be good for all problems (obviously).
08:06
But one thing which seems to be a given across all forms of concurrency is the concept of a queue.
08:06
QUEUES EVERYWHERE! (edited)
Avatar
NWDD Nov 19, 2020 08:07 AM
well, concurrency through shared memory may disagree
Avatar
gingerBill Nov 19, 2020 08:08 AM
What do you mean?
Avatar
NWDD Nov 19, 2020 08:09 AM
I mean, you can do concurrency through memory without using queues
Avatar
gingerBill Nov 19, 2020 08:10 AM
Of course, but many basic concurrency things will have a queue-like thing to them.
Avatar
NWDD Nov 19, 2020 08:11 AM
yes, yes, just was pointing out that "all forms of concurrency" is just an expression
08:12
but I do think there is a merit in ditching queues to improve overall efficiency, even if it makes everything much harder to reason about
Avatar
gingerBill Nov 19, 2020 08:12 AM
But if you look at non-computing realms, e.g. humans, the queue is the way to organize things.
08:13
@NWDD And that's the cost that is to made. The cost between pure performance and the ability to reason about the problem.
Avatar
NWDD Nov 19, 2020 08:13 AM
maybe some models will come in the future to help mitigate this? (edited)
Avatar
jfs Nov 19, 2020 08:14 AM
I'd assumed that queues don't need to be slow. In fact they can achieve speed-up because they reduce synchronization costs
08:14
also, messages don't necessarily imply a lot of copying. You can just enqueue pointers
Avatar
jfs Nov 19, 2020 08:14 AM
it's basically ownership transfer
Avatar
gingerBill Nov 19, 2020 08:14 AM
Queues are just a way of organization, and there is not inherently slow about them.
Avatar
gingerBill Nov 19, 2020 08:15 AM
Random distribution into different queues might not be the best choice compared to selective distribution.
08:16
e.g. if each message contains information about how much work it is, the scheduler can help decide where to place it.
08:16
And that's the next aspect to add onto the queue idea, a scheduler.
Avatar
jfs Nov 19, 2020 08:16 AM
I think we really need to distinguish access to global concurrently mutated data structures (databases) from cooperating computation (edited)
08:16
the former might tend to gnarly explicit synchronization, and RCU type data structures
08:17
the latter tends to be easily coordinated using queues
Avatar
gingerBill Nov 19, 2020 08:18 AM
1 requester to 1 source == trivial M requesters to 1 source == shared memory 1 requester to N sources == message M requesters to N sources == hybrid
Avatar
jfs Nov 19, 2020 08:19 AM
I don't understand tbh
Avatar
NWDD Nov 19, 2020 08:19 AM
i think that's right
Avatar
jfs Nov 19, 2020 08:19 AM
what would be an example of M to N
Avatar
NWDD Nov 19, 2020 08:20 AM
the linux kernel has a recent example to that with asynchronous IO via
08:20
io_uring? (I think it was called something like that) (edited)
Avatar
jfs Nov 19, 2020 08:20 AM
io_uring is just a queue
Avatar
NWDD Nov 19, 2020 08:20 AM
yes and no, it's "a queue with pointers"
08:21
so it's kind of hybrid
08:21
you have this global data structure which is shared between user and kernel
08:22
and it's by writing on it that you communicate and request to avoid having to pay for the switch
08:22
so while it's true that it uses a queue to synchronize it also uses a shared memory location
Avatar
jfs Nov 19, 2020 08:23 AM
right, in the end everything is a shared memory location
08:23
queues are only an abstraction
08:24
queues provide serialization of concurrent requests / responses
Avatar
gingerBill Nov 19, 2020 08:24 AM
There is a reason I brought up the "models". Some models are more useful than others in different situations
Avatar
jfs Nov 19, 2020 08:26 AM
with M to N, did you allude to e.g. N threads accessing a shared memory search tree of M nodes that can be concurrently modified?
Avatar
gingerBill Nov 19, 2020 08:27 AM
I was meaning: M threads (requesters/accessors) accessing N sources of shared memory
Avatar
jfs Nov 19, 2020 08:27 AM
so what's a source of memory here?
08:28
what is the access?
Avatar
gingerBill Nov 19, 2020 08:30 AM
(I am being very vague on purpose)
Avatar
jfs Nov 19, 2020 08:34 AM
My point above was probably that there is a tradeoff - we can replace explicit synchronization on shared memory by mediating accesses through a data-structure-managing actor (process)
08:35
at the cost of more strict serialization
Avatar
NWDD Nov 19, 2020 08:35 AM
this is what I understood: 1 requester to 1 source == trivial -> (straight-forward single-thread code) M requesters to 1 source == shared memory -> (for example: multiple threads accessing a hash-table) 1 requester to N sources == message -> (for example: a thread that receives network packets from multiple sockets and puts information in a hashtable) M requesters to N sources == hybrid -> (for example: multiple threads that receive network packets from multiple sockets and put information in a hashtable)
Avatar
gingerBill Nov 19, 2020 08:40 AM
Yep!
08:40
Perfect examples.
Avatar
jfs Nov 19, 2020 08:40 AM
hmmm
08:40
What I'm missing is for example, how are those N sources related?
08:40
If there are no consistency constraints for the N things, the problem isn't any harder
Avatar
gingerBill Nov 19, 2020 08:41 AM
Well, the last one is technically M->N->1
Avatar
NWDD Nov 19, 2020 08:42 AM
yes, couldn't think of a practical example without adding ->1 😦 (in the last example I was thinking about a matchmaking server)
08:43
If there are no consistency constraints for the N things, the problem isn't any harder
in the M->N->1 example I was thinking of, the reason why M->N is different from 1->N is because 1->N couldn't provide enough throughput
Avatar
gingerBill Nov 19, 2020 08:44 AM
The simple example of M->N would this: Each (M) thread receives a network packet, does some work on it, and then passes to another server (N)
Avatar
bvisness Nov 19, 2020 09:40 AM
What's the worst concurrency bug you've all encountered?
Avatar
gingerBill Nov 19, 2020 09:41 AM
Locked up everything on all threads, because I was recursively sending and receiving messages (semaphore) from the same thing.
09:41
e.g. all threads were blocked and stuck in an infinite loop at the same time, effectively.
Avatar
bvisness Nov 19, 2020 09:44 AM
I ask because I know that there's tons of bug potential once you start doing things concurrently. I had a good time a while ago going through this thing: https://deadlockempire.github.io/
Slay dragons, learn concurrency! Play the cunning Scheduler, exploit flawed programs and defeat the armies of the Parallel Wizard.
πŸ‘ 1
Avatar
gingerBill Nov 19, 2020 09:45 AM
Here's a question, is there actually ever a need for a semaphore instead of a condition variable?
09:46
(I know they are not equivalent)
Avatar
bvisness Nov 19, 2020 09:49 AM
For the audience (me), could you define the difference?
Avatar
NWDD Nov 19, 2020 10:01 AM
What's the worst concurrency bug you've all encountered?
A race condition that happened in a non-parallel situation of a so-called "safe" programming language (C#) in a game that was more or less ECS-based, where a system removed the "rigidbody" component in a very specific (user-triggered) situation. There was a separate system which worked like a finite-state-machine that was being updated every few frames. If during a transition between two states the rigidbody got removed, the thread that was running the logic crashed and the C# runtime for the target platform would silently swallow the exception freezing the game (without providing any crash-dump or useful information)
(edited)
😬 1
Avatar
NWDD Nov 19, 2020 10:12 AM
Here's a question, is there actually ever a need for a semaphore instead of a condition variable?
Have been thinking for a while, but I don't think I've ever felt the need or seen an advantage to using a semaphore
10:13
I do recall at some point using them because it was provided in a library example?
Avatar
bvisness Nov 19, 2020 10:25 AM
So what makes semaphores a poor choice?
Avatar
ratchetfreak Nov 19, 2020 10:26 AM
because the most recommended scenario for a semaphore is a pool of resources
10:26
however when you have a pool of resources then also want a handle to the specific resource you got
10:27
which need an additional thread-safe way to handle it
10:27
and that thing to dole out the resource handles can handle blocking the thread just as well as the semaphore
Avatar
NWDD Nov 19, 2020 10:29 AM
I can see them being useful for example to request a system to run once (for example run a physics update)? But because more often than not you need to know when it has finished and wait for it, there are other options? Plus it feels like semaphores aren't really well known which means that it may confuse other people working in the project In the end I feel that because we're used to do so it's easier to reason about critical regions of code that should not execute at the same time and other options are just not as popular? (edited)
Avatar
ratchetfreak Nov 19, 2020 10:30 AM
they are still taught as a synchronization primitive though
10:31
and for the record: semaphore is a counter where if you try an decrement below 0 it blocks until another thread increments it above 0 a condition variable is an object that lets you wait on a signal from the thread while temporarily releasing a mutex
Avatar
NWDD Nov 19, 2020 10:32 AM
yes, people are taught about synchronization in general but I don't think that knowledge persists in time after tests
Avatar
ryanfleury Nov 19, 2020 10:54 AM
For those who have worked with parallel programming a fair amount, doing parallel programming properly such that close-to-optimal code is produced given any parallel problem seems extremely difficult to master, and extremely difficult to do in general. How much of this do you attribute to tools? Are there tools you wish you had when learning---or doing---this kind of programming?
Avatar
jfs Nov 19, 2020 10:54 AM
What's the worst concurrency bug you've all encountered?
@bvisness I've run into a weird situation that involved some sort of false sharing. I had a writer queue that would normally transfer around 20MB / sec, but in that situation the throughput dropped to about 400KB / sec
11:34
forgot to mention explicitly that the bottleneck (400KB/s) here was a memcpy() ;-). When the original 20MB/s was simply the hardware source
11:01
@ryanfleury I'm not sure I'm attributing anything on tools. What we've missed out on in the discussion so far is focussing more on what actually happens in the hardware, HM style. (edited)
Avatar
jfs Nov 19, 2020 11:02 AM
In the end we're on highly parallel machines and if there weren't possible benefits, much of the parallelism wouldn't exist (edited)
Avatar
Wayward Nov 19, 2020 11:02 AM
adding onto @ryanfleury 's question, are there any resources you'd recommend for getting into parallel programming?
Avatar
NWDD Nov 19, 2020 11:05 AM
I like the parallel stacks feature of visual studio, but It's not life-changing
Avatar
jfs Nov 19, 2020 11:12 AM
@Wayward I was recommended "Performance Modeling and Design of Computer Systems - Queueing Theory in Action". My company has ordered it, haven't got to see it yet.
11:12
It for sure is important to understand the basics, like Caches, MESI, and synchronization primitives
11:14
the Linux kernel goes quite fancy with synchronization on shared data structures, so maybe that is a recommend. Though on the other hand, this approach is error-prone, not beautiful from an architectural perspective.
11:16
I'm sure that static analyzers, fuzzers, and similar tools can help a lot with debugging shared data structures. So that would be an answer to Ryan's question. I can't say anything about the quality of the existing tools, not really having used any
Avatar
Vegard Nov 19, 2020 11:17 AM
I feel like I ought to have some tools to recommend, but the truth is that I don't really. usually the challenge when doing something fancy (i.e. more than the straightforward spinlock/mutex) is getting things to work correctly at all, and then the best thing you can do is to stress-test on as many CPUs as you can. so in a way maybe a machine with lots of CPUs is the best way to find bugs..?
Avatar
jfs Nov 19, 2020 11:18 AM
I found this a nice and accessible document about architectural aspects, although it's from Chris Lattner and geared towards high-level languages (Swift in this case) https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 (edited)
11:19
With my relatively humble stuff, I found it surprising how quickly some of my concurrency bugs were found by simple stress testing @Vegard
11:20
though that is somewhat of a tautology, it doesn't take a lot of testing until you hit no bugs anymore (i.e. just fewer ;-])
Avatar
Vegard Nov 19, 2020 11:23 AM
it can be really tough to hit some bugs, so I don't advocate testing as a way to validate your design
11:25
for sanity checking or bug finding it's okay
Avatar
Wayward Nov 19, 2020 01:51 PM
@ryanfleury on a sidenote, both the current topic and the next few could really use some resource recommendations listed on the handmade network resource page afterwards
Avatar
gingerBill Nov 19, 2020 01:57 PM
I'm back, female canines!
πŸ™„ 3
Avatar
bvisness Nov 19, 2020 01:59 PM
so what 🌢️ stuff do you have for us
Avatar
gingerBill Nov 19, 2020 01:59 PM
The Actor Model is only popular because because it's the OOP of concurrency models and fits very with in OOP languages.
Avatar
bvisness Nov 19, 2020 02:04 PM
Interesting. Didn't you say earlier that it was possibly a good fit for networked applications?
14:04
I mean I guess that wouldn't be related to popularity, per se
Avatar
gingerBill Nov 19, 2020 02:05 PM
I didn't say good, I said it scaled easily to networked applications.
14:05
Because each machine is treated as its own actor in the network/graph
Avatar
bvisness Nov 19, 2020 02:06 PM
Would you say that CSP is basically the actor model too, or are there some differences?
Avatar
gingerBill Nov 19, 2020 02:06 PM
CSP is the anti-actor model.
Avatar
bvisness Nov 19, 2020 02:07 PM
Ok that's surprising to me, because both models have separate stateful "processes" that communicate with each other, don't they?
Avatar
gingerBill Nov 19, 2020 02:10 PM
Think about the focus of each model
Avatar
bvisness Nov 19, 2020 02:15 PM
I'm not sure I see the distinction you're going for. Are you saying the important part of CSP is the communication, and the important part of the actor model is the actors (e.g. processes)?
14:15
Or is my "e.g. processes" the issue here
Avatar
jfs Nov 19, 2020 02:18 PM
I'm not really getting the distinction either. Also not all of CSP is channel focused or communication focused. If I recall the first half of the book doesn't even mention channels. I recall CSP more as an algebra over sequences of events
14:19
but for the channel part, not sure what is that relevant or insightful. Would very much like to know
14:20
I gather that CSP channels are understood as sending messages synchronously (i.e. the sender waits until recipient "dequeues" it), as opposed to asynchronous sending with Actor model, but I'm also not sure that this is super relevant, nor would I actually want to waste the time waiting
Avatar
bvisness Nov 19, 2020 02:22 PM
well I'm also not sure that the actor model specifies synchronous vs. asynchronous communication?
Avatar
jfs Nov 19, 2020 02:23 PM
There are in any case, different variants of all the theories - for example I believe CSP started out as a static graph of processes connected by channels, but it might be that this constraint was lifted in later publications (don't quote me, I haven't really checked back)
14:24
I know that actor model is definitely always understood as sending completely asynchronously @bvisness . At least in these days
14:25
but if I'm thinking of modelling my program after the actor model, I'll probably consider allocating messages statically in the sender, so allocation isn't a performance bottleneck, and the number of existing messages is naturally bounded
14:26
that would also mean each sender has to wait until it gets some of its messages returned back before it can send more, which would again lead to some form of "blocking". Not really while sending but still
Avatar
bvisness Nov 19, 2020 02:30 PM
that makes sense, and would lead to a model like I'm used to from Go
14:31
(what you describe is basically the behavior of a buffered channel)
14:32
I actually very rarely see any of Go's concurrency features used heavily outside the standard library, and I'm not sure why. They certainly feel well-integrated into the language, but nobody seems to use them.
14:33
Maybe it's just laziness or people not knowing how to use them.
Avatar
ratchetfreak Nov 19, 2020 02:33 PM
more column b than column a IMO
14:34
then again go is targeted to backend webdev
Avatar
bvisness Nov 19, 2020 02:35 PM
I certainly do agree that the actor model / CSP is a good conceptual fit for an object-oriented language (I continue to think they are essentially the same)
14:36
I guess I'm curious, though, if it's an essentially object-oriented concept. Concurrent execution seems to me to imply that you have concurrent "processes", which will certainly have their own state. Whether that's an "object" vs. a coroutine, goroutine, thread, etc. seems unrelated.
14:37
After all, you can apply actor model or CSP designs inside a program, or across network boundaries, and the concepts feel the same to me
Avatar
gingerBill Nov 19, 2020 02:40 PM
If you extend CSP to allow for infinite capacity channels, then they are dualistic models. Both are modelling interactions of a graph mesaages.
14:40
Actors = Nodes/Vertices Channels = Edges
Avatar
bvisness Nov 19, 2020 02:42 PM
So does the actor model not say anything about synchronization? I wasn't under the impression that e.g. a smalltalk system would make the communication between two objects asynchronous.
Avatar
gingerBill Nov 19, 2020 02:42 PM
But as soon as make the channels fixed capacity, it becomes synchronized (to a limit)
14:42
The actor model is pure asynchronous
14:46
So that's why I said they were dual models.
Avatar
jfs Nov 19, 2020 02:46 PM
I'll say that one should strive the number of messages in flight bounded in any program
14:47
Not sure that it's particularly relevant if it's the channel that caps the number of messages, or if it's the senders (edited)
Avatar
gingerBill Nov 19, 2020 02:47 PM
Another fun fact, CSP is effectively UNIX Pipes applied to the program level
πŸ‘ 1
Avatar
bvisness Nov 19, 2020 02:53 PM
Pasting some messages from #fishbowl-audience about the differences between CSP and the actor model...
14:54
Some definitions from the internet:
An actor is a computational entity that, in response to a message it receives, can concurrently: send a finite number of messages to other actors; create a finite number of new actors; designate the behavior to be used for the next message it receives. Recipients of messages are identified by address, sometimes called "mailing address". Thus an actor can only communicate with actors whose addresses it has. It can obtain those from a message it receives, or if the address is for an actor it has itself created.
The actor model is characterized by inherent concurrency of computation within and among actors, dynamic creation of actors, inclusion of actor addresses in messages, and interaction only through direct asynchronous message passing with no restriction on message arrival order.
Avatar
jfs Nov 19, 2020 02:54 PM
@gingerBill that is true for TCP as well, or for file I/O, or for... any communication with flow control really
Avatar
gingerBill Nov 19, 2020 02:55 PM
I mean specific pipes because of the ability to select
Avatar
jfs Nov 19, 2020 02:56 PM
I mean specific pipes because of the ability to select
select is just demultiplexing
14:57
you have a number of possible inputs (from concurrent connected actors) and want to be able to the next one that signals anything
Avatar
jfs Nov 19, 2020 02:58 PM
select is needed as a system call because the OS encapsulates I/O
14:59
but in general, demultiplexing is implemented using synchronization primitives
14:59
like condition variables
14:59
or in hardware, using interrupts or regular polling
Avatar
gingerBill Nov 19, 2020 03:00 PM
I know it's demultiplexing, but I meant that CSP was effectively the formalization of UNIX's pipes. (edited)
Avatar
jfs Nov 19, 2020 03:00 PM
hmm, ok
Avatar
bvisness Nov 19, 2020 02:55 PM
jfs's question:
But what is the essential difference between sending a message "via a channel" or "to an address"?
My overall take
I guess it's true that in a CSP system you don't directly reference the other actors. But I'm still not convinced that meaningfully changes the model you could conceive of channels as "actors" that hand messages back and forth, and now you've achieved basically the same thing? it doesn't feel to me like a fundamental difference
Avatar
bvisness Nov 19, 2020 02:55 PM
and bill:
There's a real I keep saying dual models. They are effectively opposites for measuring graphs of messages
14:55
k continue πŸ˜›
Avatar
bvisness Nov 19, 2020 02:57 PM
So @gingerBill are you saying the difference is that in CSP you control the edges, while in the actor model you control the vertices? Or something like that?
Avatar
gingerBill Nov 19, 2020 02:57 PM
Yes
Avatar
bvisness Nov 19, 2020 02:57 PM
ok, I see what you mean by "dual" then
Avatar
bvisness Nov 19, 2020 03:00 PM
I guess I still don't think they are all that different in practice, since channels feel in that context like extra restrictions on actor communication.
Avatar
jfs Nov 19, 2020 03:01 PM
My idea is that in most realistic programs you would just use a mixture of both, as you see fit
15:02
it only is a meaningful difference if you imagine actors being real physical threads (or at least OS threads) (edited)
Avatar
jfs Nov 19, 2020 03:02 PM
and channels really being a certain standard implementation with a fixed comm interface (edited)
15:05
I also happen to think that it is extremely important to use standard interfaces for concurrently modelled programs
15:06
from my experience setting up all these graphs and actors and channels and what not, and then using the comm ifaces right, is extremely painful, so one wants to maintain and use as few primitives as possible (edited)
Avatar
bvisness Nov 19, 2020 03:13 PM
So where are actor models used in practice for concurrency? (Like, what languages or tools are used for this)
15:13
apparently Go is not an example, by @gingerBill 's definition πŸ™‚
15:13
I'm just not very aware of what's in the space
Avatar
bvisness Nov 19, 2020 03:24 PM
Maybe we should just wrap it up anyway. Last call for questions?
Avatar
ratchetfreak Nov 19, 2020 04:25 PM
honestly it just sounds like nit picking to distinguish between them, you can turn the actor model into CSP by making a bunch of channel actors who forward messages to everyone who subscribed
Avatar
jfs Nov 19, 2020 04:41 PM
Scala's Akka is the most famous actor implementation that I'm aware of. Erlang is a popular and successful language that implements the actor model. Never really used any of these (edited)
Avatar
ryanfleury Nov 19, 2020 08:22 PM
Alright closing this off now. Thanks everyone for participating!