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