3 ms·
I tend to agree. I've raised some hackles with colleagues over, "splitting hairs," on the difference between concurrency and parallelism. They're two different
by agentultra 14y ago
I tend to agree. I've raised some hackles with colleagues over, "splitting hairs," on the difference between concurrency and parallelism. They're two different things and this articles does a pretty good job of pointing out some of them.
I've always thought of parallel computation as lines in time that never intersect or share resources but are computed in the same order at the same time:
---|----
---|----
---|----
The results of each line are part of one computation. The problem is split over space and their computation happens in the same order as a single task.
Conversely, concurrency is a little more lenient on causality; the lines are scheduled co-operatively and the computation will complete at some point when all the tasks are complete.
Causality in programming languages is certainly an interesting area to improve upon. Some interesting perspectives are http://bloom-lang.org http://bloom-lang.org and my own attempt at implementing it: https://github.com/agentultra/knockblock https://github.com/agentultra/knockblock which attempt to address the causality of eventually-consistent distributed replicas.
- st2p 14y agoIt's as simple as, something that's concurrent (simultaneous) may not be parallel (physically) but if it's parallel it's also concurrent. When used as a verb, parallel is interchangeable with concurrent.