POPPUR爱换

标题: 新编译器助Opteron大幅超越Xeon [打印本页]

作者: acqwer 时间: 2007-10-26 12:29
标题: 新编译器助Opteron大幅超越Xeon
意法半导体旗下全资子公司Portland Group宣布推出新版编译器“PGI 7.1”，可以让AMD的四核心Opteron 2.5GHz比Intel的四核心Xeon X5365还要快27％。
测试结果来源于SPECfp_rate-base2006，Intel Xeon使用的编译器是其自家的Intel 10.1。
新的PGI 7.1包括经过优化的PGI编译器、针对Mac平台的工具，以及一个Windows工具套装，支持在高性能PC(IPC)上调试MSMPI。PGI 7.1也支持多路Xeon系统，并提供可视化调试界面和配置工具。
Portland项目主管Douglas Miles表示，PGI 7.1是最快的Fortran编译器和C/C++编译器，在性能上相比7.0版提高了10％以上。
Portland指出，开发人员正面临严峻挑战，迫切需要改进沿用已久的古老方式，充分挖掘多核心处理器的优势。

AMD的公关们偶尔也玩点别的花样吧，九月的新闻已经翻出来多少次了。

作者: 4X4 时间: 2007-10-26 13:05
如果软件商们能早一点针对sse2甚至应用intel c++编译和优化软件，AMD在5~6年前就倒闭了。

作者: elisha 时间: 2007-10-26 13:24
amd现在也只能整天比比rates了

作者: 紫色 时间: 2007-10-26 14:01
在最求性能的环节里，编译器是最重要的一环，甚至比硬件还重要。

作者: Prescott 时间: 2007-10-26 14:03

原帖由紫色于 2007-10-26 14:01 发表
在最求性能的环节里，编译器是最重要的一环，甚至比硬件还重要。

我记得前几天你还说gfort很好很强大来着。怎么变这么快？:huh:

作者: 紫色 时间: 2007-10-26 14:08
intel fortran总的来说是快些，但是buggy。优化的太厉害了。

http://www.programfan.com/club/post-253885.html

这是那个论坛第二次向intel报告bug了。

而且，那是两码事嘛。

[ 本帖最后由紫色于 2007-10-26 14:28 编辑 ]

作者: Prescott 时间: 2007-10-26 14:12

原帖由紫色于 2007-10-26 14:08 发表
intel fortran总的来说是快些，但是buggy。优化的太厉害了。

http://www.programfan.com/club/post-253885.html

这是那个论坛第二次向intel报告bug了。

报告bug算什么？我都不知道报了多少bug了。PGI的bug还不是一样多。

作者: 紫色 时间: 2007-10-26 14:14
P大是巨人，我无限敬仰。

作者: 晶晶守护神 时间: 2007-10-26 14:16
提示: 作者被禁止或删除内容自动屏蔽

作者: acqwer 时间: 2007-10-26 14:17

原帖由紫色于 2007-10-26 14:01 发表
在最求性能的环节里，编译器是最重要的一环，甚至比硬件还重要。

问题不在这里，9月发布的K10成绩就是用PGI7.1跑的。也就是说AMD的公关们用同一个成绩换了N次标题发了N次新闻。

作者: gore4life 时间: 2007-10-26 14:23
怀疑AMD是不是把萨哈夫收编了？:blink:

作者: itany 时间: 2007-10-26 14:30

原帖由紫色于 2007-10-26 14:01 发表
在最求性能的环节里，编译器是最重要的一环，甚至比硬件还重要。

可惜AMD自家没有编译器，照这样说只能算半个CPU公司……

作者: 紫色 时间: 2007-10-26 14:47
没关系，有intel大哥呢，通过 -xW -xO之类的选项，amd U也得到了很好的支持: intel为了卖编译器(编译器上千美元, 等于卖掉多少U), 也提供对amd U的优化.
而且编译器不一定要自己干。帮助GCC提高性能，提供对自家k8优化的库，第三方的编译器(如pgi) ,条条大路通罗马啊.

作者: catxing 时间: 2007-10-26 15:06

原帖由 itany 于 2007-10-26 14:30 发表

可惜AMD自家没有编译器，照这样说只能算半个CPU公司……

这个还击太狠鸟.....

作者: free818 时间: 2007-10-26 16:02
INTEL看来不行了.:lol:

作者: the_god_of_pig 时间: 2007-10-26 18:14

原帖由 acqwer 于 2007-10-26 14:17 发表

问题不在这里，9月发布的K10成绩就是用PGI7.1跑的。也就是说AMD的公关们用同一个成绩换了N次标题发了N次新闻。

不要拆台嘛，AMD只是要强调一下他们的k10用最新的编译器仍然K不过同频Xeon而已:charles:

