并发不是并行性？ [英] Concurrency is not Parallelism?

问题描述

这里是Rob Pike对此的幻灯片。每次我去这个我觉得像一个蠢货。我不能弄清楚它的要点。众所周知，并发是一个复杂的问题分解成较小的组件。如果你不能正确地将一些东西分成更小的部分，那么很难使用并发来解决它。

但是在幻灯片中没有太多细节，在你实现并发后如何获得并行性。在课程幻灯片（52号）中，他说并发 - 也许平行。但是问题是 - 何时和如何能够正确有效地实现并发性导致并行性？

我的猜测是，开发人员应该在并发级别工作 - 并行性应该是语言的/ vm的关注（gomaxprocs？）。只要关心智能分解成更小的单元，只关心正确的并发 - 并行性将由系统来处理。

请放一些光。

解决方案

Rob Pike的意思

一个算法的抽象形式，你必须选择，如果你将实现它与消息传递或共享内存或也许混合。您还必须考虑内存访问类型（NUMA，UMA等）和使用的拓扑（Hypercube，Torus，Ring，Mesh，Tree等）

这似乎很多的工作，一个人只是想要的东西，甚至可以简单，以并行的方式（例如并行）。

这是很多工作特别是如果你改变拓扑（所以你可以有它的所有优点）。

所以你编写并行代码（简单或复杂）将选择看起来最好的方式，甚至以连续的方式运行它（一个示例是.net的任务并行库）

重要编辑：

我应该提到我在谈论程序/算法中的并发，而不是运行的独立程序

您说

很好理解并发是复杂问题的分解成较小的分量。如果你不能正确地把一些东西分成更小的部分，很难使用并发来解决它。

这些较小的组件可能依次依赖于彼此以完成，所以即使你分成小组件，也不意味着你实现并发/并行性。

在我所有的并行和分布式算法类中（在BS和MS中），我们从来没有谈到我们获得的并发性，现在让我们看看如何获​​得并行性 。

在文献中，你还会发现分布式和并行之间的细线。 p>

从算法的角度来看，你可以使用并发，并行性和分布式，你会得到相同的想法。

从一个实现的角度来看，如果你说并行，你通常打算在本地计算机或集群（共享内存通信）上运行的程序，以及在网格上运行程序（消息传递通信）时分布式。

现在，分布式和并行性意味着并发。

我认为你应该更加怀疑这些术语，因为即使在文学中（我谈论的是实际贡献于这个领域而不只是创造某种语言的人），它们被用来表达抽象的概念。

并发性的算法（即程序）意味着具有可以独立于其他代码段运行的代码段，即使它们最终会等待其他代码段（检查Amdahl定律看到的是什么含义

因此，只要你在一个算法/程序中有并发性，你也有并行性。最好只是实现一些并行和分布式算法，以更好地了解其背后的想法。如果你知道C / C ++，你可以使用OpenMPI用于分布式（消息传递）实现，而OpenMP用于并行（共享内存）实现。

EDIT：

他也可以意味着并发作为抽象原则，并且作为实现的方式并行[共享内存，消息传递，内存访问类型（numa，uma等）]。

Here are slides by Rob Pike on this. Every time I go thru this I feel like a moron. I'm not able to to figure out the gist of it. It's well understood that concurrency is decomposition of a complex problem into smaller components. If you cannot correctly divide something into smaller parts, it's hard to solve it using concurrency.

But there isn't much detail in slides on how to get parallelism once you've achieved concurrency. In the Lesson slide (num 52), he says Concurrency - "Maybe Even Parallel". But the question is - When and How can concurrency correctly and efficiently lead to Parallelism?

My guess is that, under the hood Rob's pointing out that developers should work at the level of concurrency - and parallelism should be language's/vm's concern (gomaxprocs?). Just care about intelligent decomposition into smaller units, concerned only about correct concurrency - parallelism will be take care by the "system".

Please shed some light.

解决方案

What Rob Pike means

When you have the abstract form of an algorithm in mind, you then have to choose if you will implement it with Message Passing or Shared Memory or maybe Hybrid. You will also have to consider the type of memory access (NUMA, UMA, etc) and the Topology used (Hypercube, Torus, Ring, Mesh, Tree, etc)

This seems a lot of work to someone who just wants something, maybe even simple, done in a parallel way (e.g. parallel for).

And it is a lot of work especially if you change the topology (so you can have all of its advantages).

So you write the parallel code (be it simple or complex) and the VM or compiler will choose what seems to be the best way to go, even running it in a sequential way! (an example would be Task Parallel Library for .net)

Important EDIT:

I should mention that I am talking about concurrency in a program / algorithm and not between independent programs that run in a system.

You said that

It's well understood that concurrency is decomposition of a complex problem into smaller components. If you cannot correctly divide something into smaller parts, it's hard to solve it using concurrency

but it is wrong b/c those smaller components may depend on each other in a sequential manner to complete, so even if you divide into small components, it does not mean you achieve concurrency / parallelism.

In all my classes of parallel and distributed algorithms (both in BS and MS) we never talked about "concurrency we obtained and now let's see how to obtain parallelism". If you use the word concurrency to describe and algorithm then you imply parallelism and vice versa.

In the literature you will also find a thin line between distributed and parallel.

From an algorithmic point of view you can use concurrency, parallelism and distributed and you get the same idea.

From an implementation point of view, if you say "parallelism" you usually intend a program that runs on the local computer or a cluster (Shared Memory communication), and "distributed" when you run the program on a grid (Message Passing communication).

Now, both distributed and parallelism imply concurrency.

I think you should be more skeptical about the precise meaning of these terms because even in the literature (and I talk about people that actually contributed to this field and not just the creation of some language) they are used to express the abstract concept.

Concurrency on an algorithm (be it program) means to have pieces of code that can run independent of other pieces of code, even if they will eventually wait for some other pieces of code (check Amdahl's Law to see exactly the implication of this).

So whenever you have concurrency in an algorithm / program you also have parallelism.

I think it is better to just implement some parallel AND distributed algorithms to better understand the idea behind it. If you know C/C++ you can use OpenMPI for distributed (Message Passing) implementations and OpenMP for parallel (Shared Memory) implementations.

EDIT:

He could also mean concurrency as the abstract principle and parallel as the way it is implemented [Shared Memory, Message Passing, Hybrid between both; Type of memory acces (numa, uma, etc)].

这篇关于并发不是并行性？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！