POPPUR爱换

标题: 科学运算,请远离INTEL [打印本页]

作者: mooncocoon    时间: 2007-4-19 12:39
标题: 科学运算,请远离INTEL
实验室刚买的XENO5355*2的服务器,用来跑K原子级别的大体系分子动力学模拟,花了5W多,换来了什么呢~?
对比是实验室去年年初花2W多买的双OP265的机器
同样的2003的系统,同样的MS软件,同样的分子动力学大体系摸拟运算,同样有DOM3,调用同样多的4G内存,INTEL这边运算过程调用8核,AMD那边调用4核,放在同一个房间,同时开始计算

11天过去了,AMD组第3组大体系的分子动力学计算已经接近完成,INTEL那边第一组还没有完成…… 察看纪录,双方的CPU调用全都是100%

不明原因,但我到得出了一个结论——物理模拟以及量子物理方面的运算~请远离INTEL……
作者: hdy_aoe    时间: 2007-4-19 12:41
这里几个搞科学计算的??
作者: mooncocoon    时间: 2007-4-19 12:42
所以我才没让所有人远离INTEL嘛~
作者: Prescott    时间: 2007-4-19 12:43
w00t) 这么说5355 x2 连 OP 265 *2的1/3性能都不到?
我看你还是需要仔细找一下原因的。

而且5355 x2 怎么需要5万块钱?
作者: mooncocoon    时间: 2007-4-19 12:48
整机需要5W,买U的时候被狠宰了一把,一快1W2

找了几天时间的原因了,没有头绪,计算模型~调用内存数~计算量设置~操作系统全部一样,AMD这边的系统还要老整整1年……

事实让人崩溃,除非你打算跟我说2003现在还不能很好的支持XENO5355或者需要补丁什么的 ……
作者: mooncocoon    时间: 2007-4-19 12:49
总之因为这个,实验室采购安腾2集群服务器的计划被搁置了,再卖一个OP8系列的服务器的计划被提上来了
作者: AlcatrazX    时间: 2007-4-19 12:50
提示: 作者被禁止或删除 内容自动屏蔽
作者: kknd1967    时间: 2007-4-19 12:51
效率差了6倍/core,又不是mp扩展性的问题
搞研究的 不明原因 如何结论? :huh:
作者: mooncocoon    时间: 2007-4-19 12:56
我现在估计跟DOM3有关,根据经验DOM3做势分析需要异常频繁的内存读写
可是不挂DOM3,还模拟个毛的体系啊……

之前算了个小体系的,50原子,势环境相对2000的体系已经是简单的不能再简单了,那次大家平手算是,都是9小时左右完成,OP265这边快了20多分钟
作者: potomac    时间: 2007-4-19 12:58
提示: 作者被禁止或删除 内容自动屏蔽
作者: 无梦之夜    时间: 2007-4-19 13:01
渣.......不过桌面平台肉还是很好的:a)
作者: Edison    时间: 2007-4-19 13:12
去cpuid那里下个PerfMonitor,然后看看都是些什么指令为主。

不过如果是内存操作密集型的应用,CPU200X的FP rate就是答案了。w00t)
作者: roland2kw    时间: 2007-4-19 13:12
楼主你哪里的?整机是哪家的产品?有必要CALL SUPPORT。
作者: gazel    时间: 2007-4-19 13:28
可以用VTune看看,看看瓶颈在哪里。用的是什么编译器?你的结果真的很奇怪。
作者: zaarath    时间: 2007-4-19 13:32
这个差距也太大了点吧,2.66 * 8 = 21.3 竟然不到 1.8*4 = 7.2的 三分之一,就是说效率差了将近九倍。core 2 又不是当年netburst的低效率,即使在科学计算上没什么优势也不可能一败涂地。毕竟同频的话science mark和F@H都是conroe胜出。

你要是搞科研的,如此大的反差肯定会引起你的警觉,知道肯定是哪里不对劲。

你应该先用一些常用测试软件(尤其是支持多核的比如cinebench)来确定xeon的机器肯定是运行正常。
然后你比较一下单线程运行的情况,再比较一下双线程,然后再试试4/8线程,结合不同的内存设定。如果还不行,打电话给供应商,让他们派人来解决。

不明原因,就下了结论,亏你是搞学术的。
作者: zaarath    时间: 2007-4-19 13:34
原帖由 Edison 于 2007-4-19 13:12 发表
去cpuid那里下个PerfMonitor,然后看看都是些什么指令为主。

不过如果是内存操作密集型的应用,CPU200X的FP rate就是答案了。w00t)


