Redian新闻
>
想买个laptop的外置硬盘,>=800g,usb借口,哪个名声好点?不想硬盘crash.
avatar
想买个laptop的外置硬盘,>=800g,usb借口,哪个名声好点?不想硬盘crash.# PDA - 掌中宝
d*a
1
i5机器,内存够
STATA运行某个用户贡献的程序,费时一小时
我这属于试算,每试算一次一小时,这没法忍
换i7也只能缩短到50分钟?
难道我只好自己拿C#写?
avatar
c*e
2
想买>=800g,现在的laptop硬盘好小,不能装很多软件,非常烦人。
avatar
n*7
3
改成并行的
或者一次跑4个job
avatar
l*e
4
你即使买了外置硬盘,也不能把软件装在上面吧,除非你一直挂着
硬盘都是看运气的,随便挑个大牌的买吧
avatar
d*a
5

我的一个试算分成四个部分并行?这听着挺好,但可能吗?
还是四个试算同时进行?这倒是可行,就是没什么意义

【在 n******7 的大作中提到】
: 改成并行的
: 或者一次跑4个job

avatar
n*7
6
我说的是data或者参数split
如果你需要测试不同data或者参数的结果,每个job分别处理不同的data/parameter就
好了
这是最简单的利用多核的方式
STATA我没用过,不知道改成C#能有多少提高
不过我一年前遇到过类似的情况
我的code开始是用R写的,本来够快
后来加了一些步骤之后慢的不行了
我就改成了java,速度大概50X以上
后来我又改成多线程了,并行度接近100%,所以速度是16X
这样运行时间降低了大概3个数量级
不过我要提醒你一点,java这样的通用语言统计方面的包远不如R之类的专业语言
不少东西我只好自己实现,很蛋疼
我估计你用C#也会有这个问题

【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行?这听着挺好,但可能吗?
: 还是四个试算同时进行?这倒是可行,就是没什么意义

avatar
P*H
7
一次跑四个最简单了。为什么没意义?因为你就只有一个用户,还任务之间有依赖?

【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行?这听着挺好,但可能吗?
: 还是四个试算同时进行?这倒是可行,就是没什么意义

avatar
i*l
8
你这种的不如上AMD的8核处理器/
avatar
d*a
9
i5四核吧
不是说两核的i3都完灭AMD吗?

【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
avatar
n*7
10
估计只会更差
AMD的所谓8核是4个module
每个module 2个整数运算单元+1个浮点运算单元
做浮点运算就是4核
更不用说AMD IPC非常差,就是核多一倍也没用
我测试过16core的xeon对24core的opteron
结果是xeon要快一倍

【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
avatar
y*b
11
光靠机器是不行的,除非来个液氮超频。
提升代码效率的基本顺序是:
代码profiling->代码改进优化->openmp并行化->mpi并行化
avatar
n*7
12
现在mpi也可以做shared memory计算
纯用mpi比mpi+openmp性能还好
不过这是我同事说的,他用纯mpi做了一个hybrid的并行项目

【在 y**b 的大作中提到】
: 光靠机器是不行的,除非来个液氮超频。
: 提升代码效率的基本顺序是:
: 代码profiling->代码改进优化->openmp并行化->mpi并行化

avatar
y*b
13
mpi一直可以做shared memory计算,在一台机器的内存里面通讯,性能能不好吗。
用mpi比mpi+openmp性能还好,很多情况是这样的,我做的情况也是如此。但是不能排
除有些情况不是如此。
关键是,mpi从设计到完成比openmp复杂太多。一个项目,时间上很可能不允许做mpi(
没个半年设计、开发、调试、大规模测试很难搞定),但是openmp很简单,几天几周基
本都能搞定。
mpi一旦做好了,就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
,mpi就没这个限制了,几百几千个节点并行的威力没法比。
avatar
n*7
14
嗯,性能和实现速度之间确实需要取舍
可能我们的问题比较简单,我同事几天就搞定了
不过他也确实做的比较糙
后来讲他的工作,另一个同事发现他的并行效率超过100%了
最后的解释是有时候cluster的其他用户slowdown了有些节点,所以结果不稳定...

