其实差别不是很大, mpi现在也对共享内存系统优化了. 关键还是看你代码怎么写.
有心的话可以先了解一下两种各自的优点和缺点. 这方面可以翻翻书也可以在网络上找找. 我在pfan也写过类似的东西, 不知道沉哪里去了.

[quote]其实差别不是很大, mpi现在也对共享内存系统优化了. 关键还是看你代码怎么写.
有心的话可以先了解一下两种各自的优点和缺点. 这方面可以翻翻书也可以在网络上找找. 我在pfan也写过类似的东西, 不知道沉哪里去了.[/quote]
貌似现在大家对写多核并行的程序没多大兴趣，讨论的人不多嘛！

不是一般算法自然地就能推广到并行, 所以并行的时候为了提高效率很可能要换并行算法. 就算不在原来算法的基础上修改:
mpi 要修改部分甚至大部分的代码. omp 如果只是循环并行之类的改动比较小但效率未必高,效率不佳的时候还是要考虑改代码. 在相同的算法下, omp消耗比较小, 共享内存方式在线程之间交换数据比较高效.
要改代码不是人人都愿意, 很多人是用别人或前人的代码算算弄个数据写文章毕业就够了, 感兴趣的人不是特别多也很合理. 而且学并行不是学会用并行语句就够要学好还是要花些时间多看几本书的,当然这个看需求,有些几句简单并行就非常好的效果, 只要觉得加速比满足了也可以.

[quote]不是一般算法自然地就能推广到并行, 所以并行的时候为了提高效率很可能要换并行算法. 就算不在原来算法的基础上修改:
mpi 要修改部分甚至大部分的代码. omp 如果只是循环并行之类的改动比较小但效率未必高,效率不佳的时候还是要考虑改代码. 在相同的算法下, omp消耗比较小, 共享内存方式在线程之间交换数据比较高效.
要改代码不是人人都愿意, 很多人是用别人或前人的代码算算弄个数据写文章毕业就够了, 感兴趣的人不是特别多也很合理. 而且学并行不是学会用并行语句就够要学好还是要花些时间多看几本书的,当然这个看需求,有些几句简单并行就非常好的效果, 只要觉得加速比满足了也可以.[/quote]
恩，并行属于底层的东西，这个本来不应该属于程序员研究的内容，程序员只要把计算任务写出来就好了，到操作系统层面就不应该让程序员在操心了。现在的操作系统和开发工具需要彻底的改造，来适应并行时代。

[quote][quote]不是一般算法自然地就能推广到并行, 所以并行的时候为了提高效率很可能要换并行算法. 就算不在原来算法的基础上修改:
mpi 要修改部分甚至大部分的代码. omp 如果只是循环并行之类的改动比较小但效率未必高,效率不佳的时候还是要考虑改代码. 在相同的算法下, omp消耗比较小, 共享内存方式在线程之间交换数据比较高效.
要改代码不是人人都愿意, 很多人是用别人或前人的代码算算弄个数据写文章毕业就够了, 感兴趣的人不是特别多也很合理. 而且学并行不是学会用并行语句就够要学好还是要花些时间多看几本书的,当然这个看需求,有些几句简单并行就非常好的效果, 只要觉得加速比满足了也可以.[/quote]
恩，并行属于底层的东西，这个本来不应该属于程序员研究的内容，程序员只要把计算任务写出来就好了，到操作系统层面就不应该让程序员在操心了。现在的操作系统和开发工具需要彻底的改造，来适应并行时代。[/quote]
那你恐怕要等很久很久一段时间了. 以往在自动并行方面的努力到现在也未能见到什么成效. 并行我不觉得是底层的东西. 线程或者进程的开销那么大, 并行粒度那么多, 独立任务划分情况那么多种类. 除非将来出人类智慧级别的编译器.
如果楼主觉得并行不值得深入一步了解的话, 还是退回去优化好串行程序吧, 串行程序做得好, 效率也很高的.

