固然，现在有很多库对当前通用计算平台上这些primitive的手段进行了包装，但绝不是为了简化编程范型，而只是为了让程序员能够更关注于范型本身，而不被当前实现手段的繁琐分散了注意。这两种范型有清晰地目标。

你引用的几段话，也主要是并行系统设计的一些原则、手段以及好的支撑应该做的事情。

虽然Joe Armstrong现在到处宣扬Erlang在并行编程方面的优势，并把并行/并发编程作为Erlang最重要的特征进行推介，但这只是Joe在当前的形势下的一种推销Erlang的手段。从JoeArmstrong的一些严肃的访谈和论文中，可以看出，Erlang最核心的特征是软件容错，Erlang非常优雅、深刻地解决了容错这个问题，从而像并发/并行/分布这些问题都很容易地被同样优雅地解决了。其他语言无论做出怎样的更改、扩展、创新，只要没有正确地解决容错的问题，在这些方面都无法和Erlang相提并论，因为：you can’t fix stupid. 跑题了，呵呵。

……
最好的平行程式不是先問處理器的數量，然後圍繞這個數量來撰寫所有演算法。雖然較低的階層上可能存在這種情況，但程式的高層部分應該製造任務——大量任務，然後讓一些底層結構把這些任務和處理器的數量聯繫起來。顯然，與一個只能製造兩個任務的程式相比，一個能製造數千個平行任務的程式的擴展性要好得多。因此，程式設計時的重點是任務，而非執行緒。
……

Joe Armstrong 在 Joe Thesis CN 中的表述是：

……
巨大的潜在效率——设计成以许多独立的并行进程来实现的系统,可以很方便地实现在多处理器上,或者运行在分布式的处理器网络上。注意,这种效率的提升只是潜在的,只有当应用程序可以被分解成许多真正独立的任务时,才能产生实效。如果任务之间有很强的数据依赖,这种提升往往是不可能的。
……

说法很有一些相似……。

Ulf Wiger 在 Erlang Multicore 中则说：

Erlang SMP ”Credo”
SMP should be transparent to the programmer in much the same way as distribution is,
– I.e. you shouldn’t have to think about it
– …but sometimes you must
Use SMP mainly for stuff that
you’d make concurrent anyway.

诚然 SMP 并不等于 Parallel (或者说只是后者的一部分)，而且“被并发包装起来的并行”也不能涵盖全部情况(…but sometimes you must)。但，除此之外，“SMP should be transparent to the programmer in much the same way as distribution is”。｛对于(Erlang)程序员来说，和分布式(distribution)一样，对称多处理(SMP)也是透明的｝。

这是一个极具诱惑力的范型简化(并发范型包装并行范型)。如果不能这么理解，那又是为什么？(比如，具一个反例？)

不能这么理解。呵呵

这样做的目的是试图(至少是在一部分场景下)简化编程范型(用并发来包装并行)。当然，这必须要建立在这种“简化”本身是可行的基础之上。Erlang 承诺使用面向“并行”编程写出来的程序，在多核的系统中能“自动”的获得多核CPU上的“并发”加速。这是一个很漂亮的“简化”。那么这是否就意味着“底层的并行问题已经被(部分的)包装在并发技术之中”了呢？

当然，一些诸如大规模科学运算一样的应用，是不适用这种简化的。这需要另当别论，但对于“常规”应用而言，是否上面这样的简化就已经足够了呢。毕竟 OpenMP/MPI/CUDA/OpenCL/… 这些“并行”设施和技术都需要相当的精力去啃(尤其是 CUDA 和 OpenCL，好像都是很专注于“数据并行”风格的东西，确实适合数据并行，但并非所有的项目都能通用)。

如果这样说是成立的，那么，比较“接近应用”的程序员们就只需要用“并发”来解决问题，不需要了解太多关于“并行”的背景知识，就能很好的应付大部分的状况。因为“并行”问题已经被“并发”包装起来，被更“接近硬件”的底层程序员们解决掉了。

关键的一点应该是，这些同时运行的任务是为了更快地完成同一个计算的目标呢？还是仅仅是为了能够同时运行以提升系统的响应能力呢？至于任务本身是不是一定相同倒不是关键问题，比如：数据并行中，任务是相同的，但是任务并行中，任务就不相同。

“”"更进一步，如果把“任务”概念扩大化，将“并发”系统在一个单CPU上的“运行实例”当作是“一个(相同的)任务”，通过“并行”手段，让它能在“多个CPU”上得到加速(貌似Erlang的SMP就是如此)。”"”

你这样做的目的是啥。如果一开始设计系统时，就考虑到系统可以在多个CPU上得到加速时，其实这就是一个并行设计的问题了,Map-Reduce框架就是这样一个例子。另外，如果我们开发一个Web server，希望能够同时处理更多的用户请求，在这个场景下，处理用户请求的任务看似也相同，但是这些任务并不是为了一个更大的计算目标服务，某些任务失败仅仅会影响系统的服务质量。此时，我们可以使用多核，但是目标是为了提升系统的可用性和响应能力。这就是并发设计了。

“”"我们是否可以说，并发和并行的研究领域不同，并发要比并行的抽象层次更高(上面的例子实际上是用“并行”技术支持了“并发”系统)，在具体应用中，也更加灵活呢(在有“并行”支持的“并发”系统上，也可以通过将相同的任务分发出去，来达到与“并行”相同的加速效果)？”"”

并行和并发都是编程范型，它们需要的底层基础设施支持有很大的重叠。它们本身我觉得并没有层次高低之分。

dsun :
并行就是为了通过多个处理器并行计算，让一个任务计算的更快。并发就是为了让多个无关的任务同时进行，这里的重点就是根据问题领域和场景区分出哪些是属于一个任务的计算，而哪些则根本就是不同的任务，以及设计的目标是什么。这是谈论并行还是并发的前提。

是否可以认为：“并行”的问题域是研究如何让“一个(相同的)任务”在“多个CPU”上跑得更快，换句话说，它只针对“一个(相同的)任务”，并且和“多个CPU”密切相关；而“并发”的问题域是研究如何让“多个任务”同时运行，它不强调被同时运行的多个任务是“一个(相同的)任务”，也和CPU的数量无关。

这里我不清楚的一点是，“并发”在概念上是否强调了这些被同时运行的多个任务，一定要是彼此不相同的呢？那么，如果某种情况下，这些被同时运行的多个任务其实就是“一个(相同的)任务”，此时，“并发”和“并行”之间的区别是否就只有“多个CPU”这么一条了呢？

更进一步，如果把“任务”概念扩大化，将“并发”系统在一个单CPU上的“运行实例”当作是“一个(相同的)任务”，通过“并行”手段，让它能在“多个CPU”上得到加速(貌似Erlang的SMP就是如此)。从这个意义上讲，我认为这两个概念在问题领域上的差异是：“并行”更强调“多核”，比如“显卡/CUDA/FPGA”的并行之类，似乎更接近硬件；而“并发”则更“抽象”一些，相比“并行”，要离硬件远一些(离软件更近一些)。

我们是否可以说，并发和并行的研究领域不同，并发要比并行的抽象层次更高(上面的例子实际上是用“并行”技术支持了“并发”系统)，在具体应用中，也更加灵活呢(在有“并行”支持的“并发”系统上，也可以通过将相同的任务分发出去，来达到与“并行”相同的加速效果)？

我不确定上面的理解是否正确，让我们把这个问题继续挖下去，搞清楚。

erlang的process更自由，可以通讯，切非对等。

因此在明确场景和目标的前提下，并行和并发其实是非常明确的概念。