http://www.spec.org/cpu2006/results/res2007q3/cpu2006-20070903-01949.html

http://www.spec.org/cpu2006/results/res2007q2/cpu2006-20070514-01054.html

作者: 紫色 时间: 2007-10-26 22:19
一眼望去，全部都是些只知道YY，只知道跑分，只知道“理论最大性能”的举人。岂不知编译器能让程序快个2倍3倍是常有的事情啊。
这些人等待45nm喷乳上市的心情，就像是等待着女人洗完澡的男人正躺在床上憧憬着即将到来的性高潮。
厂商很欣赏这种心态。正等着这些小白入彀。

[ 本帖最后由紫色于 2007-10-26 22:20 编辑 ]

作者: AMD11 时间: 2007-10-26 22:32

原帖由紫色于 2007-10-26 22:19 发表
一眼望去，全部都是些只知道YY，只知道跑分，只知道“理论最大性能”的举人。岂不知编译器能让程序快个2倍3倍是常有的事情啊。
这些人等待45nm喷乳上市的心情，就像是等待着女人洗完澡的男人正躺在床上憧憬着即将到 ...

太强了，Intel等干吗花这么多钱推出新构架？专心研究编译器就行了。:w00t)::thumbsup:

作者: acqwer 时间: 2007-10-26 23:11

原帖由紫色于 2007-10-26 22:19 发表
一眼望去，全部都是些只知道YY，只知道跑分，只知道“理论最大性能”的举人。岂不知编译器能让程序快个2倍3倍是常有的事情啊。
这些人等待45nm喷乳上市的心情，就像是等待着女人洗完澡的男人正躺在床上憧憬着即将到 ...

差不多每一句话都是坑的人还是少发表些这种装B的言论吧。

作者: itany 时间: 2007-10-26 23:21
另外再说一句，如果不是SSE，编译器还优化啥？
就展开个循环啥的？

作者: 紫色 时间: 2007-10-26 23:22

原帖由 acqwer 于 2007-10-26 23:11 发表

差不多每一句话都是坑的人还是少发表些这种装B的言论吧。

哦。请阁下告诉我，你这句的“信息”是啥？

你认为我哪里错了直接就踢好了，弄出这种“零信息”的P话对我有什么作用？我就算每句话都是坑，也比你句句都是空气要强。
你真有能耐就不是这样了。阁下什么时候才能ZW够呢？

作者: acqwer 时间: 2007-10-26 23:29

原帖由紫色于 2007-10-26 23:22 发表

哦。请阁下告诉我，你这句的“信息”是啥？

你认为我哪里错了直接就踢好了，弄出这种“零信息”的P话对我有什么作用？我就算每句话都是坑，也比你句句都是空气要强。
你真有能耐就不是这样了。阁下什么时候才 ...

第一、在最求性能的环节里，最重要的是代码优化而不是编译器。

第二、这里没有任何人否认过编译器的作用，曲解他人的意思，yy出个前提并以此为依据开喷的通常都是低素质的小白。

第三、期待更新、更强的产品上市对用户来说是很正常的事，连这都要喷的人除了装B外还有什么可以形容？

作者: 紫色 时间: 2007-10-26 23:44
我想这里编译器的意思是从源码到可执行文件的全套工具，包括了代码优化。我请你看看自己顶楼的帖子。

作者: acqwer 时间: 2007-10-26 23:51

原帖由紫色于 2007-10-26 23:44 发表
我想这里编译器的意思是从源码到可执行文件的全套工具，包括了代码优化。我请你看看自己顶楼的帖子。

顶楼的帖子？Spec什么时候允许进行源码的优化了，什么编译器又能自动进行源代码的优化？

作者: 紫色 时间: 2007-10-26 23:55
编译器的优化当然值得是生成优化的二进制代码。我从头到尾都是这个意思。

[ 本帖最后由紫色于 2007-10-26 23:56 编辑 ]

作者: acqwer 时间: 2007-10-27 00:14
好的源代码可以在差的编译器上也能发挥出不错的性能，好的编译器无法让一个差的源码跑出好性能。

作者: Ricepig 时间: 2007-10-27 02:42

原帖由 itany 于 2007-10-26 23:21 发表
另外再说一句，如果不是SSE，编译器还优化啥？
就展开个循环啥的？

编译器优化这么简单的话，也不会有n多国际一流论文期刊了~~~
衡量指令执行的代价和指令之间顺序的代价，消除无谓的语句，识别代码块并将其优化为较快速的机器代码
SSE优化只是里面一小部分吧。

作者: Ricepig 时间: 2007-10-27 02:43

原帖由 acqwer 于 2007-10-27 00:14 发表
好的源代码可以在差的编译器上也能发挥出不错的性能，好的编译器无法让一个差的源码跑出好性能。

