应验：Core再创疯狂奇迹，浮点性能Specfp2000暴3000点大关，诛灭Power5

基于pentium 3的Dothan或者Yonah在游戏方面的性能可是一点都不逊色于K8亚：

http://www.pcinlife.com/article/ ... 49184284d152_9.html

不过Yonah的指令解码/执行效率真糟糕：

http://www.pcinlife.com/article/ ... 49184284d152_6.html

Conroe的指令解码/执行效率比Yonah好多了，只是prefiex指令方面还不能和K8比：

http://www.pcinlife.com/article/ ... 4158113d191_22.html

应该是测试水平真差，还有对体系结构的理解真不到位。很多时候，根本不是在测试解码而是比ALU数量了。

举例子：
P-M是双整数ALU。 傻比ALU数量有啥用?

K8有3个整数ALU，如果傻比，K8多了50%。 看看整数性能的对比是什么结果呢?
2.2G
PM          1839  远超过 K8            1573
http://www.spec.org/osg/cpu2000/ ... 20051212-05228.html
http://www.spec.org/osg/cpu2000/ ... 20050805-04445.html

就和那个比浮点除法延迟一样傻。 要比浮点除法延迟Core2也没K8好。脑子走极端了。 就以为K8浮点比Core2强

再好的测试如果你连判读都理解错误甚至根本看都不看当然是会变成"水平很差"，最奇怪的是居然还拿CPU2000这个IPC很多时候都达不到1IPC的东西来说明基于汇编的指令解码/执行测试是乱比，谁走极端而且是先入为主大家一目了然。

如果你有更好的指令解码效率测试方式，我是不妨看看的。

是你没能够看懂，这句话：“很多时候，根本不是在测试解码而是比ALU数量了”

另外，对于前缀的测试， 就比较好笑了。 这种组合没啥意义。

那是因为你没有看到原文的："透过这个测试，我们可以首先获得CPU在执行某个指令时候的指令cache带宽，然后根据指令的字节长度得出CPU对该指令的执行/解码能力。"

如果前缀的部分没任何意义，Intel就根本不会把这部分内容写在新的优化指南中。

没看出来有多少科学依据

你这种组合没啥意义

这样的测试方式本身就注定了会受到i-cache、decoded i-cache、fill unit、ALU等因素的影响，不过从测试结果来看，和一些使用相对复杂工具的测试结果相比是相当接近的，例如寄存器-寄存器的指令解码率在P6上也就是略高于1.3 IPC的水平。

你这个是没准的。 就好像认为 重的物体下落快， 轻的慢。 结果看上去和真像(重力&空气阻力的效果) 差不多哦

但真像绝对不是这麽回事。

原帖由 hopetoknow 于 2006-12-9 14:41 发表
你这个是没准的。 就好像认为 重的物体下落快， 轻的慢。 结果看上去和真像(重力&空气阻力的效果) 差不多哦

但真像绝对不是这麽回事。

完全不对,您的高中物理是怎么学的

下落速度取决于重力,空气阻力,和空气浮力与质量的比值

换句话说,和质量本身完全没有关系(除非涉及量子物理的弱相对力,汗)

不信?10公斤棉花一定比1公斤铁球下来的慢

原帖由 ghrs2010 于 2006-12-9 14:45 发表


完全不对,您的高中物理是怎么学的

下落速度取决于重力,空气阻力,和空气浮力与质量的比值

换句话说,和质量本身完全没有关系(除非涉及量子物理的弱相对力,汗)

不信?10公斤棉花一定比1公斤铁球下来的慢

这不是结果相近但却是错误的观点吗


只是少说了空气浮力