想买个laptop的外置硬盘，>=800g,usb借口，哪个名声好点?不想硬盘crash.# PDA - 掌中宝
d*a
1 楼
i5机器，内存够
STATA运行某个用户贡献的程序，费时一小时
我这属于试算，每试算一次一小时，这没法忍
换i7也只能缩短到50分钟？
难道我只好自己拿C#写？
STATA运行某个用户贡献的程序，费时一小时
我这属于试算，每试算一次一小时，这没法忍
换i7也只能缩短到50分钟？
难道我只好自己拿C#写？
c*e
2 楼
想买>=800g，现在的laptop硬盘好小，不能装很多软件，非常烦人。
n*7
3 楼
改成并行的
或者一次跑4个job
或者一次跑4个job
l*e
4 楼
你即使买了外置硬盘，也不能把软件装在上面吧，除非你一直挂着
硬盘都是看运气的，随便挑个大牌的买吧
硬盘都是看运气的，随便挑个大牌的买吧
d*a
5 楼
我的一个试算分成四个部分并行？这听着挺好，但可能吗？
还是四个试算同时进行？这倒是可行，就是没什么意义
【在 n******7 的大作中提到】
: 改成并行的
: 或者一次跑4个job
n*7
6 楼
我说的是data或者参数split
如果你需要测试不同data或者参数的结果，每个job分别处理不同的data/parameter就
好了
这是最简单的利用多核的方式
STATA我没用过，不知道改成C#能有多少提高
不过我一年前遇到过类似的情况
我的code开始是用R写的，本来够快
后来加了一些步骤之后慢的不行了
我就改成了java，速度大概50X以上
后来我又改成多线程了，并行度接近100%，所以速度是16X
这样运行时间降低了大概3个数量级
不过我要提醒你一点，java这样的通用语言统计方面的包远不如R之类的专业语言
不少东西我只好自己实现，很蛋疼
我估计你用C#也会有这个问题
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
如果你需要测试不同data或者参数的结果，每个job分别处理不同的data/parameter就
好了
这是最简单的利用多核的方式
STATA我没用过，不知道改成C#能有多少提高
不过我一年前遇到过类似的情况
我的code开始是用R写的，本来够快
后来加了一些步骤之后慢的不行了
我就改成了java，速度大概50X以上
后来我又改成多线程了，并行度接近100%，所以速度是16X
这样运行时间降低了大概3个数量级
不过我要提醒你一点，java这样的通用语言统计方面的包远不如R之类的专业语言
不少东西我只好自己实现，很蛋疼
我估计你用C#也会有这个问题
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
P*H
7 楼
一次跑四个最简单了。为什么没意义？因为你就只有一个用户，还任务之间有依赖？
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
【在 d******a 的大作中提到】
:
: 我的一个试算分成四个部分并行？这听着挺好，但可能吗？
: 还是四个试算同时进行？这倒是可行，就是没什么意义
i*l
8 楼
你这种的不如上AMD的8核处理器/
d*a
9 楼
i5四核吧
不是说两核的i3都完灭AMD吗？
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
不是说两核的i3都完灭AMD吗？
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
n*7
10 楼
估计只会更差
AMD的所谓8核是4个module
每个module 2个整数运算单元+1个浮点运算单元
做浮点运算就是4核
更不用说AMD IPC非常差，就是核多一倍也没用
我测试过16core的xeon对24core的opteron
结果是xeon要快一倍
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
AMD的所谓8核是4个module
每个module 2个整数运算单元+1个浮点运算单元
做浮点运算就是4核
更不用说AMD IPC非常差，就是核多一倍也没用
我测试过16core的xeon对24core的opteron
结果是xeon要快一倍
【在 i***l 的大作中提到】
: 你这种的不如上AMD的8核处理器/
y*b
11 楼
光靠机器是不行的，除非来个液氮超频。
提升代码效率的基本顺序是：
代码profiling->代码改进优化->openmp并行化->mpi并行化
提升代码效率的基本顺序是：
代码profiling->代码改进优化->openmp并行化->mpi并行化
n*7
12 楼
现在mpi也可以做shared memory计算
纯用mpi比mpi+openmp性能还好
不过这是我同事说的，他用纯mpi做了一个hybrid的并行项目
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
纯用mpi比mpi+openmp性能还好
不过这是我同事说的，他用纯mpi做了一个hybrid的并行项目
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
y*b
13 楼
mpi一直可以做shared memory计算，在一台机器的内存里面通讯，性能能不好吗。
用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
除有些情况不是如此。
关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
本都能搞定。
mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
，mpi就没这个限制了，几百几千个节点并行的威力没法比。
用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
除有些情况不是如此。
关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
本都能搞定。
mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
，mpi就没这个限制了，几百几千个节点并行的威力没法比。
n*7
14 楼
嗯，性能和实现速度之间确实需要取舍
可能我们的问题比较简单，我同事几天就搞定了
不过他也确实做的比较糙
后来讲他的工作，另一个同事发现他的并行效率超过100%了
最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
【在 y**b 的大作中提到】
: mpi一直可以做shared memory计算，在一台机器的内存里面通讯，性能能不好吗。
: 用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
: 除有些情况不是如此。
: 关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
: 没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
: 本都能搞定。
: mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
: ，mpi就没这个限制了，几百几千个节点并行的威力没法比。
可能我们的问题比较简单，我同事几天就搞定了
不过他也确实做的比较糙
后来讲他的工作，另一个同事发现他的并行效率超过100%了
最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
【在 y**b 的大作中提到】
: mpi一直可以做shared memory计算，在一台机器的内存里面通讯，性能能不好吗。
: 用mpi比mpi+openmp性能还好，很多情况是这样的，我做的情况也是如此。但是不能排
: 除有些情况不是如此。
: 关键是，mpi从设计到完成比openmp复杂太多。一个项目，时间上很可能不允许做mpi(
: 没个半年设计、开发、调试、大规模测试很难搞定)，但是openmp很简单，几天几周基
: 本都能搞定。
: mpi一旦做好了，就不是openmp能比的了。openmp只能运行在一个节点或一台工作站上
: ，mpi就没这个限制了，几百几千个节点并行的威力没法比。
y*b
15 楼
呵呵，理论上是没法超过100%的，实际上90%的效率已经很惊人了，规模大的时候更是
不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
啥问题。
结果不稳定？也是要跟串行结果比较的。
不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
啥问题。
结果不稳定？也是要跟串行结果比较的。
n*7
16 楼
就是跟串行的比较
1个core 要200h
64个core 只要1h
明显不对
不过paper已经发了
也没人管了
我感觉并行最关键的还是问题的领域
我们领域的问题基本都是高度可并的
其实单机并行我已经觉得很爽了
现在版上的千元双路机都有16核32线程
单机并行就可以缩短运行时间一个数量级
很客观了
也准备找机会玩玩MPI，一直对分布式计算很有兴趣
【在 y**b 的大作中提到】
: 呵呵，理论上是没法超过100%的，实际上90%的效率已经很惊人了，规模大的时候更是
: 不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
: 比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
: 靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
: 啥问题。
: 结果不稳定？也是要跟串行结果比较的。
1个core 要200h
64个core 只要1h
明显不对
不过paper已经发了
也没人管了
我感觉并行最关键的还是问题的领域
我们领域的问题基本都是高度可并的
其实单机并行我已经觉得很爽了
现在版上的千元双路机都有16核32线程
单机并行就可以缩短运行时间一个数量级
很客观了
也准备找机会玩玩MPI，一直对分布式计算很有兴趣
【在 y**b 的大作中提到】
: 呵呵，理论上是没法超过100%的，实际上90%的效率已经很惊人了，规模大的时候更是
: 不得了。除了问题本身和软件环境，跟具体的supercomputer架构也有关系。
: 比较快速高效的开发办法是直接使用C++ Boost提供的mpi库（就是一层包装，但非常可
: 靠），比调用那些原始的mpi函数好百倍。当然运行的时候得有这些库支持，这倒不是
: 啥问题。
: 结果不稳定？也是要跟串行结果比较的。
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#写？
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
18 楼
道理是这样，但是比如用STATA做分析的分析师，关注点在分析的问题本身，设计各种
回归模型，数据处理，而不在优化代码。
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
回归模型，数据处理，而不在优化代码。
【在 y**b 的大作中提到】
: 光靠机器是不行的，除非来个液氮超频。
: 提升代码效率的基本顺序是：
: 代码profiling->代码改进优化->openmp并行化->mpi并行化
d*a
19 楼
上NVIDIA独立显卡，然后用CUDA是否可以大幅度提高计算速度？
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
V*0
20 楼
不行，STATA不支持cuda等cpu computing
STATA对cpu的并行效率其实也看场合
【在 d******a 的大作中提到】
: 上NVIDIA独立显卡，然后用CUDA是否可以大幅度提高计算速度？
STATA对cpu的并行效率其实也看场合
【在 d******a 的大作中提到】
: 上NVIDIA独立显卡，然后用CUDA是否可以大幅度提高计算速度？
d*a
21 楼
我改用matlab或者Mathematica就可以了吧？
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
【在 V**0 的大作中提到】
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
【在 V**0 的大作中提到】
: 不行，STATA不支持cuda等cpu computing
: STATA对cpu的并行效率其实也看场合
d*a
22 楼
在cluster上并行效率超过100%，对一些计算/通讯比很高的程序来说，根本就不是什么
异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
经常可见。我自己做实验也看到过好些次。
【在 n******7 的大作中提到】
: 嗯，性能和实现速度之间确实需要取舍
: 可能我们的问题比较简单，我同事几天就搞定了
: 不过他也确实做的比较糙
: 后来讲他的工作，另一个同事发现他的并行效率超过100%了
: 最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
经常可见。我自己做实验也看到过好些次。
【在 n******7 的大作中提到】
: 嗯，性能和实现速度之间确实需要取舍
: 可能我们的问题比较简单，我同事几天就搞定了
: 不过他也确实做的比较糙
: 后来讲他的工作，另一个同事发现他的并行效率超过100%了
: 最后的解释是有时候cluster的其他用户slowdown了有些节点，所以结果不稳定...
y*b
23 楼
谢谢指出，这个superlinear speedup很有意思，这里说一般只有小规模才会出现？
https://wiki.scinet.utoronto.ca/wiki/index.php/Introduction_To_Performance
cache size的影响明显，但要碰巧problem size刚好在某个值附近才会发生
superlinear speedup，所以不是很普遍? 我猜测。
https://wiki.scinet.utoronto.ca/wiki/index.php/Introduction_To_Performance
cache size的影响明显，但要碰巧problem size刚好在某个值附近才会发生
superlinear speedup，所以不是很普遍? 我猜测。
n*7
24 楼
你总算说点有意思的了
那么一般这个效率可以达到的上限是多少？
我感觉即使可以突破100%，提升也应该有限，不会有大幅的超出
【在 d***a 的大作中提到】
: 在cluster上并行效率超过100%，对一些计算/通讯比很高的程序来说，根本就不是什么
: 异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
: cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
: 经常可见。我自己做实验也看到过好些次。
那么一般这个效率可以达到的上限是多少？
我感觉即使可以突破100%，提升也应该有限，不会有大幅的超出
【在 d***a 的大作中提到】
: 在cluster上并行效率超过100%，对一些计算/通讯比很高的程序来说，根本就不是什么
: 异常现象。最常见的原因是cache总和变大。一个处理器有8MB cache，32个处理器的
: cache加起来就有256MB。这个现象，对搞高性能计算的人来说，是基本常识，读文献时
: 经常可见。我自己做实验也看到过好些次。
w*g
25 楼
要快的话得用C++。
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
【在 d******a 的大作中提到】
: i5机器，内存够
: STATA运行某个用户贡献的程序，费时一小时
: 我这属于试算，每试算一次一小时，这没法忍
: 换i7也只能缩短到50分钟？
: 难道我只好自己拿C#写？
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，所以不是很普遍? 我猜测。
。但也不算太少见，所以写文章分析系统性能的时候，一定要知道可以用这个来解释异
常的性能提高。:) 当然还要加做实验，分析结果，才能确知。
另一个常见原因是内存总和变大了。有些程序浪费很多时间在存贮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
27 楼
内存这个一般倒是都会做些分析，毕竟并行计算并不只是speedup，内存够用也非常重
要。有些计算对内存需求极大，非得到多个节点上均分一下才能算得动，典型的如三维
边界元方法。
好的scalability很重要的一点就是problem size增大的时候节点内存无需增加或者只
需缓慢增加，而且还能保持iso-efficiency。对不同的具体问题这种scalability都是
不同的，一般需要推演相关公式，如三维差分流动和三维离散元就有不同的
scalability，做深度耦合并行的时候就得很注意。
但是cache这东西实在很敏感，好像也没见到啥理论分析，不过我是搞应用的这方面知
之不深。
要。有些计算对内存需求极大，非得到多个节点上均分一下才能算得动，典型的如三维
边界元方法。
好的scalability很重要的一点就是problem size增大的时候节点内存无需增加或者只
需缓慢增加，而且还能保持iso-efficiency。对不同的具体问题这种scalability都是
不同的，一般需要推演相关公式，如三维差分流动和三维离散元就有不同的
scalability，做深度耦合并行的时候就得很注意。
但是cache这东西实在很敏感，好像也没见到啥理论分析，不过我是搞应用的这方面知
之不深。
d*a
28 楼
内存的性能分析和预测比cache容易得多。Cache性能表现有一定的随机性。有不少软件
和硬件方法能提高cache性能，但性能预测本质上是概率性的，我个人看法是类似于天
气预报，仅做参考，不可全信。
和硬件方法能提高cache性能，但性能预测本质上是概率性的，我个人看法是类似于天
气预报，仅做参考，不可全信。
y*b
29 楼
今天整理一下计算数据，吓一大跳，有很多efficiency>100%的情况。不仅如此，计算
规模越大(用到节点数越多)，该情况越显著。
小规模计算(最多使用8节点)普遍低于100%；
中等规模计算(最多使用64节点)竟然全部大于100%；
大规模(最多使用1024个节点)在32节点下效率竟然达到2000%，768节点仍然有130%，
1024节点才降到87%。
我这个计算的特点是对内存要求极低，但对cpu要求非常高。确实具备了凑巧能把数据
放进cache的可能？
另外当时做这些计算用的是自己费力不讨好编译的intel mpi(同时还编译了openmpi，
稳定性差些就没采用)，没用原机默认的mpi库(或者当时就没有，但后来os升级后又都
提供了)，会不会有啥影响，现在都重算一遍是不可能了。
规模越大(用到节点数越多)，该情况越显著。
小规模计算(最多使用8节点)普遍低于100%；
中等规模计算(最多使用64节点)竟然全部大于100%；
大规模(最多使用1024个节点)在32节点下效率竟然达到2000%，768节点仍然有130%，
1024节点才降到87%。
我这个计算的特点是对内存要求极低，但对cpu要求非常高。确实具备了凑巧能把数据
放进cache的可能？
另外当时做这些计算用的是自己费力不讨好编译的intel mpi(同时还编译了openmpi，
稳定性差些就没采用)，没用原机默认的mpi库(或者当时就没有，但后来os升级后又都
提供了)，会不会有啥影响，现在都重算一遍是不可能了。
相关阅读
请推荐国内老人用的手机乐视盒子能用手机遥控和AIRPLAY类似的功能吗用WP的给推荐个MicroSD 卡吧弃婴挺罗永浩，反方舟子，不知道哪个是因，哪个是果推荐可以HDMI输出的便宜板子乐视限海外IP，改DNS也不行啊，有什么好办法吗？锤子手机从开始就是错的[FS]白色三星Note 2 Verizon@$180+shipping请教：iPhone自带的邮件app，可以实现gmail的推送吗？问下大家都用多大带宽的internet service今天的大事问一下小米的收费模式联想k920八月初发布，金属机身，801晓龙，1999这个latexcat是干啥的？万一罗胖子完成不了订单，所有用户都能拿到退款吗？Note 3的电池太扯淡了synology是要出新品了吧方秃子这人的确难缠，又贼又毒这种情况下罗老师C轮融资还有戏吗?国内安卓手机的系统是裁剪过的吗？