嗯……这个问题的复杂度我心里还是有个数的，所以这帖不指望得出答案之类，重在交流讨论。
先说一下我大致的了解吧。因为最近有机会接触到了多核的计算机，所以我也稍微关心了一下。总的感觉是并行似乎真不那么容易，在Stackexchange的未解答率（无人回答或有人答却未被采纳或没有Upvote的问题数比上总问题数）只有35/175.==0.2，这算是相当高了，要知道全站总体未解答率是1325/14474.==0.0915435，一些流行的Tag，比如plot，未解答率只有63./2069==0.0304495。compile在我印象里应该是比较麻烦的，可是一查却发现未解答率才16/149.==0.107383，正好是平均水准。
这175个问题里面得分比较高的问题我也算读了一下，要总结的话，那就是，只有一件事是可以并行的那它才是可以并行的，也就是说，只有当你要做的事是可以互无瓜葛地进行的的时候，Mathematica的并行指令才可以被使用……
说到这里，有件事大家或许会觉得奇怪，那就是，照这个说法，很多的列表操作似乎都应该是可以并行的，为什么实际上并非如此？对于这一点，我也不是很清楚（那你拿出来说干嘛！），但我怀疑这可能和PackedArray（某个和Mathematica的快速计算有着重要关系的数据结构，Mathematica在版本5.2之后快起来很大程度上就是因为它）本身结构的特殊性有关……具体的……我也不是很清楚。但是看看SE上某些高手对SparseArray内部结构的解析帖，我就强烈地感觉，PackedArray一定没那么容易并行。
此外，就我所做的简单的测试而言，并行提速的效果很有限，并且，很多时候都不能和Compile并用，而单用Compile获得的提速往往大幅高于单用并行所获得的。
在这过程中我甚至考虑了要不要转战别的软件。Julia不知道有没有人知道？一个还在零点几版的以高性能计算为目标的语言，研究了半天之后提了这个问题：
http://stackoverflow.com/q/23290917/1551513
结果至今未见回应……我想我的问题问的应该不那么糟，那么，没人给出具体解答的原因，应该还是因为它不那么容易吧……
于是我就试着在更一般的层面上探索了一下这个问题，于是看到了这么一篇文章：
http://www.ltesting.net/ceshi/ceshijishu/rjcsgcsrm/2013/1024/206739.html
七零八落地写了这么多（答了一天题着实有点疲劳），以上就是我所查到的和并行有关的一些信息，欢迎大家交流探讨。

嗯！我特别想看看并行，但是每次都觉得范例华而不实，没大用。而且貌似还出过a++不等于a=a+1的情况。

没有例子无法验证。

目前只会用ParallelTable和ParallelMap，另外不知道楼主有没有在HPC多节点上跑程序的经验，最近比较头疼，找不到好的例子

我是程序里for什么的太多，才去并行，一般没这想法

话说各国人士对并行的热情似乎都在持续高涨，SE已经出现了这个总结帖（浏览量在这不长的时间里已破千……）：
http://mathematica.stackexchange.com/q/48295/1871

其实在超级计算领域，并行已经大行其道很多年了。我觉得串行改并行，首先是创造并行算法，其次是要实现比串行更快的效率（不然该并行没有说服力）。