FP Rate差再多能差9倍么?我看是应该叫售后的时候了。
作者: zaarath    时间: 2007-4-19 13:39
还有就是大家说话小声点。AMD听到的话明天就会看到报道:

“Barcelona expects to see 10X gains in scientific applications"
作者: 89度热水    时间: 2007-4-19 13:42
让INTEL来解决吧,应该不是U本身的性能问题
作者: mooncocoon    时间: 2007-4-19 13:47
OYE~PerfMonitor弄来了,两边全都安装不能,03系统……

点PerfMonitor.exe,全无反映……

[ 本帖最后由 mooncocoon 于 2007-4-19 13:52 编辑 ]
作者: mooncocoon    时间: 2007-4-19 13:54
有在考虑换UNIX或者LINUX,不过这要征得ACCELRYS的同意……
作者: gazel    时间: 2007-4-19 13:56
原帖由 mooncocoon 于 2007-4-19 13:47 发表
OYE~PerfMonitor弄来了,两边全都安装不能,03系统……

点PerfMonitor.exe,全无反映……

一着急,日语语法都出来了?
:loveliness: :loveliness: VTUNE呢?有么?
作者: mooncocoon    时间: 2007-4-19 14:03
正在找
不知道是不是的人为设置,不少软件在这两台机器上都是双击了没有反应……
作者: bbcbbs    时间: 2007-4-19 14:30
提示: 作者被禁止或删除 内容自动屏蔽
作者: mooncocoon    时间: 2007-4-19 14:36
楼上的你在说什么……
如果你觉得一个大体系模拟跑几天是希奇事情或者种了病毒……我不知道除了孤陋寡闻以外我还能说什么好了……
我跑过连续41天的模拟……

并不是我们想要用2003,软件是ACCELRYS的,机器是ACCELRYS的,一切都是ACCELRYS说了算……
作者: mooncocoon    时间: 2007-4-19 14:39
另外,已经联系ACCELRYS了~他们正在龟速解决
唉……还是盗版+自装机是王道啊……想怎么胡来都行
作者: waishuma    时间: 2007-4-19 14:58
提示: 作者被禁止或删除 内容自动屏蔽
作者: 红发IXFXI    时间: 2007-4-19 15:27
原帖由 mooncocoon 于 2007-4-19 14:39 发表
另外,已经联系ACCELRYS了~他们正在龟速解决
唉……还是盗版+自装机是王道啊……想怎么胡来都行


:blink:
LZ给AFAN极大的精神支持。。。。。。。。。
作者: bessel    时间: 2007-4-19 15:30
对于受制于内存延时的程序来说是这样,对于多cpu平台你也是对的。


原帖由 Seraphlich 于 2007-4-19 13:05 发表
科学计算本类I就没什么优势。流体计算也如此了。

作者: CaptianGhostSSE    时间: 2007-4-19 15:34
w00t) 纯文字的啊? 是否是把两套系统的结果弄反了?
作者: bessel    时间: 2007-4-19 15:34
Are u using dmol3 ?
原帖由 mooncocoon 于 2007-4-19 14:39 发表
另外,已经联系ACCELRYS了~他们正在龟速解决
唉……还是盗版+自装机是王道啊……想怎么胡来都行

作者: suzune    时间: 2007-4-19 15:45
小跑个题,月子你Master毕业了吧?Ph.D中?
作者: jaguard    时间: 2007-4-19 15:46
原帖由 CaptianGhostSSE 于 2007-4-19 15:34 发表
w00t) 纯文字的啊? 是否是把两套系统的结果弄反了?

RPWT,对于你这种人上图都不可信
作者: Prescott    时间: 2007-4-19 15:57
你用的是这个程序吗?貌似5160轻松干掉Opteorn 285啊

http://www.principledtechnologie ... l/DMol3ServPerf.pdf

[attach]733609[/attach]

[ 本帖最后由 Prescott 于 2007-4-19 15:59 编辑 ]
作者: bessel    时间: 2007-4-19 16:00
俺从来没有听说过dom3,对于dmol3俺的同事们是用过的。
就等楼主一句话了。



原帖由 Prescott 于 2007-4-19 15:57 发表
你用的是这个程序吗?貌似5160轻松干掉Opteorn 285啊

http://www.principledtechnologie ... l/DMol3ServPerf.pdf

733609

作者: suzune    时间: 2007-4-19 16:01
ACCELRYS应该是某材料学专用的模拟软件吧?
很奇怪月子现在搞什么课题..
5W多的服务器很水啊,前几天上研的同学还说他们BOSS申请自然基金,开口1000W,其中随便写了200W的服务器<-完全用来上网