【在 y**b 的大作中提到】
: mpi一直可以做shared memory计算,在一台机器的内存里面通讯,性能能不好吗。
: 用mpi比mpi+openmp性能还好,很多情况是这样的,我做的情况也是如此。但是不能排
: 除有些情况不是如此。
: 关键是,mpi从设计到完成比openmp复杂太多。一个项目,时间上很可能不允许做mpi(
: 没个半年设计、开发、调试、大规模测试很难搞定),但是openmp很简单,几天几周基
: 本都能搞定。
: mpi一旦做好了,就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
: ,mpi就没这个限制了,几百几千个节点并行的威力没法比。

avatar
y*b
15
呵呵,理论上是没法超过100%的,实际上90%的效率已经很惊人了,规模大的时候更是
不得了。除了问题本身和软件环境,跟具体的supercomputer架构也有关系。
比较快速高效的开发办法是直接使用C++ Boost提供的mpi库(就是一层包装,但非常可
靠),比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持,这倒不是
啥问题。
结果不稳定?也是要跟串行结果比较的。
avatar
n*7
16
就是跟串行的比较
1个core 要200h
64个core 只要1h
明显不对
不过paper已经发了
也没人管了
我感觉并行最关键的还是问题的领域
我们领域的问题基本都是高度可并的
其实单机并行我已经觉得很爽了
现在版上的千元双路机都有16核32线程
单机并行就可以缩短运行时间一个数量级
很客观了
也准备找机会玩玩MPI,一直对分布式计算很有兴趣

【在 y**b 的大作中提到】
: 呵呵,理论上是没法超过100%的,实际上90%的效率已经很惊人了,规模大的时候更是
: 不得了。除了问题本身和软件环境,跟具体的supercomputer架构也有关系。
: 比较快速高效的开发办法是直接使用C++ Boost提供的mpi库(就是一层包装,但非常可
: 靠),比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持,这倒不是
: 啥问题。
: 结果不稳定?也是要跟串行结果比较的。

avatar
m*n
17
亲身经历:
1,把绝大多数命令行前面加qui
2,如果是一些迭代运算,试运算时限制迭代次数。比如用一个变量控制,试运算全部选
10,正式运算全部选40
3,用双路cpu。双X2670 Xeon非常便宜,16核。如果需要,我有一对可以退给你。
4,对于stata科学运算,其他指标一样,仅仅i5 VS i7的区别,也就是hyperthread,基
本没有提高
5,优化算法。

【在 d******a 的大作中提到】
: i5机器,内存够
: STATA运行某个用户贡献的程序,费时一小时
: 我这属于试算,每试算一次一小时,这没法忍
: 换i7也只能缩短到50分钟?
: 难道我只好自己拿C#写?

avatar
m*n
18
道理是这样,但是比如用STATA做分析的分析师,关注点在分析的问题本身,设计各种
回归模型,数据处理,而不在优化代码。

【在 y**b 的大作中提到】
: 光靠机器是不行的,除非来个液氮超频。
: 提升代码效率的基本顺序是:
: 代码profiling->代码改进优化->openmp并行化->mpi并行化

avatar
d*a
19
上NVIDIA独立显卡,然后用CUDA是否可以大幅度提高计算速度?

【在 d******a 的大作中提到】
: i5机器,内存够
: STATA运行某个用户贡献的程序,费时一小时
: 我这属于试算,每试算一次一小时,这没法忍
: 换i7也只能缩短到50分钟?
: 难道我只好自己拿C#写?

avatar
V*0
20
不行,STATA不支持cuda等cpu computing
STATA对cpu的并行效率其实也看场合

【在 d******a 的大作中提到】
: 上NVIDIA独立显卡,然后用CUDA是否可以大幅度提高计算速度?
avatar
d*a
21
我改用matlab或者Mathematica就可以了吧?


: 不行,STATA不支持cuda等cpu computing

: STATA对cpu的并行效率其实也看场合



【在 V**0 的大作中提到】
: 不行,STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合

avatar
d*a
22
在cluster上并行效率超过100%,对一些计算/通讯比很高的程序来说,根本就不是什么
异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache,32个处理器的
cache加起来就有256MB。这个现象,对搞高性能计算的人来说,是基本常识,读文献时
经常可见。我自己做实验也看到过好些次。