“说到这里，有件事大家或许会觉得奇怪，那就是，照这个说法，很多的列表操作似乎都应该是可以并行的，为什么实际上并非如此？对于这一点，我也不是很清楚（那你拿出来说干嘛！），但我怀疑这可能和PackedArray（某个和Mathematica的快速计算有着重要关系的数据结构，Mathematica在版本5.2之后快起来很大程度上就是因为它）本身结构的特殊性有关……具体的……我也不是很清楚。但是看看SE上某些高手对SparseArray内部结构的解析帖，我就强烈地感觉，PackedArray一定没那么容易并行。
“此外，就我所做的简单的测试而言，并行提速的效果很有限，并且，很多时候都不能和Compile并用，而单用Compile获得的提速往往大幅高于单用并行所获得的。”
针对这一部分补个例子吧，就用以前讨论过多次的FDTD（时域有限差分算法，一种针对麦克斯韦方程组的显式的有限差分，不过这里用的例子很简单，其实就是一个一维波动方程的求解器……唉呀其实大家不用管这么多，只要知道这是一个由几重循环构成的算法就行了），具体而言是这一帖里的代码：https://tieba.baidu.com/p/2965726742?pid=48424739239&cid=0#48424739239 ，原帖里的代码有一点错误，这里帖上修改后的版本：
ie = 200;
ez = ConstantArray[0., {ie + 1}];
hy = ConstantArray[0., {ie}];
fdtd1d = Compile[{{steps}},
Module[{ez = ez, hy = hy},
Do[ez[[2 ;; -2]] += (hy[[2 ;; -1]] - hy[[1 ;; -2]]);
ez[[1]] = Sin[n/10];
hy[[1 ;; -1]] += (ez[[2 ;; -1]] - ez[[1 ;; -2]]), {n, steps}];
ez]];
sol1 = fdtd1d[1000]; // AbsoluteTiming
(* {0.0150000, Null} *)
很显然，ez[[2 ;; -2]]+=……和hy[[1 ;; -1]] +=……这两行中，“似乎”隐含了可以并行的要素，但是其实上面这段代码是非并行的（大家有多核的电脑的话可以检查下CPU的使用率）。至于为什么……如上面所说，我也不太清楚。
总之先试试把它们强制并行一下吧。这里的两处Part可以用ParallelTable
来代替：
ie = 200;
ez = ConstantArray[0., {ie + 1}];
hy = ConstantArray[0., {ie}];
fdtd1d = Function[{steps},
Module[{ez = ez, hy = hy},
Do[ez[[2 ;; -2]] +=
ParallelTable[(hy[[i + 1]] - hy[[i]]), {i, ie - 1}];
ez[[1]] = Sin[n/10.];
hy[[1 ;; -1]] +=
ParallelTable[(ez[[i + 1]] - ez[[i]]), {i, ie}], {n, steps}];
ez]];
sol2 = fdtd1d[1000]; // AbsoluteTiming
sol1==sol2
(* {29.7740000, Null} *)
(* True *)
……至少在我的双核机子上这段代码是被大幅地拖慢了（顺便这里用Table的话其实比较快）
上面没有用到Compile，因为ParallelTable压根不在这个单子里：http://mathematica.stackexchange.com/a/1101/1871 当然这里可以实际试试：
ie = 200;
ez = ConstantArray[0., {ie + 1}];
hy = ConstantArray[0., {ie}];
fdtd1d = Compile[{{steps}},
Module[{ez = ez, hy = hy, ie = ie},
Do[ez[[2 ;; -2]] +=
ParallelTable[(hy[[i + 1]] - hy[[i]]), {i, ie - 1}];
ez[[1]] = Sin[n/10.];
hy[[1 ;; -1]] +=
ParallelTable[(ez[[i + 1]] - ez[[i]]), {i, ie}], {n, steps}];
ez]];
sol3 = fdtd1d[1000]; // AbsoluteTiming
sol1 == sol3
结果不贴了，总之编译时出现了警告，最后速度也没提升，有兴趣的可以用CompilePrint检查下结果。
例子到这里就结束了……等下，你不是说“就我所做的简单的测试而言，并行提速的效果很有限”吗？这根本就没有提速吧？！对此，我得说，我可能是产生了一些令人遗憾的记忆偏差（殴）……然后，其实可能的“并行方案”并不止这一种，但是此刻我又燃烧殆尽了，所以还是下一次再继续实验吧……

说到并行，这里再补一个链接：
http://mathematica.stackexchange.com/a/50992/1871
这位在这里给出了一个c++的解法，虽然我不会c++，但是大致能看出，这和他楼上的那个Mathematica解法在算法上是大同小异的，但是，这段c++代码是并行的，并且在他的12核机子上比Mathematica版本快了一个数量级……而Mathematica似乎不能简单地把相应的代码弄成并行的……

mma的神经网络基于mxnet 而mxnet在计算时是创造一个计算图了的 并对算法进行了并行优化的编译 这能不能算另辟蹊径呢