d******a
发帖数: 32122 | 1 i5机器，内存够
STATA运行某个用户贡献的程序，费时一小时
我这属于试算，每试算一次一小时，这没法忍
换i7也只能缩短到50分钟？
难道我只好自己拿C#写？ |
n******7
发帖数: 12463 | |
d******a
发帖数: 32122 | 3
我的一个试算分成四个部分并行？这听着挺好，但可能吗？
还是四个试算同时进行？这倒是可行，就是没什么意义
【在 n******7 的大作中提到】
: 改成并行的
: 或者一次跑4个job
|
n******7
发帖数: 12463 | 4 我说的是data或者参数split
如果你需要测试不同data或者参数的结果，每个job分别处理不同的data/parameter就
好了
这是最简单的利用多核的方式
STATA我没用过，不知道改成C#能有多少提高
不过我一年前遇到过类似的情况
我的code开始是用R写的，本来够快
后来加了一些步骤之后慢的不行了
我就改成了java，速度大概50X以上
后来我又改成多线程了，并行度接近100%，所以速度是16X
这样运行时间降低了大概3个数量级
不过我要提醒你一点，java这样的通用语言统计方面的包远不如R之类的专业语言
不少东西我只好自己实现，很蛋疼
我估计你用C#也会有这个问题
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
|
P**H
发帖数: 1897 | 5 一次跑四个最简单了。为什么没意义？因为你就只有一个用户，还任务之间有依赖？
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
|
i***l
发帖数: 9994 | |
d******a
发帖数: 32122 | 7 i5四核吧
不是说两核的i3都完灭AMD吗？
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
|
n******7
发帖数: 12463 | 8 估计只会更差
AMD的所谓8核是4个module
每个module 2个整数运算单元+1个浮点运算单元
做浮点运算就是4核
更不用说AMD IPC非常差，就是核多一倍也没用
我测试过16core的xeon对24core的opteron
结果是xeon要快一倍
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
|
y**b
发帖数: 10166 | 9 光靠机器是不行的，除非来个液氮超频。
提升代码效率的基本顺序是：
代码profiling->代码改进优化->openmp并行化->mpi并行化 |
n******7
发帖数: 12463 | 10 现在mpi也可以做shared memory计算
纯用mpi比mpi+openmp性能还好
不过这是我同事说的，他用纯mpi做了一个hybrid的并行项目
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
|
|
|
y**b
发帖数: 10166 | 11 mpi一直可以做shared memory计算，在一台机器的内存里面通讯，性能能不好吗。
用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
除有些情况不是如此。
关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
本都能搞定。
mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
，mpi就没这个限制了，几百几千个节点并行的威力没法比。 |
n******7
发帖数: 12463 | 12 嗯，性能和实现速度之间确实需要取舍
可能我们的问题比较简单，我同事几天就搞定了
不过他也确实做的比较糙
后来讲他的工作，另一个同事发现他的并行效率超过100%了
最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
【在 y**b 的大作中提到】
: mpi一直可以做shared memory计算，在一台机器的内存里面通讯，性能能不好吗。
: 用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
: 除有些情况不是如此。
: 关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
: 没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
: 本都能搞定。
: mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
: ，mpi就没这个限制了，几百几千个节点并行的威力没法比。
|
y**b
发帖数: 10166 | 13 呵呵，理论上是没法超过100%的，实际上90%的效率已经很惊人了，规模大的时候更是
不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
啥问题。
结果不稳定？也是要跟串行结果比较的。 |
n******7
发帖数: 12463 | 14 就是跟串行的比较
1个core 要200h
64个core 只要1h
明显不对
不过paper已经发了
也没人管了
我感觉并行最关键的还是问题的领域
我们领域的问题基本都是高度可并的
其实单机并行我已经觉得很爽了
现在版上的千元双路机都有16核32线程
单机并行就可以缩短运行时间一个数量级
很客观了
也准备找机会玩玩MPI，一直对分布式计算很有兴趣
【在 y**b 的大作中提到】
: 呵呵，理论上是没法超过100%的，实际上90%的效率已经很惊人了，规模大的时候更是
: 不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
: 比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
: 靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
: 啥问题。
: 结果不稳定？也是要跟串行结果比较的。
|
m*****n
发帖数: 3644 | 15 亲身经历：
1，把绝大多数命令行前面加qui
2,如果是一些迭代运算，试运算时限制迭代次数。比如用一个变量控制，试运算全部选
10，正式运算全部选40
3，用双路cpu。双X2670 Xeon非常便宜，16核。如果需要，我有一对可以退给你。
4，对于stata科学运算，其他指标一样，仅仅i5 VS i7的区别，也就是hyperthread,基
本没有提高
5，优化算法。
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
|
m*****n
发帖数: 3644 | 16 道理是这样，但是比如用STATA做分析的分析师，关注点在分析的问题本身，设计各种
回归模型，数据处理，而不在优化代码。
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
|
d******a
发帖数: 32122 | 17 上NVIDIA独立显卡，然后用CUDA是否可以大幅度提高计算速度？
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
|
V**0
发帖数: 889 | 18 不行，STATA不支持cuda等cpu computing
STATA对cpu的并行效率其实也看场合
【在 d******a 的大作中提到】
: 上NVIDIA独立显卡，然后用CUDA是否可以大幅度提高计算速度？
|
d******a
发帖数: 32122 | 19 我改用matlab或者Mathematica就可以了吧？
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
【在 V**0 的大作中提到】
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
|
d***a
发帖数: 13752 | 20 在cluster上并行效率超过100%，对一些计算/通讯比很高的程序来说，根本就不是什么
异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
经常可见。我自己做实验也看到过好些次。
【在 n******7 的大作中提到】
: 嗯，性能和实现速度之间确实需要取舍
: 可能我们的问题比较简单，我同事几天就搞定了
: 不过他也确实做的比较糙
: 后来讲他的工作，另一个同事发现他的并行效率超过100%了
: 最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
|
|
|
y**b
发帖数: 10166 | 21 谢谢指出，这个superlinear speedup很有意思，这里说一般只有小规模才会出现？
https://wiki.scinet.utoronto.ca/wiki/index.php/Introduction_To_Performance
cache size的影响明显，但要碰巧problem size刚好在某个值附近才会发生
superlinear speedup，所以不是很普遍? 我猜测。 |
n******7
发帖数: 12463 | 22 你总算说点有意思的了
那么一般这个效率可以达到的上限是多少？
我感觉即使可以突破100%，提升也应该有限，不会有大幅的超出
【在 d***a 的大作中提到】
: 在cluster上并行效率超过100%，对一些计算/通讯比很高的程序来说，根本就不是什么
: 异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
: cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
: 经常可见。我自己做实验也看到过好些次。
|
w***g
发帖数: 5958 | 23 要快的话得用C++。
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
|
d***a
发帖数: 13752 | 24 是的，这个不是普遍现象，碰上了是运气。搞应用的，不能指望靠这个效应来提高性能
。但也不算太少见，所以写文章分析系统性能的时候，一定要知道可以用这个来解释异
常的性能提高。:) 当然还要加做实验，分析结果，才能确知。
另一个常见原因是内存总和变大了。有些程序浪费很多时间在存贮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，所以不是很普遍? 我猜测。
|
y**b
发帖数: 10166 | 25 内存这个一般倒是都会做些分析，毕竟并行计算并不只是speedup，内存够用也非常重
要。有些计算对内存需求极大，非得到多个节点上均分一下才能算得动，典型的如三维
边界元方法。
好的scalability很重要的一点就是problem size增大的时候节点内存无需增加或者只
需缓慢增加，而且还能保持iso-efficiency。对不同的具体问题这种scalability都是
不同的，一般需要推演相关公式，如三维差分流动和三维离散元就有不同的
scalability，做深度耦合并行的时候就得很注意。
但是cache这东西实在很敏感，好像也没见到啥理论分析，不过我是搞应用的这方面知
之不深。 |
d***a
发帖数: 13752 | 26 内存的性能分析和预测比cache容易得多。Cache性能表现有一定的随机性。有不少软件
和硬件方法能提高cache性能，但性能预测本质上是概率性的，我个人看法是类似于天
气预报，仅做参考，不可全信。 |
y**b
发帖数: 10166 | 27 今天整理一下计算数据，吓一大跳，有很多efficiency>100%的情况。不仅如此，计算
规模越大(用到节点数越多)，该情况越显著。
小规模计算(最多使用8节点)普遍低于100%；
中等规模计算(最多使用64节点)竟然全部大于100%；
大规模(最多使用1024个节点)在32节点下效率竟然达到2000%，768节点仍然有130%，
1024节点才降到87%。
我这个计算的特点是对内存要求极低，但对cpu要求非常高。确实具备了凑巧能把数据
放进cache的可能？
另外当时做这些计算用的是自己费力不讨好编译的intel mpi(同时还编译了openmpi，
稳定性差些就没采用)，没用原机默认的mpi库(或者当时就没有，但后来os升级后又都
提供了)，会不会有啥影响，现在都重算一遍是不可能了。 |
