j******n
发帖数: 108 | 1 你觉得在所有的 application 中，能并行的多，还是串行的多？
如果能并行的计算，特别是个人计算，真的那么普及的话
multi-core cpu 的前景显然更加明朗
所以我才说 cloud computing 目前的定位在于大规模数据分析的
这些分析多数都比较容易并行处理，比如 list intersection, aggregation
非要把字处理、视频解码移到 cloud 里，其实用的是存储，不是计算
这些计算在 cloud 里和个人电脑里没有什么区别 |
|
a***y
发帖数: 19743 | 2 ☆─────────────────────────────────────☆
JunPengJia (贾君鹏(Junpeng Jia)) 于 (Fri Oct 22 17:01:28 2010, 美东) 提到:
首先要批评dsb的逻辑混乱，说PC open没错，但那是IBM open，不是微软Open，而IBM
已死，说Open就牛逼是讲不通的。
好下面开始胡说八道。
很久很久以前，毛主席还在，林副统帅刚刚去世的时候，美帝国主义的Intel公司整出
了4004CPU，一帮哥们闲得没事干整出了不少蛋疼的“电脑”，一般就是几盏灯一闪一
闪，没有键盘也没有鼠标，也没有显示器，也没有……反正都没有。当时还有摩托罗拉
做CPU
后来杀出了乔布斯教主，教主本人并不是geek，也从来不是geek，但教主本人极具忽悠
天赋，骗超级geek 沃兹尼克Wozniak搞了Apple I，而教主牛逼之处在于从一个消费者
角度看待问题，坚决不同意用小灯（没人会用）或LED面板（买不起）做显示器，而是
可以直接用电视。于是成功卖出若干。在华国锋主席的时代，教主卖出了200台左右，
一台卖666.66刀... 阅读全帖 |
|
T**********n
发帖数: 480 | 3 越快越好是没错的
但是并行程序设计这种事是不应该由程序员来做
最高顶多做到编译的层次，比如HPF这样的倒是有可能
举一个可能不恰当的例子
其实OS的IO都是异步的，但是程序员打开文件，读，写
都不会用异步的写法issue一个操作，等待一个回调
这是核心态的事情，在用户态做不能带来任何好处
并行程序也是，就算SMP全面普及，顶多是一个支持并行的VM上面继续跑串行程序 |
|
J*********n
发帖数: 370 | 4 记得看过一篇说并行当前状况的文章，具体内容不带记得了，大意是说目前并行在很大程度上只是在现有计算机体系架构上做的一些Ad hoc的小动作，并没有从思想上得到突破。如果真的能得到突破，那么计算机无论从理论到应用，硬件到软件都将发生翻天覆地的变法，IT行业可能因此而重新洗牌
不知是不是真的，大家也来说说并行吧，欢迎您的高见 |
|
s****d
发帖数: 56 | 5 Hadoop的最大优点是 fault tolerance， 如果你有上百台普通机器，这些机器都不是
很稳定，并且是进行一过性数据分析，用Hadoop
如果你是要在固定的数据上做不同的OLAP，建议用并行数据库，比如Teradata
Hadoop：数据加载快，但处理执行慢；每次这些都要重新加载所有数据
并行数据库：数据加载慢，但一旦加载完成，由于索引和查询优化，反复查询处理就快
了。不过并行数据库fault-tolerance不如Hadoop强 |
|
r**********e
发帖数: 2821 | 6 凡是支持并行的程序都可以，比如计算，video制作，现在市面上支持多核的应用软件
不多。但越来越多的程序支持并行了，据说directX11也支持并行。另外多核多任务爽
，比如软解蓝光，cpu占有率低，还同时用电脑干别的。 |
|
h****r
发帖数: 258 | 7 Intel众核架构芯片首秀 单颗破万亿次计算
转自：驱动之家
作者：上方文Q
除了介绍Xeon E5系列，Intel今天还首次展示了基于众核心(MIC)架构的新型协处理器
“Knights Corner”，根据DGEMM测试其双精度浮点性能已经超过一万亿次每秒(
1TFlops)，这也是历史上第一次做到这一点的处理器芯片。
相比之下，目前最强大的专用并行加速器是NVIDIA Tesla M2090，双精度浮点峰值性能
665GFlops(6650亿次每秒)，大大低于Intel KNC。 1.jpg
回首1997年，Intel曾经利用9298颗Pentium II Xeon处理器打造了第一台计算性能突破
TFlops大关的超级计算机“ASCI Red”，整套系统占据72个机柜，而KNC只需要一个PCI
-E扩展插槽就可以了。
KNC协处理器将是第一款投入商用的MIC架构产品，计划采用22nm Tri-Gate工艺制造，
核心数量超过50个，频率1.0-1.2GHz。通过搭配同步推出的Xeon E5系列，KNC既可以利
用专为高度并行负载设计的新架构提供超高性能，又可以兼容现有的x86编程... 阅读全帖 |
|
h******6
发帖数: 2697 | 8 这个完全是看原来的算法可并行化的程度 原算法并行度高的改成GPU的程序优化之后几
百倍的提速是很常见的 另外 这个也取决于你用的什么GPU和什么CPU来比 这里的问题
并不是简单地你把随便一个算法或者程序拿过来放到一个GPU上跑测下时间 然后拿到
CPU上跑测下时间 然后比较两个时间
GPU计算现在还没办法普及 最主要是因为把一个算法在GPU上实现需要很有经验的程序
员才行 涉及到重新设计算法以及内存使用上的分配 目前的几个能自动把串行程序编译
成并行程序的compiler都效率非常低下 所以单纯问GPU计算比CPU计算快几倍是没有意
义的 |
|
m****s
发帖数: 1481 | 9 如果算法可以并行的话，我推荐用gpu，相对于cpu搞并行用多线程比如mpi这些，gpu跑
并行的上手难度小多了。而且速度提升还是很大的，特别是不需要非常高精度的。
我之前把组里的通信仿真从c转成opencl，速度提升有10-40倍，当然是跑的单精度，因
为通信的最终硬件实现只有6-7位，所以单精度，甚至半精度都是绰绰有余的。其他的
科学计算我就不确定了，不过即使都是跑双精度，gpu一般也能比cpu快5-10倍，我是说
同价位的一个cpu和一个gpu比。
当然最快的还是fpga，不过那个开发起来费时间一些，design重复利用率也不高，不像
code |
|
t*****z
发帖数: 1598 | 10 楼上的仁兄说得是。你先看看能否并行再作定夺吧。方法很简单，把程序跑上，是
Windows就按Ctrl+Alt+Del，不是Windows就用top命令，就可以看出CPU利用率了。
如果你的程序可以并行，并且可以利用很多个线程（至少8个）；或者虽然不能并行，
但是你每次都会开好几个进程分别计算，那么你看中的机器还有可取之处（passmark评
分8220），比你原来的单颗i5-2320好那么一截（5665），但是还是不如现在的主流个
人电脑。只是仗着工作站的稳定性和ECC，那就认了。
如果只能单线程，那这个配置（1220）比你原先的（1672）还不如！你的老板岂不是要
抓狂。
别去纠结什么频率了。那个数字在不同系列CPU之间基本没有可比性。非要追求高频的
话可以上AMD的FX-9590，那可是八核5GHz的神器哦，价钱才300，你和你老板一定会
high。这至少比你看中的E5里的最低端的CPU要好不少。 |
|
d***a
发帖数: 13752 | 11 专业计算里，很多很多了，不说算几天，几个星期甚至几个月的都有。
另外有些计算，无法做成分布式并行，或者要求很大的内存，那么自己买好机器比E2C
更快。
E2C适合突发式的大规模分布式并行计算。比如说数据来了，很短时间内就要出结果，
要用几千上万个node并行，就很适合E2C。如果自己（公家）搞一个大的cluster，利用
率很低，就太不合算了。
算, |
|
n******7
发帖数: 12463 | 12 就是跟串行的比较
1个core 要200h
64个core 只要1h
明显不对
不过paper已经发了
也没人管了
我感觉并行最关键的还是问题的领域
我们领域的问题基本都是高度可并的
其实单机并行我已经觉得很爽了
现在版上的千元双路机都有16核32线程
单机并行就可以缩短运行时间一个数量级
很客观了
也准备找机会玩玩MPI，一直对分布式计算很有兴趣 |
|
m*****r
发帖数: 3822 | 13 双路i7的机器，相当于有8个cpu。一些并行程序是正常的，比如开8个并行
系统load为~8，top里八个进程各位99%cpu占用。但是某个程序很奇怪，
就算只开1个进程，系统load都会很高，这个进程的占用率也会达到800%。如果多个
进程并行的话非常慢。感觉好像是一个进程就占满所有cpu。
因为有些程序表现正常，系统配置应该没有问题。但是什么情况下会导致以上这种现象？
谢谢 |
|
X******U
发帖数: 137 | 14 【 以下文字转载自 Windows 讨论区 】
发信人: XIAOZHOU (liszt), 信区: Windows
标 题: 问一个外行的问题,关于mpi
发信站: BBS 未名空间站 (Thu Feb 19 11:34:13 2009), 转信
请问有没有办法利用双核的cpu同时运行两个进程作并行计算?
我对并行计算完全是外行.现在的程序根据说明书支持mpich作并行计算,不知道在同一
台pc上是否可行?两个进程对我来说足够了,我只想节省一些时间,充分利用一下资源.
希望有经验的能不吝赐教.谢谢! |
|
w***g
发帖数: 5958 | 15 如果bottleneck在网络带宽，那么这种pipeline对提高throughput不会有明显的区别。
但是pipeline作为一种经典的并行化方法有它自己的好处。就你这个应用而言，我能想
到的一个明显的好处是可以把lock contention限制在读写缓冲区那段代码里。相比于操
作系统处理多个连接而言，你针对特定应用写的缓冲区代码会简单很多，这样有助于提
高并行度。如果哪天你们把带宽这个bottleneck给优化掉了，那么这种好处就会体现出
来了。 一般而言，pipeline在performance上的好处主要是提高并行度和增加cache
locality。 |
|
y**b
发帖数: 10166 | 16 看来这个理解是对的，至少是经验之谈。
实际上我将unordered_set全都替换成vector，在损失功能情况下测试，发现内存消耗
几乎不变。可见问题不在于我使用了那种数据结构，而是这些数据serialized之后通过
mpi传输的时候，mpi底层实现要消耗大量内存。mpi有些参数可以调整内存消耗，但也
非常有限。
当然我还有其他解决办法，就是采用并行数据输出，整个并行计算结束之后用另外的程
序来合并数据、清楚冗余数据，免得干扰并行计算本身。 |
|
c******o
发帖数: 1277 | 17 这个没有detail很难说，只能说非常大致感觉是这样的。
先把各个“角色”抽象成为一个type,这个type包括了一个abstract trait， 和几个
extend的 case class，取决于model可能很复杂，里面可能包括了状态。
角色之间／和环境的互动抽象为function
对于可读性，我并不认为FP一定好
scala好玩的是可以用 主谓宾，定状补来写code,如果需要
对于并行处理
imperative:
player1.attack(player2)
player1, player2 内部状态改变
player1.hitByThunder()
player1 内部状态改变
两个动作无关的话也不好并行
FP:
attack(player1, player2) => (newplayer1, newplayer2)
hitByThunder(player1) => newplayer1
如果两个动作不相关, 它们都返回Future type， 可以直接
for (
a1 <- attack...
a2 <- hitByThunder...
) yield (... 阅读全帖 |
|
c******o
发帖数: 1277 | 18 这个没有detail很难说，只能说非常大致感觉是这样的。
先把各个“角色”抽象成为一个type,这个type包括了一个abstract trait， 和几个
extend的 case class，取决于model可能很复杂，里面可能包括了状态。
角色之间／和环境的互动抽象为function
对于可读性，我并不认为FP一定好
scala好玩的是可以用 主谓宾，定状补来写code,如果需要
对于并行处理
imperative:
player1.attack(player2)
player1, player2 内部状态改变
player1.hitByThunder()
player1 内部状态改变
两个动作无关的话也不好并行
FP:
attack(player1, player2) => (newplayer1, newplayer2)
hitByThunder(player1) => newplayer1
如果两个动作不相关, 它们都返回Future type， 可以直接
for (
a1 <- attack...
a2 <- hitByThunder...
) yield (... 阅读全帖 |
|
g*****g
发帖数: 34805 | 19 不同车次可以并行，同一车次不并行比较公平。就是按时间顺序读出来，顺序处理。显
然你要并行也可以，就是没那么公平。 |
|
c*******9
发帖数: 9032 | 20 你不能用简单例子说明。大项目你都这么编不是普通程序员能做到的。
否则大家都用汇编好了，简单的算法汇编也有现成的。CPU指令支持并行，不等于应用
实现并行就容易，OpenMP也只适合某一类应用。而且，fp也不一定就满，haskell一般
也只比C慢50%，有的应用比c写的还快（你可以说C的没优化，但手工优化哪那么容易）
。Java也要性能问题，也不妨碍广泛应用。fp不普及不是因为性能，而是概念抽象一点
，没有数理逻辑训练的人不适应，但并行方面的简易或许可以抵消这个代价。 |
|
c*******9
发帖数: 9032 | 21 说的是多核。openmp不适合复杂同步的应用，而且c／C艹在并行和非并行切换也不方便
，会杀鸡用牛刀。用haskell就可以先不管并行，需要时候简单加上不影响其他代码。 |
|
T********i
发帖数: 2416 | 22 个人认为FPGA有些是忽悠，有些是鸡肋。
先说说FPGA在金融领域干些啥？
1. Market Data Feed handler
2. Order entry
3. Risk check
个人认为，FPGA在单线程应用上，并不比Intel Xeon占优势。Xeon多执行单元，大流水
，高性能cache，基本上已经性能到极限，何况主频超过3G，也高于FPGA。
FPGA优势在于大规模并行，遗憾的是，交易领域并行度达不到那么高。确实，Market
Data可能有多个multicast channel，可能能够并行解码。但是单个multicast channel
必须串行解码因为消息之间有数据依赖。而且对于股票数据，基本上是c structure，
没啥可解的。
有人认为FPGA能够节约CPU的core。这个也没啥意思。关键是通过PCI-E bus，这是很大
的瓶颈。Solarflare基本上已经到了极限，不是其ASIC处理TCP/UDP stack不够快，而
是PCI-E增大了latency，这个基本无解。
个人认为FPGA唯一有可能比Xeon快<5us的地方在于，如果纯FPGA不需要通... 阅读全帖 |
|
T********i
发帖数: 2416 | 23 很简单，这个系统是耦合系统，不是分布系统。根本不能分布。
goodbug给我提的那些苛刻要求最后都get to him。
耦合表现在：
1. 支持联票换乘
2. 支持All-or-none团体票
3. 支持以上组合
有票要100%出票。
因此，是全国一盘棋。他不能无限并行。即使要并行，也要有一个调度器。调度器是单
线程的。每个请求调度以前要看一眼。这个看一眼就是数据依赖性。100K/s读都很难撑
得住。
如果没有这个依赖性，当然可以几乎无限并行（按照车次）。但是这是一个彩票系统了
。 |
|
d****i
发帖数: 4809 | 24 多谢指出问题，正如大神Linus最近指出的，忘掉操蛋的并行计算吧，并行计算不是
silver bullet，大部分时候我们并不需要并行也过得很好！java 8的stream底层的实
现就是fork-join pool，就是把他变成了看起来的语法糖而已。 |
|
|
z****e
发帖数: 54598 | 26 系统什么时候并行你不需要操心
反正你的每一个verticle对象只会被一个thread所执行，在同一个时间点内
不会互相干扰，所以你不用去管vert.x什么时候做并行操作，什么时候不做
这个dispatch由vert.x来搞
所以哪怕你启动的只有一个verticle，只监听一个port
也还是会有多个threads来调用这个verticle的instances，java里面就是内存对象
然后当并发量大的时候，thread就会多起来
然后不同的threads如果调用同一个verticle
那么他们会分别持有这个verticle的不同instances
每一个thread分配一个instance酱紫
你就当你写的verticle是运行在单线程环境中就好了，并行的事，vert.x会帮你搞定
当然一个重要前提就是，你不能直接share object between threads
如果需要在不同threads中分享数据，则你需要看用bus
另外我记得他们好像提供了一个内存共享的map好像，你要自己查查 |
|
N********n
发帖数: 8363 | 27 把原始数据拆成N块。各分块并行计算出MAX之后再汇总找出众MAX之中的MAX。
最基本的DIVIDE & CONQUER & AGGREGATE思路。具体编程要看你的硬件是
MULTI-CORE，MULTI-CPU还是MULTI-SERVER。另外也要看你的编译器针对硬
件生成并行代码的能力，总之关键在并行。 |
|
|
|
|
z****e
发帖数: 54598 | 31 我反正用hadoop的过程中还没遇到过用快排的地方
现在基本上都不sort了，要sort的话，建index的cache就好了
不需要等到用的时候再sort，那多慢呀，而且又吃内存
多sort几下，整个系统就别干其他事了，光忙着sort了
而且快排能并行么？我好像是不太记得怎么做快排的并行
所以感觉做hadoop什么不合适，terasort第一步就是并行化处理
不过说到这里我突然想起来，terasort跟quicksort倒是有些共通之处
可以按照terasort的方式做，但是那样就是terasort而非qs了 |
|
z****e
发帖数: 54598 | 32 你说的呢
无非就是单机变成多机
然后遇到了分布式事务的问题
这个的确是问题，也的确单机上不存在
老魏的方案是干脆退回到单机，能并行的部分无脑并行
不能并行的部分，就塞给单机，这个属于回避问题
但是人类进步的动力在于，遇到了困难
遇到了难题，你要解决难题，而不是回避难题
所以你的例子很好，那如何解决呢？
尤其是如何又快又好滴解决呢？
有很多种方式，我已经说了一种最简单的
请问你有其他办法嘛？
其实看懂了这个，就会觉得蓝胖的那几篇论文很扯蛋
因为回避了一些重要的问题，比如公平性问题
其实没有觉得完美的solutions
所以才有趣的，如何取舍呢？
这就需要你罗列出来了，这个才是软件的问题好吧？
算法，软件，programming多数时候在解决这些问题
而不是简单的计数器 |
|
T********i
发帖数: 2416 | 33 本文的目的在于帮助程序员树立正确的世界观和人生观。如果感觉颠覆感太强烈，主要
原因也不是你学错了，而是你的老师教错了，或者你的教科书写错了。
1. 确定图灵机和不确定图灵机，
根据计算机科学理论，图灵机（Turing Machine）是计算机的抽象模型。现有的计算机
的计算能力（不是速度，而是理论上能够求解数学问题的能力）不会超过这个模型。
确定图灵机（DTM）是图灵机的一个经典描述，是一个单线程的图灵机。
不确定图灵机（NTM）可以看作是一台有无穷多单线程的图灵机组合的图灵机。也就是
有无限并行能力的图灵机。
可计算性理论可以证明，NTM和DTM是等价的。也就是说DTM可以完全模拟NTM。NTM能够
计算的题目，DTM也必然能够计算，虽然可能速度上比NTM慢很多倍。
2. 冯.诺依曼（Von Neumann）计算机体系就是DTM
现在的计算机都是冯.诺依曼体系。即使多核计算机，本质上也就是有限个DTM组合。和
NTM相距甚远。注意NTM是有无限个核心的无穷并行的计算机。
3. 什么是NTM？量子计算机才是
有一种理论认为量子计算机利用平行宇宙进行超大规模并行计算，也... 阅读全帖 |
|
T********i
发帖数: 2416 | 34 本文的目的在于帮助程序员树立正确的世界观和人生观。如果感觉颠覆感太强烈，主要
原因也不是你学错了，而是你的老师教错了，或者你的教科书写错了。
1. 确定图灵机和不确定图灵机，
根据计算机科学理论，图灵机（Turing Machine）是计算机的抽象模型。现有的计算机
的计算能力（不是速度，而是理论上能够求解数学问题的能力）不会超过这个模型。
确定图灵机（DTM）是图灵机的一个经典描述，是一个单线程的图灵机。
不确定图灵机（NTM）可以看作是一台有无穷多单线程的图灵机组合的图灵机。也就是
有无限并行能力的图灵机。
可计算性理论可以证明，NTM和DTM是等价的。也就是说DTM可以完全模拟NTM。NTM能够
计算的题目，DTM也必然能够计算，虽然可能速度上比NTM慢很多倍。
2. 冯.诺依曼（Von Neumann）计算机体系就是DTM
现在的计算机都是冯.诺依曼体系。即使多核计算机，本质上也就是有限个DTM组合。和
NTM相距甚远。注意NTM是有无限个核心的无穷并行的计算机。
3. 什么是NTM？量子计算机才是
有一种理论认为量子计算机利用平行宇宙进行超大规模并行计算，也... 阅读全帖 |
|
发帖数: 1 | 35 R的并行计算挺方便的，parallel，doparallel，foreach
有些库自身就提供并行化计算，比如forecast，caret
apply系列并不真的并行化，只是写code简介
vectorization有一定帮助，但是不解决根本问题
最终要想性能上去还是要用c/c++写库然后wrap
R的最大优势就是几乎所有最新的统计算法都能第一时间登陆这个平台
R唯一的缺憾是只能内存操作，但是现在也有大数据平台的接口和用硬盘做swap的库
另一个之前的午后是深度学习库，现在mxnet有Amazon撑腰了，而且对R的支持还不错。 |
|
s******u
发帖数: 501 | 36 没拿TBB写过并行程序，所以不敢说。我听说的是TBB更适合task并行，而不是data并行
，所以也许并不适合通常的数值计算。当然只是听说，不负责任，呵呵 |
|
a*****s
发帖数: 1121 | 37 单从你的数据量上看，九个节点已经不错了。aws上的都是VM instance，100个不一定
有你的9个物理机器快。
wdong分析的很到位，个人感觉你的程序需要并行，spark有两级并行，选择executor的
数量，然后，选择每个executor上多少parallelism，spark prefer 大内存fat node，
如果你的机器内存不大, 恐怕效果一般，跟写mapreduce相差不多（你只是parsing），
如果可能，用SSD替换硬盘，加大内存。检查网络速度，是10GE还是1GE，压缩你的数据
（HDFS支持snappy）
用AWS从S3到本地HDFS就把你时间耗去大半，不划算。
光spark的tuning就有很多可做的，而且用spark的目的也就是为了并行。
楼主贴些详细信息，大家也可以帮你分析分析 |
|
d******c
发帖数: 2407 | 38 函数式一大好处是可以比较容易引入并行。能够几乎不改变代码就支持并行就是新鲜高
级的东西，10年前有吗？各种语言和库都支持吗？天底下没有新鲜事，但是很多东西的
做法不同，context不同，效果完全不同。
你给我来个python list comprehension并行看看。GIL从根子上就限定了python，
python作者自己说了一大堆python不是函数式的话，实际上他就不怎么喜欢。看他的文
章，完全是因为别人要，别人加的，他是持保留态度的。
I have never considered Python to be heavily influenced by functional
languages, no matter what people say or think. I was much more familiar with
imperative languages such as C and Algol 68 and although I had made
functions first-class objects, I didn't view Python as a f... 阅读全帖 |
|
d***a
发帖数: 13752 | 39 可能程序或运行环境有问题，需要针对并行性能来调一下。数据量足够大了，并且没有
计算依赖性，这是非常适合并行的情况。
多进程运行的做法，只是为了短平快，这种特殊情况下可以一下子搞定，但性能上不会
比自己写并行程序更快（在最好情况下）。
。。 |
|
x****u
发帖数: 44466 | 40 CPU里面的很多高成本组件只是针对非充分并行优化的串行程序才有意义的
比如流水线，分支预测，乱序执行，各种重命名，微指令，cache等等
如果计算任务高度适合并行化，那设计思路要推倒重来
归根结底还是因为目前主频撞到南墙了，只能加大并行度了 |
|
d***a
发帖数: 13752 | 41 我同意这个观点。Python搞并行反正是不行，不如用C/Fortran和pthread/MPI/PVM来搞
。Python的一些模块，内部可以用并行来实现。Numpy内部应该是可以用上多核并行。 |
|
X******U
发帖数: 137 | 42 请问有没有办法利用双核的cpu同时运行两个进程作并行计算?
我对并行计算完全是外行.现在的程序根据说明书支持mpich作并行计算,不知道在同一
台pc上是否可行?两个进程对我来说足够了,我只想节省一些时间,充分利用一下资源.
希望有经验的能不吝赐教.谢谢! |
|
c*******h
发帖数: 1096 | 43 设计一个可并行的算法。即使新算法比老算法在非并行的情况下看着要傻，但是可能并行
一搞，优势就出来了 |
|
t********t
发帖数: 5415 | 44 amdahl's law是永远正确的吧...一个程序如果有一部分是不能parallelize的话怎么整
也不可能比这个还快啊。
通用程序本身可能是串行的，但是程序处理的数据可以并行处理啊，loop unrolling不
就是个例子。巨量并行也就是在巨量数据的时候有价值，否则各个进程/处理器之间通
信就把效率吃掉了。而且还得考虑dependency。acectl的看法我觉得有道理，
dependency是由data source决定的，你作为一个processor再怎么搞也不能把他搞没，
能做的只是把dependency造成的影响尽量降低。而且并行这东西搞出来的初衷不就是面
对巨大数据的吗？
工程上的要求以现在的技术个人觉得其实都不算太难解决了，但这是engineering不是
science，要考虑现实情况，更多的时候还是在研究怎么把CPU/GPU/FPGA等等的最后一
点效率榨干吧...个人认为quantitative approach其实更多的时候是被现实逼出来的一
种验证方法，对我而言他只是让我意识到了在系统里什么地方会出瓶颈，真到具体计算
CPI之类的时候都是脏活累活了。当然我 |
|
k*********g
发帖数: 791 | 45 有限元方法的并行效果特别差；
并行的最核心的问题；
根本不是你老师教你的、或者你可以在literature里看到的那个；
即如何降低communication的比率；
并行的最核心的问题是；
如何保持原有的单处理器状态下的离散系统的那些良好的性质；
有限元单元之间的dependency非常高；
所以在以上2方面做得都非常差；
discontinuous spectral element method is the one for everything；
跟 dsem 比，有限元跟垃圾没啥区别；
别的不说，在单处理器情况下，dsem就比有限元快100倍； |
|
R******9
发帖数: 267 | 46 根据工作需要，中国科学院力学研究所非线性力学国家重点实验室对外公开招聘项目聘用
人员一名。详细情况见www.imech.ac.cn 。
现将有关事项公布如下：
一、部门：中国科学院力学研究所非线性力学国家重点实验室
二、工作职责：
1、负责多尺度力学计算平台的建设工作；
2、负责多尺度力学计算平台的管理及日常维护；
3、协助科研人员及学生进行并行程序的移植、修改、调试及效率调优；
4、完成实验室及课题组交给的其他与计算平台有关的工作。
三、应聘条件
1．热爱本职工作、爱岗敬业，具有优秀的思想品德、职业道德和团队精神；
2．工作积极主动，具有很强的工作责任心和创新、服务意识，对工作一丝不苟，认真
负责；
3．年龄35周岁以下，计算机、计算力学或计算数学等相关专业硕士及以上学位；
4. 熟悉并行机群的软硬件结构及并行计算编程、调试环境；
5．熟悉机房管理，有机房建设或机房管理经验者优先；
6. 熟悉计算流体力学、计算固体力学或分子动力学计算者优先。
四、应聘材料
力学所岗位申请表及工作经历；本人证件照；家庭情况；重要证书复印件（包括学历、学
位、英语等级以及其它获奖证书等）；联系方式。 |
|
q*d
发帖数: 22178 | 47 这位仁兄,不必提到计算必是大规模并行,
大部分人不是做并行的也一般用不到.
很多人也就数值积个分,插个值,解个二阶微分方程等等,
干这个你非得用supercomputer并行,
那不等于去walmart买个菜非要开飞机还得是F22 |
|