[ 本帖最后由 suzune 于 2007-4-19 16:03 编辑 ]
作者: bessel    时间: 2007-4-19 16:09
5w多的机器还水,很多鬼佬连这机器都没有照样出了无穷多的prl,看来
没有idea钱再多也没用。

原帖由 suzune 于 2007-4-19 16:01 发表
ACCELRYS应该是某材料学专用的模拟软件吧?
很奇怪月子现在搞什么课题..
5W多的服务器很水啊,前几天上研的同学还说他们BOSS申请自然基金,开口1000W,其中随便写了200W的服务器

作者: T_SK    时间: 2007-4-19 16:21
:funk: :blink: :wacko: :sweatingbullets: :thumbsup: 不太信任楼主!
作者: mooncocoon    时间: 2007-4-19 16:30
就是DMOL3~不过因为这东西苛烈的内存使用量,我们都改叫他DOOM3了,叫着叫着就顺口了

如果单纯用DMOL3对机器当然不会有什么要求了~2.6C都能跑~但是如果将DMOL3作为一个参量计算形式挂在其他的东西上面一起跑就是两回事了~

下午人家来了,没搞出个所以然来,说明天来拉走

我们在搞某个纳米相原位反应的模拟,试验作起来太贵了……
作者: mooncocoon    时间: 2007-4-19 16:32
另外~鬼佬是没有自己的机器,可是别人学校里都是怒强劲的服务器~你要算什么,提个申请,然后将数据和计算方法打个包或者写个详细申请,人家就会分机时给你了~
国内想跑点东西完全要靠自己啊……
作者: mooncocoon    时间: 2007-4-19 16:33
原帖由 suzune 于 2007-4-19 15:45 发表
小跑个题,月子你Master毕业了吧?Ph.D中?

7月份OVER,然后就可能要跟专业说拜拜了……:crying:
作者: shike_cuke    时间: 2007-4-19 16:35
差距好大.......................
作者: bessel    时间: 2007-4-19 16:39
dmol3的性能在p4的时候都马马虎虎可以用,不要说扣肉了。
至少公开的benchmark里面dmol的性能在intel平台没问题。
也学你的算例太特别,也许是你们自己的问题。

你们都不看dmol的手册了解一下这东西在不同平台的性能,出了问题就打算
买新机器的态度的确很难让人理解。我觉得你们不太适合在计算物理这个行当里。
早点quit吧。


原帖由 mooncocoon 于 2007-4-19 16:30 发表
就是DMOL3~不过因为这东西苛烈的内存使用量,我们都改叫他DOOM3了,叫着叫着就顺口了

如果单纯用DMOL3对机器当然不会有什么要求了~2.6C都能跑~但是如果将DMOL3作为一个参量计算形式挂在其他的东西上面一起跑就 ...

作者: bessel    时间: 2007-4-19 16:48
鬼佬的机器比国内还难用,算不出结果要滚蛋的。不像国内,想怎么浪费就怎么浪费。你要定期report你算了啥,出了啥结果。机时费也是要钱的。
很多不需要那么大计算量的工作的人就用pc算,我给你举个美国的例子,有个家伙拿过aps的计算物理方面的奖,独立的开创了一个领域,现在他的
同行都在用数十个处理器数百G的内存的机器干,人家还是在用双路的破pc算。就算是在nano和材料方面,也不是靠拼机器出来的,某人说过“不是买了机器和软件
就能很好的作材料科学的”。大学里面多数一流的计算组还是在用普通的x86集群,最多双路而已。那些努强筋的机器是给一些极端需要计算量的情况用的。

计算不是越大越好,不针对谁。

