7 ms·

So which terms do you suggest? What I was talking about was event handing systems needing different things than computational systems, and misapplications of to

by _yosefk 13y ago

So which terms do you suggest? What I was talking about was event handing systems needing different things than computational systems, and misapplications of tools designed for the former in the latter. The way I use the terms "concurrency" and "parallelism" is largely consistent with the way language designers involved in Haskell, Rust and ParaSail use these terms. What other widespread uses of these terms conflict with my usage, and what should I have said to avoid "another round of terminology war"?

Glyptodon 13y ago
I don't really know what terms are best to use, all I know is I've met a fair number of people who don't think context switching is a true form of concurrency. I think a large segment of this group sees parallelism as many backhoes digging one hole (or working as a team on a few holes) and concurrency as many backhoes all digging their own holes, roughly speaking. I also encounter another (smaller) group of people who blur/conflate concurrency with distributed systems, probably because of things like websites bragging about how many 'concurrent connections' they can serve. These two groups can blur with each other fairly easily because they share what I'd term an 'intuition overlap.' Oddly enough, I think this helps explain why many people are often so confused about things like NodeJS. Touted for its concurrency, a lot of people first using it seem to think that it's somehow parallel by nature. I think the reason this kind of confusion is so prevalent is that in vernacular English, concurrent is essentially a synonym for 'simultaneous,' while as used in programming (along the lines of how it was used in this article) it comes to mean something more like 'how many balls can a juggler keep in the air,' with highly concurrent systems being able to juggle many more balls with the same two hands, so to speak. And in fact, in a way, all the balls are concurrently in the air, but it's not (I think) the most intuitive thing, hence why many vehemently disagree about usage.
Symmetry 13y ago
When you find yourself arguing about whether a tree falling in the forest causes a sound, the right thing to do is to start talking about vibrations and audio sensations instead. Ambiguous words can almost always be bypassed by using more words to nail down meanings properly. And, more elaboration on the subject than necessary: http://wiki.lesswrong.com/wiki/A_Human%27s_Guide_to_Words http://wiki.lesswrong.com/wiki/A_Human%27s_Guide_to_Words
scott_s 13y ago
Your usage is slightly different than mine. My usage comes from what I learned way back in my operating systems class in undergrad. I've been doing work in parallel computing of various forms for a bit now, and this is how I think about it (cribbing from what I wrote here a few months back): Concurrency is a statement about a duration of time. Parallelism is a statement about a moment in time. During a one second window, did both of the tasks execute? If yes, then they are concurrent. If no, then they are not concurrent in that window. Was there any moment in time when both tasks executing simultaneously? If yes, then they executed in parallel. If no, then they did not execute in parallel. From this, it's easy to see that if something is parallel, it must also be concurrent - in order for two tasks to execute during the same moment in time, they must also both have executed during a window of time. Concurrency without parallelism happens on machines with a single core. Processes and threads must time-share the only core. Frequently, some of these processes will have multiple threads, so the threads need to synchronize with each other, even though they don't execute at the same time. Concurrency and parallelism implies non-deterministic interleavings of threads and processes, but whether or not the result is deterministic is up to how we program.
ggchappell 13y ago
I think the solution is simple: define your terms (or link to a definition that agrees with yours). More to point, please do this. I think it would make your article less confusing and accessible to more people.

by _yosefk 13y ago

Glyptodon 13y ago

I don't really know what terms are best to use, all I know is I've met a fair number of people who don't think context switching is a true form of concurrency. I think a large segment of this group sees parallelism as many backhoes digging one hole (or working as a team on a few holes) and concurrency as many backhoes all digging their own holes, roughly speaking. I also encounter another (smaller) group of people who blur/conflate concurrency with distributed systems, probably because of things like websites bragging about how many 'concurrent connections' they can serve. These two groups can blur with each other fairly easily because they share what I'd term an 'intuition overlap.' Oddly enough, I think this helps explain why many people are often so confused about things like NodeJS. Touted for its concurrency, a lot of people first using it seem to think that it's somehow parallel by nature. I think the reason this kind of confusion is so prevalent is that in vernacular English, concurrent is essentially a synonym for 'simultaneous,' while as used in programming (along the lines of how it was used in this article) it comes to mean something more like 'how many balls can a juggler keep in the air,' with highly concurrent systems being able to juggle many more balls with the same two hands, so to speak. And in fact, in a way, all the balls are concurrently in the air, but it's not (I think) the most intuitive thing, hence why many vehemently disagree about usage.

Symmetry 13y ago

When you find yourself arguing about whether a tree falling in the forest causes a sound, the right thing to do is to start talking about vibrations and audio sensations instead. Ambiguous words can almost always be bypassed by using more words to nail down meanings properly. And, more elaboration on the subject than necessary: http://wiki.lesswrong.com/wiki/A_Human%27s_Guide_to_Words http://wiki.lesswrong.com/wiki/A_Human%27s_Guide_to_Words

scott_s 13y ago

Your usage is slightly different than mine. My usage comes from what I learned way back in my operating systems class in undergrad. I've been doing work in parallel computing of various forms for a bit now, and this is how I think about it (cribbing from what I wrote here a few months back): Concurrency is a statement about a duration of time. Parallelism is a statement about a moment in time. During a one second window, did both of the tasks execute? If yes, then they are concurrent. If no, then they are not concurrent in that window. Was there any moment in time when both tasks executing simultaneously? If yes, then they executed in parallel. If no, then they did not execute in parallel. From this, it's easy to see that if something is parallel, it must also be concurrent - in order for two tasks to execute during the same moment in time, they must also both have executed during a window of time. Concurrency without parallelism happens on machines with a single core. Processes and threads must time-share the only core. Frequently, some of these processes will have multiple threads, so the threads need to synchronize with each other, even though they don't execute at the same time. Concurrency and parallelism implies non-deterministic interleavings of threads and processes, but whether or not the result is deterministic is up to how we program.

ggchappell 13y ago

I think the solution is simple: define your terms (or link to a definition that agrees with yours). More to point, please do this. I think it would make your article less confusing and accessible to more people.