【在 n******7 的大作中提到】
: 嗯,性能和实现速度之间确实需要取舍
: 可能我们的问题比较简单,我同事几天就搞定了
: 不过他也确实做的比较糙
: 后来讲他的工作,另一个同事发现他的并行效率超过100%了
: 最后的解释是有时候cluster的其他用户slowdown了有些节点,所以结果不稳定...

avatar
n*7
24
你总算说点有意思的了
那么一般这个效率可以达到的上限是多少?
我感觉即使可以突破100%,提升也应该有限,不会有大幅的超出

【在 d***a 的大作中提到】
: 在cluster上并行效率超过100%,对一些计算/通讯比很高的程序来说,根本就不是什么
: 异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache,32个处理器的
: cache加起来就有256MB。这个现象,对搞高性能计算的人来说,是基本常识,读文献时
: 经常可见。我自己做实验也看到过好些次。

avatar
w*g
25
要快的话得用C++。

【在 d******a 的大作中提到】
: i5机器,内存够
: STATA运行某个用户贡献的程序,费时一小时
: 我这属于试算,每试算一次一小时,这没法忍
: 换i7也只能缩短到50分钟?
: 难道我只好自己拿C#写?

avatar
d*a
26
是的,这个不是普遍现象,碰上了是运气。搞应用的,不能指望靠这个效应来提高性能
。但也不算太少见,所以写文章分析系统性能的时候,一定要知道可以用这个来解释异
常的性能提高。:) 当然还要加做实验,分析结果,才能确知。
另一个常见原因是内存总和变大了。有些程序浪费很多时间在存贮I/O上。放到cluster
上去运行,比如说一个节点有64GB内存,32个节点有就2TB内存,对某些程序来说就可
以大大减少I/O访问时间,也许所有的数据集都可以放到内存里,不用访问外存贮了。

【在 y**b 的大作中提到】
: 谢谢指出,这个superlinear speedup很有意思,这里说一般只有小规模才会出现?
: https://wiki.scinet.utoronto.ca/wiki/index.php/Introduction_To_Performance
: cache size的影响明显,但要碰巧problem size刚好在某个值附近才会发生
: superlinear speedup,所以不是很普遍? 我猜测。

avatar
y*b
27
内存这个一般倒是都会做些分析,毕竟并行计算并不只是speedup,内存够用也非常重
要。有些计算对内存需求极大,非得到多个节点上均分一下才能算得动,典型的如三维
边界元方法。
好的scalability很重要的一点就是problem size增大的时候节点内存无需增加或者只
需缓慢增加,而且还能保持iso-efficiency。对不同的具体问题这种scalability都是
不同的,一般需要推演相关公式,如三维差分流动和三维离散元就有不同的
scalability,做深度耦合并行的时候就得很注意。
但是cache这东西实在很敏感,好像也没见到啥理论分析,不过我是搞应用的这方面知
之不深。
avatar
d*a
28
内存的性能分析和预测比cache容易得多。Cache性能表现有一定的随机性。有不少软件
和硬件方法能提高cache性能,但性能预测本质上是概率性的,我个人看法是类似于天
气预报,仅做参考,不可全信。
avatar
y*b
29
今天整理一下计算数据,吓一大跳,有很多efficiency>100%的情况。不仅如此,计算
规模越大(用到节点数越多),该情况越显著。
小规模计算(最多使用8节点)普遍低于100%;
中等规模计算(最多使用64节点)竟然全部大于100%;
大规模(最多使用1024个节点)在32节点下效率竟然达到2000%,768节点仍然有130%,
1024节点才降到87%。
我这个计算的特点是对内存要求极低,但对cpu要求非常高。确实具备了凑巧能把数据
放进cache的可能?
另外当时做这些计算用的是自己费力不讨好编译的intel mpi(同时还编译了openmpi,
稳定性差些就没采用),没用原机默认的mpi库(或者当时就没有,但后来os升级后又都
提供了),会不会有啥影响,现在都重算一遍是不可能了。
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。