原帖由 mooncocoon 于 2007-4-19 16:32 发表
另外~鬼佬是没有自己的机器,可是别人学校里都是怒强劲的服务器~你要算什么,提个申请,然后将数据和计算方法打个包或者写个详细申请,人家就会分机时给你了~
(jubm]B2`电脑城,网上交易,电脑硬件,买卖,二手交易,商城,显卡,硬盘,处理器,销售,网上商店,ATi,NVIDIA,G80,R600国内想跑点东西完全要靠自己啊……

作者: bessel    时间: 2007-4-19 16:50
你说了我想说的。w00t)

原帖由 potomac 于 2007-4-19 12:58 发表
这样也叫搞科学啊。:funk: :thumbsup:
偶看这样的实验室不如撤了,大家出去撮一顿,再来个massage。B)

作者: mooncocoon    时间: 2007-4-19 17:04
我想,十几K以上原子的分子动力学模拟不是靠脑子或者随便一台机器就能跑出来的吧~要不我发给你一台双OP265你给我跑个10W原子看看~?
这已经不是人有多大胆地有多大产的年代了~极个别的例子不能说明问题的~正确的做法是明白自己为什么要跑这样规模的运算然后寻找合适的计算载体,不是拼脑力走捷径
我不忽略人的因素,但是起码客观因素是存在的,盲目忽略客观因素而且直接叫喊说别人不合适搞这个行当而且让别人OUT~到底谁该QUIT呢~?


另外~本末一定不能倒置~买这台机器跟跑DMOL3出问题要打算买新机器完全是风马牛不相及的两回事~我有说过买这台机器是因为之前的双OP265跑DMOL3出问题了么~?究竟是你不理解我们买机器的态度呢还是你给我们扣了个帽子呢~?
如何用FORTURN将DMOL3外挂到别的运算组件上的方式我们完全是按照公司的指导进行的~而且在OP那台机器上的实践证明我们的子程序设计完全没有问题并且PASS了他们要做的所有测试,公司方面没有跟我们说过我们的子程序无法使用在新平台上,怎么到你这里就成了我们不好好看手册了呢~?手册会告诉你如何使用汇编~?

让别人做些什么之前,最好先搞清楚别人的状况,盲目的将别人定性不是一个搞科研的该有的对待人的态度

当然,对待物就是另一回事了
作者: mcs_xiaonan    时间: 2007-4-19 17:05
anyway,好消息,过两天答辩的时候人家问我为什么不做更大规模仿真我就赖intel好了:p
作者: bessel    时间: 2007-4-19 17:13
这是谁说的?

原帖由 mooncocoon 于 2007-4-19 12:49 发表
总之因为这个,实验室采购安腾2集群服务器的计划被搁置了,再卖一个OP8系列的服务器的计划被提上来了

作者: mooncocoon    时间: 2007-4-19 17:18
我这是在说跑DMOL3不行要换安腾2么~?我有说过先前打算买安腾2集群是为了什么么~?
难道还不允许根据实际情况来修正先前的采购计划啦~?600W的单子,难道不能慎重么~?选择了INTEL导致我们现在的实际计算过程受阻,无论出与何种考量,难道就不许我们犹豫一下了么~?

我不是很明白为什么很容易明白的问题到你这里就不明白了而且还成了“小辫子”
麻烦你搞清楚前因后果再来宣判我们是不是应该QUIT,好么~?
作者: bessel    时间: 2007-4-19 17:26
你连dmol都要写成dom是负责任的讨论问题么?
明显你们自己的代码出了问题不知道怎么解决,发在这里求助也好,抱怨也好,你怎么得出你标题的结论的,不就是瞎猜么?
你自己说因为你们这个有毛病的程序就要推迟itanium,买个amd 8xx的机器,为什么不好好找找毛病先?
如果你的应用特殊,程序本身没毛病,那就是说明确实xeon不适合,连这个都不清楚就继续买amd 8xx机器做什么,这是负责任的对待funding的态度么?


原帖由 mooncocoon 于 2007-4-19 17:18 发表
我这是在说跑DMOL3不行要换安腾2么~?我有说过先前打算买安腾2集群是为了什么么~?
难道还不允许根据实际情况来修正先前的采购计划啦~?600W的单子,难道不能慎重么~?选择了INTEL导致我们现在的实际计算过程受 ...

作者: bessel    时间: 2007-4-19 17:33
谁知道你要干什么,但是你们显然是在用xeon做benchmark来考虑进一步的算例。


原帖由 mooncocoon 于 2007-4-19 17:18 发表
我这是在说跑DMOL3不行要换安腾2么~?我有说过先前打算买安腾2集群是为了什么么~?
难道还不允许根据实际情况来修正先前的采购计划啦~?600W的单子,难道不能慎重么~?选择了INTEL导致我们现在的实际计算过程受 ...

作者: mooncocoon    时间: 2007-4-19 17:34
原帖由 bessel 于 2007-4-19 17:26 发表

明显你们自己的代码出了问题不知道怎么解决,发在这里求助也好,抱怨也好,你怎么得出你标题的结论的,不就是瞎猜么?
你自己说因为你们这个有毛病的程序就要推迟 ...

又给我定性

ACCELRYS的认证和测试还不如你一句话来得实在~我明白了~我们跟ACCELRYS都错了~你才是正确的~我们都不应该干这个~我们都应该QUIT

唉……楼上一席话惊醒我们跟ACCELRYS两个梦中人啊……
作者: mooncocoon    时间: 2007-4-19 17:37
原帖由 bessel 于 2007-4-19 17:33 发表
谁知道你要干什么,但是你们显然是在用xeon做benchmark来考虑进一步的算例。



你不是已经知道了么~?我们态度有问题应该QUIT啊~你怎么现在又不知道了呢~?这么健忘~?
原帖由 bessel 于 2007-4-19 16:39 发表
你们都不看dmol的手册了解一下这东西在不同平台的性能,出了问题就打算买新机器的态度的确很难让人理解。我觉得你们不太适合在计算物理这个行当里。
早点quit吧。

作者: jaguard    时间: 2007-4-19 17:39
这类应用本身就是AMD的强项,不过差别这么大系统或者软件应该有啥问题,内存操作再多也拉不开那么大的差距
作者: bessel    时间: 2007-4-19 17:41
你一开始有告诉大家你们具体做了什么么?

你只是说你们在用dom3其实是dmol3,然后算得慢。你既然认真地看过手册,也用过dmol以前,那么你应该知道这个东西的性能;出的问题不是dmol的问题,而是你的
外挂的问题。你的说法不是在误导大家么?这时候你就应该检查你的子程序而不是告诉我们你的结论“科学计算远离intel”,你们作科研,写论文也这样下结论?

“公司方面没有跟我们说过我们的子程序无法使用在新平台上”
是你做科研还是dmol的公司做,公司已经告诉了他们应该告诉你们的,剩下的是你们自己的问题。


原帖由 mooncocoon 于 2007-4-19 17:04 发表
如何用FORTURN将DMOL3外挂到别的运算组件上的方式我们完全是按照公司的指导进行的~而且在OP那台机器上的实践证明我们的子程序设计完全没有问题并且PASS了他们要做的所有测试,,怎么到你这里就成了我们不好好看手册了呢~?手册会告诉你如何使用汇编~?

作者: xiaxiaf    时间: 2007-4-19 17:41
提示: 作者被禁止或删除 内容自动屏蔽
作者: bessel    时间: 2007-4-19 17:45
你空对空,俺们也只好空对空给你定性。

原帖由 mooncocoon 于 2007-4-19 17:34 发表

又给我定性

ACCELRYS的认证和测试还不如你一句话来得实在~我明白了~我们跟ACCELRYS都错了~你才是正确的~我们都不应该干这个~我们都应该QUIT

唉……楼上一席话惊醒我们跟ACCELRYS两个梦中人啊……

作者: Prescott    时间: 2007-4-19 17:45
原帖由 xiaxiaf 于 2007-4-19 17:41 发表
LZ其实把2个结果说反了就不会这样有人怀疑你了,在有些人看来intel是不可能落后别人的.


X5355比OP265快3倍还真有可能。反过来可能性就不大了。
作者: mooncocoon    时间: 2007-4-19 17:49
原帖由 bessel 于 2007-4-19 17:41 发表
你一开始有告诉大家你们具体做了什么么?

你只是说你们在用dom3其实是dmol3,然后算得慢。你既然认真地看过手册,也用过dmol以前,那么你应该知道这个东西的性能;出的问题不是dmol的问题,而是你的
外挂的 ...

所以说你是强人~ACCELRYS的认证和测试还不如你一句话来得实在~一个通过ACCELRYS认证和测试的普适外挂程序这么快就被你判断成出了问题,而且最关键的是我们一直用的好好的计算过程在你这里都是有问题的了
公司方面确实不做科研,但是ACCELRYS是要对自己的程序负责的~
不过呢,现在看来他们明显没有你负责~别人测试了1个多月,你一句话就结束了
我们跟ACCELRYS都错了~你才是正确的~我们都不应该干这个~我们都应该QUIT

我想反驳一下楼上那个说IF的~这里喜欢INTEL的人相当一部分还是非常客观和热心的~Prescott跟我PM讨论了问题可能出现的地方并且给出了可行的解决方案,再此表示感谢。如果问题因此得到解决,我想某个教育我怎样做科研的人应该思考一下自己说过的话了

[ 本帖最后由 mooncocoon 于 2007-4-19 17:50 编辑 ]
作者: bessel    时间: 2007-4-19 17:50
除了dgemm这类应用以外恐怕没戏,多数科学计算受制于内存带宽。


原帖由 Prescott 于 2007-4-19 17:45 发表

X5355比OP265快3倍还真有可能。反过来可能性就不大了。

作者: Prescott    时间: 2007-4-19 17:52
原帖由 bessel 于 2007-4-19 17:50 发表
除了dgemm这类应用以外恐怕没戏,多数科学计算受制于内存带宽。



有可能嘛,只要存在一个就行,找一两个X5355快过Op265 3倍的还是比较容易的。
想找几个OP265比X5355快3倍的程序,那就难多了不是?
作者: bessel    时间: 2007-4-19 17:53
原帖由 Prescott 于 2007-4-19 17:52 发表

有可能嘛,只要存在一个就行,找一两个X5355快过Op265 3倍的还是比较容易的。
想找几个OP265比X5355快3倍的程序,那就难多了不是?

这就有一个啊,多好啊。
作者: Prescott    时间: 2007-4-19 17:56
原帖由 bessel 于 2007-4-19 17:53 发表

这就有一个啊,多好啊。

:sweatingbullets:
已经和LZ谈过了,内存使用量超过可用物理内存。让他换64bit OS和软件去了。

[ 本帖最后由 Prescott 于 2007-4-19 17:59 编辑 ]
作者: HeavenPR    时间: 2007-4-19 17:59
...........

VM 都一起上了,那性能直接降到 1% :funk:
作者: bessel    时间: 2007-4-19 18:06
ok,你的程序可以在a上跑,在i上就不行,这是现在的问题。

公司测了一个月都测了什么?
你测了多久,都检查了什么?

一直用的好好的不见得没有问题,毕竟是使用了不同的平台,不同平台出问题是很正常的事情,如果你有对于不同平台特别的优化。

最简单的,单独的dmol是否在两个平台可以有正常的速度和结果。以及你做的计算中间过程是否一致。

不同的优化下来可能有极小的机器误差,或许你们的机器误差影响了计算,不能收敛,你检查过中间步骤没有?

原帖由 mooncocoon 于 2007-4-19 17:49 发表
一个通过ACCELRYS认证和测试的普适外挂程序这么快就被你判断成出了问题,而且最关键的是我们一直用的好好的计算过程在你这里都是有问题的了

别人测试了1个多月

原帖由 mooncocoon 于 2007-4-19 12:48 发表
整机需要5W,买U的时候被狠宰了一把,一快1W2

找了几天时间的原因了,没有头绪,计算模型~调用内存数~计算量设置~操作系统全部一样,AMD这边的系统还要老整整1年……

事实让人崩溃,除非你打算跟我说2003 ...

作者: bessel    时间: 2007-4-19 18:10
细节。

那个amd机器怎么没问题?两个一个开了pae一个没开?
一个读内存一个读硬盘还是两个都读硬盘?
读硬盘的机器怎么可能cpu 100%。


原帖由 Prescott 于 2007-4-19 17:56 发表

:sweatingbullets:
已经和LZ谈过了,内存使用量超过可用物理内存。让他换64bit OS和软件去了。

作者: Prescott    时间: 2007-4-19 18:17
原帖由 bessel 于 2007-4-19 18:10 发表
细节。

那个amd机器怎么没问题?两个一个开了pae一个没开?
一个读内存一个读硬盘还是两个都读硬盘?
读硬盘的机器怎么可能cpu 100%。



我猜想:两个都读,但是我不知道这个程序的行为,这个需要你这个专家告诉我,有没有可能8个线程的情况下程序malloc的内存更多?还有一种可能是更多的并行度加大了page fault的频度和颠簸。

具体的细节问楼主吧。

如果是page fault造成的交换,CPU是会到100%的。

[ 本帖最后由 Prescott 于 2007-4-19 18:19 编辑 ]
作者: bessel    时间: 2007-4-19 18:28
楼主说是一样的内存使用,w00t) 这个得他回答。

读swap的时候从windows那个任务管理器看可能是100%
代码里如果检测cpu时间恐怕是0%,难道楼主是按了alt-ctrl+del检测的?

作科学计算用到swap的还是请他自个儿来定性吧。不过貌似有些量化软件曾经这样干过,那时候人们只有几百兆内存。


原帖由 Prescott 于 2007-4-19 18:17 发表

我猜想:两个都读,但是我不知道这个程序的行为,这个需要你这个专家告诉我,有没有可能8个线程的情况下程序malloc的内存更多?还有一种可能是更多的并行度加大了page fault的频度和颠簸。

具体的细节问楼 ...

作者: cjmgz    时间: 2007-4-19 18:56
怎么AMD比INTEL快了
LZ就给人扣上帽子了?
虽然扣肉比K8好,不排除有某些情况下反过来吧...
AMD不是那么见鬼吧?跑个程序快了,连用的人都变有问题
不知道怎么说好类
作者: ITANIUM2    时间: 2007-4-19 19:10
我说个相反的例子:
有限差分法, 内存大小不是瓶颈
都是O2 优化

K8 3500+  vs.  woodcrest 5160
>35 min    vs.  <10min
作者: ITANIUM2    时间: 2007-4-19 19:12
原帖由 Prescott 于 2007-4-19 17:56 发表

:sweatingbullets:
已经和LZ谈过了,内存使用量超过可用物理内存。让他换64bit OS和软件去了。


原来如此
Prescott 好敬业啊:lol:
作者: bessel    时间: 2007-4-19 20:23
还有一种可能是xeon使用的是双通道fb-dimm而不是4通道,这样amd有2倍的带宽优势以及延时上有优势。


原帖由 Prescott 于 2007-4-19 17:45 发表

X5355比OP265快3倍还真有可能。反过来可能性就不大了。

作者: zaarath    时间: 2007-4-19 22:46
原帖由 cjmgz 于 2007-4-19 18:56 发表
怎么AMD比INTEL快了
LZ就给人扣上帽子了?
虽然扣肉比K8好,不排除有某些情况下反过来吧...
AMD不是那么见鬼吧?跑个程序快了,连用的人都变有问题
不知道怎么说好类



把帖子看仔细了,现在说的不是AMD比Intel快,而是说OP265比X5355快9倍。。。 这可能么?楼主在不明原因的情况下就下结论,所以遭到质疑。
作者: cap    时间: 2007-4-19 23:51
楼主搞科学计算的嘛
应该学会用Vtune和threadprofile之类的软件
看看每个thread是否真的都在满负载运行,还是互相等待memory allocation或者I/O
用Vtune看看每个thread hotspot 是否是在系统调用,那就很值得研究(比如前面prescott分析的在32bit OS中超过4G内存分配导致分配错误就可能出现这种现象)
总之你做学问总要花点时间细心研究下
不太懂计算机的话这里也有很多人可以问
再不济可以直接打电话找intel AE support,人不过来问问还是可以
(btw 如果是AMD大概就不会有人帮你了)
作者: Prescott    时间: 2007-4-19 23:54
原帖由 cap 于 2007-4-19 23:51 发表
楼主搞科学计算的嘛
应该学会用Vtune和threadprofile之类的软件
看看每个thread是否真的都在满负载运行,还是互相等待memory allocation或者I/O
用Vtune看看每个thread hotspot 是否是在系统调用,那就很值得 ...

100% Intel employee. )_)
作者: cap    时间: 2007-4-20 00:01
原帖由 Prescott 于 2007-4-19 23:54 发表

100% Intel employee. )_)

我amd的
建议楼主用perfmon2:lol:
作者: Prescott    时间: 2007-4-20 00:02
原帖由 cap 于 2007-4-20 00:01 发表

我amd的
建议楼主用perfmon2:lol:

真的假的 :wacko:
作者: init0    时间: 2007-4-20 01:02
科学运算?换64-bit Linux吧
作者: pzgz    时间: 2007-4-20 04:29
搞科研的,hoho...........
作者: feiying2222    时间: 2007-4-20 07:07
呵呵,绝对不正常!
作者: akeyyeka    时间: 2007-4-20 08:48
如果是内存不够导致swap, taskmanager里performance那个tab上把show kernel time打开, 如果kernel time很高, 那么存在可能是内存不够导致page fault, 如果kernel time很低, 那么应该就不是swap的问题. 虽然没有perfmon, vtune, thread profiling tool这些来得精确, 但是对于快速初步判断是有一些帮助的.
作者: colddawn    时间: 2007-4-20 09:55
该说的楼上大虾们都说了,拿VM和内存比造成什么差距可能都不奇怪
只补充一点:即使是因为Xeon性能差于Operton,也不能作为废止IA-64的依据,因为Xeon与IA-64的差异远比同为IA-32(e)的Xeon与Operton大
作者: 西门吹雪    时间: 2007-4-20 11:21
Intel VS TSMC IBM,吵吧吵吧
作者: 红发IXFXI    时间: 2007-4-20 11:41
:huh: 期待LZ的最终结果。。。。。
作者: 左手    时间: 2007-4-20 12:02
挖,这帖子我要能看懂估计混日子就没问题了
作者: 飘过778    时间: 2007-4-20 12:06
提示: 作者被禁止或删除 内容自动屏蔽
作者: ITANIUM2    时间: 2007-4-20 13:16
原帖由 飘过778 于 2007-4-20 12:06 发表
不知道你们实验室在做什么实验,投入这么大的精力和金钱用2台机子跑一样的东西,还跑了11天,估计你们实验室的人都没什么事做,是在帮INTEL和AMD做对比测试吗?


对科学计算来说,这个小意思了
作者: itany    时间: 2007-4-20 13:39
原帖由 free818 于 2007-4-20 13:32 发表
楼主说事实,却引来I FANS们不满.:lol:


mydrivers的网友现在都到PCI来转转? (_( :wacko:
作者: jgzyinnv    时间: 2007-4-20 15:02
汗,楼主这样的资深前辈仅仅因为说了一个实验的来的事实,就遭到了无数I棍的强烈愤慨和严重质疑,要是普通网友还不被I棍的口水淹死
作者: soft    时间: 2007-4-20 15:20
原帖由 jgzyinnv 于 2007-4-20 15:02 发表
汗,楼主这样的资深前辈仅仅因为说了一个实验的来的事实,就遭到了无数I棍的强烈愤慨和严重质疑,要是普通网友还不被I棍的口水淹死



有人怀疑事实嘛?

怀疑的只是楼主推出的结论而已

不要说扣帽子,看看楼主的标题是什么

倒是Afan都一致认为就是cpu的问题,根本没提什么建设性意见
作者: gigisor    时间: 2007-4-20 15:46
LZ是哪个学校的?
我们这也是作模拟计算的,主要是MC,MD,模拟和SCFT自恰场计算,,06年四月上的OPE 275*2,效率确实高,即使更早以前的买的OPE 242*2 比最早买入的一批XEON 2.8G*2快得多。所以现在INTEL的服务器一律不考虑,呵呵。
作者: jaguard    时间: 2007-4-20 19:55
原帖由 gigisor 于 2007-4-20 15:46 发表
LZ是哪个学校的?
我们这也是作模拟计算的,主要是MC,MD,模拟和SCFT自恰场计算,,06年四月上的OPE 275*2,效率确实高,即使更早以前的买的OPE 242*2 比最早买入的一批XEON 2.8G*2快得多。所以现在INTEL的服务器 ...

现在不是P4 XEON和OP比,那没法比的,楼主用的是酷睿XEON,那个速度差别应该还是软件还是系统设置问题,差别太大了
作者: qq4327    时间: 2007-4-20 19:57
hahahaha...............

留名
作者: skywalker_hao    时间: 2007-4-20 20:05
原帖由 toscana007 于 2007-4-20 19:44 发表
I fan 还陶醉在PI的胜利中不能自拔

可惜,pi实质上很全面了,只不过还不够庞大
能在pi上赢了的cpu,其他地方会差到哪里去?
作者: jaguard    时间: 2007-4-20 20:21
原帖由 toscana007 于 2007-4-20 20:17 发表
PI不过是利用了I u不错的整数能力罢了,不要一提PI就想到浮点

PI是整数运算
作者: potomac    时间: 2007-4-20 20:27
提示: 作者被禁止或删除 内容自动屏蔽
作者: elisha    时间: 2007-4-20 20:31
原帖由 gigisor 于 2007-4-20 15:46 发表
LZ是哪个学校的?
我们这也是作模拟计算的,主要是MC,MD,模拟和SCFT自恰场计算,,06年四月上的OPE 275*2,效率确实高,即使更早以前的买的OPE 242*2 比最早买入的一批XEON 2.8G*2快得多。所以现在INTEL的服务器 ...

什么年代了,还拿XEON 2.8G*2比:funk: :funk:
作者: Bohr    时间: 2007-4-20 21:04
提示: 作者被禁止或删除 内容自动屏蔽
作者: lxjlan    时间: 2007-4-20 23:47
提示: 作者被禁止或删除 内容自动屏蔽
作者: 89度热水    时间: 2007-4-21 01:35
原帖由 lxjlan 于 2007-4-20 23:47 发表

呵呵。是这样的,有的科学计算用超级计算机都要算上许多天的...


一些大数因式分解,用目前最快的超级电脑,要算几亿年才能得出结果
作者: Bohr    时间: 2007-4-21 02:00
提示: 作者被禁止或删除 内容自动屏蔽




欢迎光临 POPPUR爱换 (https://we.poppur.com/) Powered by Discuz! X3.4