[quote][quote][quote]不是一般算法自然地就能推广到并行, 所以并行的时候为了提高效率很可能要换并行算法. 就算不在原来算法的基础上修改:
mpi 要修改部分甚至大部分的代码. omp 如果只是循环并行之类的改动比较小但效率未必高,效率不佳的时候还是要考虑改代码. 在相同的算法下, omp消耗比较小, 共享内存方式在线程之间交换数据比较高效.
要改代码不是人人都愿意, 很多人是用别人或前人的代码算算弄个数据写文章毕业就够了, 感兴趣的人不是特别多也很合理. 而且学并行不是学会用并行语句就够要学好还是要花些时间多看几本书的,当然这个看需求,有些几句简单并行就非常好的效果, 只要觉得加速比满足了也可以.[/quote]
恩，并行属于底层的东西，这个本来不应该属于程序员研究的内容，程序员只要把计算任务写出来就好了，到操作系统层面就不应该让程序员在操心了。现在的操作系统和开发工具需要彻底的改造，来适应并行时代。[/quote]
那你恐怕要等很久很久一段时间了. 以往在自动并行方面的努力到现在也未能见到什么成效. 并行我不觉得是底层的东西. 线程或者进程的开销那么大, 并行粒度那么多, 独立任务划分情况那么多种类. 除非将来出人类智慧级别的编译器.
如果楼主觉得并行不值得深入一步了解的话, 还是退回去优化好串行程序吧, 串行程序做得好, 效率也很高的.[/quote]
啊，我不是觉得不值得，而是觉得现实应该改变。现在的项目都往并行发展，我也决定不了。就是觉得计算机系统的控制方面走到了一个拐点。

并行计算其实已经有几十年历史了. 翻翻mpi, omp的历史也10多20年(具体我没查过,只是看第一版标准就是很早之前的). 现在科学计算比较多的就这两个.
自动并行的项目确实是有的.但是到现在还没有看到一个能够让人接受, 或者在特定的情况下也能提供高效的并行. 这个你可以试试intel编译器的Qparallel,那个就是自动并行.其实不追求很高效那就不需要换并行算法, 在串行代码中找热点进行并行, 这就是omp在多核心单机系统中易用而被推荐的原因.
不管你希望现实怎么样, 我所知道的可预见将来很长一段时间不会有那么高智能的编译器, 等这样的东西恐怕都够几个博士毕业了. 再者有高智能编译器程序员都可以下岗了. 这个话题就好像机器人的智能是否能超越制造它的人类一样复杂.
现在热门的是异构并行, 用显卡的gpu来做计算. 有兴趣可以留意一下.

楼主期盼的东东是存在的，其实就是CoArray、HPF等。
不过个人认为呢，有些东西完全可以认为它就是语言的一部分，也许你感觉不必关心，但实际不然：）
举个例子：
设你是做流体力学的。
你现在有一个使用有限体积法来解的方程，假设它是最简单的一维稳态问题吧。
首先你需要网格划分：这个需要一定的算法，但很简单；
然后你需要形成方程组：这个也非常简单；
接下来你需要解方程组：这个相对就麻烦些了，如果你不告诉计算机具体怎么算，难道它能自动用TDMA帮你算？不太可能吧：）
再接下来的事就是后处理：这个也简单：）

而解方程组，如果计算量很小，串行的TDMA非常高效！但计算量如果相当大呢？
您学串行的TDMA和学并行的TDMA一样是要付出时间和精力的吧：）

当然，您要是用现成的TDMA求解程序源码来解决问题，只要输入参数不变或仅做很小的变动。你需要了解这个求解器是串行或并行么：）不需要啊：）

cgl_lgs兄 加头像了啊.
CoArray记得是fortran2008标准的东西. 只是对数组进行操作, 可以满足部分人的需要. HPF高性能fortran我只在书本见过简单介绍,在我理解里面它已经死掉了,呵呵.
楼主想想你要做到什么程度, 打算投入多少时间. 我几年前刚学mpi和omp不久帮一个师妹弄并行, 他的程序主体就几个可以相互独立的循环. 所以只用了omp里面简单的循环并行. 加上跟串行比较的调试时间不到一个小时. 在4个核心的服务器上跑, 效率有3倍多. 她满意了我也不想去并行其他了.
你想学但又不知道是要学通它还是只需要简单提速? 还有对于一些比较复杂的问题往往又比较高效的并行算法,那个几乎是要重写部分代码的. 是否值得是个问题. 有时候能解决问题就行,不一定都希望花时间去弄并行.

咋的头像又换回来了啊? 那个很帅啊...