好的源代码可以在好的编译器上发挥更好的性能~~~
好的编译器能让差的代码得到比好的代码更多益处~~~

[ 本帖最后由 Ricepig 于 2007-10-27 02:45 编辑 ]

作者: Ricepig 时间: 2007-10-27 02:44

原帖由 acqwer 于 2007-10-26 23:29 发表

第一、在最求性能的环节里，最重要的是代码优化而不是编译器。

代码优化是终极手段，但也是最“贵”的手段，远没有编译器优化和升级硬件来的那么容易和廉价

作者: Intelife 时间: 2007-10-27 08:22

原帖由 acqwer 于 2007-10-27 00:14 发表
好的源代码可以在差的编译器上也能发挥出不错的性能，好的编译器无法让一个差的源码跑出好性能。

编译器进行代码优化的作用就是让一个差的源码跑出好性能。好的编译器能让一个很差的源码跑出和好的源码差不多的性能，甚至比好的源码更好的性能。
好的源代码在差的编译器上生成的代码也可能会很差。另外，好的源码不一定是生成代码性能最好的源码。好的源码大部份时候会为了可读性牺牲性能。

作者: acqwer 时间: 2007-10-27 09:11
LS几位找个编译器让SuperPI跑的比Wpirme更快如何。

作者: 蒙大拿 时间: 2007-10-27 09:20
:loveliness: 代码优化当然可以,同样一个函数,不同的编译器进行编译后,只要功能保证一致,而实现功能的代码可以不同.一个更好的代码串来实际相同的功能,就是代码优化.

作者: 蒙大拿 时间: 2007-10-27 09:20
:funk: 实现

作者: potomac 时间: 2007-10-27 14:00
提示: 作者被禁止或删除内容自动屏蔽

作者: the_god_of_pig 时间: 2007-10-27 17:04

原帖由紫色于 2007-10-26 22:19 发表
一眼望去，全部都是些只知道YY，只知道跑分，只知道“理论最大性能”的举人。岂不知编译器能让程序快个2倍3倍是常有的事情啊。

一眼望去，就看见你这个只知道YY，只知道编译器，只知道所谓的“理论最大性能”的举人。岂不知CPU数量翻几翻能让程序快个2倍3倍是常有的事情啊。
:devil:

作者: Ricepig 时间: 2007-10-27 17:32

原帖由 acqwer 于 2007-10-27 09:11 发表
LS几位找个编译器让SuperPI跑的比Wpirme更快如何。

代码优化成本是很高的，编译器优化只需要和让同是super pi的源程序跑得更快就好了，成本低多了。不否认代码优化的实力，但是也不要轻视编译器优化的巨大普适性。

作者: Ricepig 时间: 2007-10-27 17:34

原帖由 potomac 于 2007-10-27 14:00 发表
算法第一，代码第二，编译器最后。:lol:

从优化的幅度来说，可能是这样的排序
但是从广泛适应性和成本来说，编译器第一，代码第二，算法第三

作者: acqwer 时间: 2007-10-27 18:07

原帖由 Ricepig 于 2007-10-27 17:32 发表

代码优化成本是很高的，编译器优化只需要和让同是super pi的源程序跑得更快就好了，成本低多了。不否认代码优化的实力，但是也不要轻视编译器优化的巨大普适性。

我否认过编译器的作用吗？我只说过在最求性能的环节里，最重要的是代码优化而不是编译器。

如果你要开发一个要求高性能的程序，你会随便编个代码实现，然后指望靠编译器来帮你优化？好的算法，适于编译器优化的编码风格才是高性能程序的基础。

作者: the_god_of_pig 时间: 2007-10-27 18:14
明明是木桶啊:sweatingbullets:

作者: Edison 时间: 2007-10-27 18:15
程序员的态度才是最重要的。

作者: acqwer 时间: 2007-10-27 18:22

原帖由 the_god_of_pig 于 2007-10-27 18:14 发表
明明是木桶啊:sweatingbullets:

不是木桶而是积木。

作者: 紫色 时间: 2007-10-27 19:06
不完全同意楼上的看法。
当然算法是最重要的，不用在这里打岔了。代码优化的范围比较大，至少，要求程序员都能对处理器优化代码是比较过分的要求。
一方面，已经积累了大量的代码，而处理器却在更新。
另外，使用sse之类simd指令要求数据的内存对齐；更有效使用cache和内存也需要相关知识。程序员也来自数学物理土木等等各行各业啊，术业有专攻，怎么能要求程序员都掌握相关优化知识呢。
应要求编译器更智能、更聪明。

欢迎光临 POPPUR爱换 (https://we.poppur.com/)