POPPUR爱换

标题: 反编译xcode5的结果来看a7性能提升的主要因素 [打印本页]

作者: largewc 时间: 2013-10-18 16:58
标题: 反编译xcode5的结果来看a7性能提升的主要因素
因为之前frankincense的猜测a7采用了gpu优化，我有点同意，所以反编译了xcode5针对armv8 armv7优化的结果对比了一下性能。

发现了一些很有意思的事情

首先是代码：

- (void)compute
{
for(int i=0;i<21600;i++)
{
gCubeVertexData[i] += 0.2f;
}
}

专门异常简单，因为根据之前的判断，a7主要是流数据优化较多，那么尽量用最简化的流数据处理，就是一个浮点数组都加0.2f

作者: largewc 时间: 2013-10-18 16:59
本帖最后由 largewc 于 2013-10-18 17:00 编辑

编译的时候，发现xcode5有一个很有趣的东西，优化开关增加了一个

除了之前的fastest，加了一个aggressive optimizations。

作者: largewc 时间: 2013-10-18 17:03
本帖最后由 largewc 于 2013-10-18 17:05 编辑

然后为了的对比测试，我先用xcode4.6.3编译了一个armv7和armv7s版本的代码，然后用ida pro反编译，得到这个结果

ida pro无法完全反编译arm的浮点，但是大体可以看到，这个是没有neon优化的。

因为下面的0.2f只有一个，就是一个单浮点计算。

作者: largewc 时间: 2013-10-18 17:08
然后用xcode5，关闭arm64，保留armv7和armv7s，优化选项选择了aggressive optimizations

然后得到这个

发现有了neon优化，这对于apple来说有了历史突破，可以看出来，从循环每次减四个元素可以看出来，是128bit的浮点计算

neon现在ida pro无法分析出代码，但是可以肯定是neon代码无疑，下面的0.2f有四个也正好证明了这个。

这个说明a6是128bit的neon。

作者: largewc 时间: 2013-10-18 17:16
本帖最后由 largewc 于 2013-10-21 14:20 编辑

最后，打开arm64 armv7 armv7s，奇怪的是，编译出来的结果大部分并不是64bit的，仍然是32bit的，所谓的64bit指令并没有存在，可能只保留arm64编译才能完全是64bit的，但是由于本身ida pro并不能分析arm64，要5.7版本加入，等5.7版本出来以后我再分析一下好了。

而且大部分公司应该是arm64 armv7 armv7s全开编译（默认编译就是这样了），并不会只开一个arm64，所以这样也有足够的参考性了。

结果很迷惑，发现代码中一次处理的neon是8个float，目前无法猜测是256bit的neon还是分两次处理（可能有拆解循环优化），不过256bit的概率也不低。

那么a7的性能优势也就是这样了，流处理来自于neon编译器自动优化的结果，对于流水线处理的数据可以大幅度提升，对于物理引擎则不行，因为neon并不包含avx里面的向量专有指令，不能专向优化物理性能。

而且我很怀疑geekbench得编译结果是怎样的，难道是基于sse1编译的？要是这样，bt的成绩是被砍半了。

--------------------------------

现在可以肯定了，arm64就是一个双发射的neon，所以这个编译结果非常靠谱，拆分两次就是为了双发射，这也能解释a7所谓的翻倍性能来源了，对于流数据处理，a7是有可能获得a6一倍性能提升的。

--------------------------------

作者: largewc 时间: 2013-10-18 17:17
本帖最后由 largewc 于 2013-10-18 17:19 编辑

我比较奇怪的是64为什么一个循环处理了两组128bit，而armv7s处理了一组128bit。

也许是a7是256bit neon，或者是为了体现性能差距，故意削弱了a6的性能。

因为如果都是128bit的话，其实可以编译一样的结果的。

其实没什么神奇的，xcode5和ios7是apple第一个能默认编译neon优化的编译器而已，所有程序都被neon优化掉了

neon对于物理作用有限，所以就这样了。

作者: the_god_of_pig 时间: 2013-10-18 17:20
不会汇编的看天书了

作者: largewc 时间: 2013-10-18 17:21
本帖最后由 largewc 于 2013-10-18 17:22 编辑

the_god_of_pig 发表于 2013-10-18 17:20
不会汇编的看天书了

改天反编译一下geekbench x86版本看一下就知道了，如果只用了sse1的话，那么成绩完全可以理解。

现在我只是迷惑a7到底是256bit还是128bit的neon而已了。

作者: largewc 时间: 2013-10-18 17:25
现在感觉arm阵营的编译器跟wintel差距甚远，这是wintel十年前就做得不错的东西了。

作者: the_god_of_pig 时间: 2013-10-18 17:36

largewc 发表于 2013-10-18 17:21
改天反编译一下geekbench x86版本看一下就知道了，如果只用了sse1的话，那么成绩完全可以理解。

现在 ...

geekbench之前被人曝FP测试用的x87，现在估计不敢在这上面做手脚了

作者: potomac 时间: 2013-10-18 17:50
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-18 17:56

potomac 发表于 2013-10-18 17:50
巴菲特：信用如贞操一旦失去便难复原。
做错，和撒谎是两回事。

可能geekbench就是一个测试simd性能的软件

作者: 开普勒 时间: 2013-10-18 18:10

largewc 发表于 2013-10-18 17:17
我比较奇怪的是64为什么一个循环处理了两组128bit，而armv7s处理了一组128bit。

也许是a7是256bit neon， ...

能否换个好点的反汇编工具？你这工具一条NEON指令都显示不出来啊！

而且你这里一条64位指令都没有。64位指令是完全不一样的，连寄存器名字都不同，而且只能运行在A64模式下。A64与以前的A32和T32之间不能interwork。

作者: 开普勒 时间: 2013-10-18 18:17

largewc 发表于 2013-10-18 17:21
改天反编译一下geekbench x86版本看一下就知道了，如果只用了sse1的话，那么成绩完全可以理解。

现在 ...

我反汇编过，x86版本的某些symbol里有sse，某些symbol里用x87。编译器自动向量化的条件比较苛刻，不要指望全给你用sse。

ARMv7版本的倒是没见到用NEON指令。这也很正常，ARMv7的NEON的单精度浮点不完全兼容IEEE754（主要是不处理de-normal number），所以除非特别指明，否则编译器不会帮你向量化。

作者: largewc 时间: 2013-10-18 18:20

开普勒发表于 2013-10-18 18:10
能否换个好点的反汇编工具？你这工具一条NEON指令都显示不出来啊！

而且你这里一条64位指令都没有。64 ...

我说过了，默认的xcode5优化就是这个了，ida pro目前不支持neon，需要5.7支持，不管如何，反正肯定是neon代码无疑了。

arm反汇编做的不多，哪个反编译工具可以反编译neon，发一个看看？

结论就是，xcode5和ios7是第一个苹果能够自动neon化的东西，就这个而已。之前的xcode是没有自动neon优化的。

作者: largewc 时间: 2013-10-18 18:21

开普勒发表于 2013-10-18 18:17
我反汇编过，x86版本的某些symbol里有sse，某些symbol里用x87。编译器自动向量化的条件比较苛刻，不要指望 ...

xcode5只编译armv7一样会有neon代码，新加入的优化选项可以做这个了。

作者: 开普勒 时间: 2013-10-18 18:23

largewc 发表于 2013-10-18 18:20
我说过了，默认的xcode5优化就是这个了，ida pro目前不支持neon，需要5.7支持，不管如何，反正肯定是neon ...

苹果平台的不清楚，我一般用binutils里的objdump来反汇编的。或者你可以试试把你的目标文件拿出来用objdump来反汇编。

另外ARM64模式下的NEON依然是128位的。

作者: largewc 时间: 2013-10-18 18:30

开普勒发表于 2013-10-18 18:23
苹果平台的不清楚，我一般用binutils里的objdump来反汇编的。或者你可以试试把你的目标文件拿出来用objdu ...

那就是苹果的arm64和armv7s有区别，arm64特意做了进一步优化，循环做了一定的拆解，有意拉开一点a7和a6的区别。

作者: 开普勒 时间: 2013-10-18 18:30

largewc 发表于 2013-10-18 18:21
xcode5只编译armv7一样会有neon代码，新加入的优化选项可以做这个了。

嗯，GCC里打开-funsafe-math-optimizations选项的话也是可以在ARMv7上支持单精度浮点NEON的，否则的话只会对整数做矢量化。估计你这个选项也是差不多意思。不过鉴于我上面说的原因，如果你的数据里有de-normal number的话，结果会不精确。

作者: 开普勒 时间: 2013-10-18 18:36

largewc 发表于 2013-10-18 18:30
那就是苹果的arm64和armv7s有区别，arm64特意做了进一步优化，循环做了一定的拆解，有意拉开一点a7和a6的 ...

unroll是为了减少循环里条件跳转的开销，又或者是为了对数据加载做优化（某些架构一次加载多个数据效率会更高）。

作者: largewc 时间: 2013-10-18 19:12

开普勒发表于 2013-10-18 18:30
嗯，GCC里打开-funsafe-math-optimizations选项的话也是可以在ARMv7上支持单精度浮点NEON的，否则的话只会 ...

苹果已经干掉了gcc，xcode5已经彻底不能选择gcc了，只有llvm了。

我同意你的neon优化是有限的，通过对比代码来看，我只是说新的a7所谓的重优化编译不过就是加入neon优化而已。

作者: ifu 时间: 2013-10-18 19:23

largewc 发表于 2013-10-18 17:16
最后，打开arm64 armv7 armv7s，奇怪的是，编译出来的结果大部分并不是64bit的，仍然是32bit的，所谓的64bi ...

不是物理引擎不能通过neon获得加速，Futuremark已经测试过可以加速。
A7的瓶颈不在于此，问题关键是随机访存。做计算机体系结构方向工作的人应该对此会有深刻认识。

作者: daniel_k 时间: 2013-10-18 19:42

largewc 发表于 2013-10-18 18:20
我说过了，默认的xcode5优化就是这个了，ida pro目前不支持neon，需要5.7支持，不管如何，反正肯定是neon ...

弱弱问一句，你这些工具是刚刚出来的么？

如果是刚出来的，那未免有点太渣了吧。ios的程序员都是靠自己手动优化neon的吗？这样岂不是要累死……intel的icc都能无缝升级指令集优化了，这货刚刚能自动优化neon，那在苹果所谓的神优化衬托下，安卓的优化岂不是成了翔

作者: largewc 时间: 2013-10-18 20:33

ifu 发表于 2013-10-18 19:23
不是物理引擎不能通过neon获得加速，Futuremark已经测试过可以加速。
A7的瓶颈不在于此，问题关键是随机 ...

物理引擎neon优化意义很小，bullet开源的，又不是什么新东西，这玩意很难neon优化的。

向量倒是容易基于avx优化，因为avx类似gpu，有了大量的向量指令。

simd指令只对流数据容易优化，随机访问的东西很难做到的。

作者: largewc 时间: 2013-10-18 20:34

daniel_k 发表于 2013-10-18 19:42
弱弱问一句，你这些工具是刚刚出来的么？

如果是刚出来的，那未免有点太渣了吧。ios的程序员都是靠自己 ...

gcc应该是可以开启neon优化的，是llvm不支持而已。

xcode5是刚出来的，之前的4.6版本是不支持neon自动优化的。

作者: ifu 时间: 2013-10-18 20:46

largewc 发表于 2013-10-18 20:33
物理引擎neon优化意义很小，bullet开源的，又不是什么新东西，这玩意很难neon优化的。

向量倒是容易基 ...

数值计算部分剥离是可以获得加速的。
practically the whole CPU time is spent in the soft body solver, PSolve_links. If you pull this function out of Bullet and bench it separately, you do see a 2x speed increase。
极端法，只要控制数据规模在A7的cache范围内，A7也是能获得加速的
实际上Futuremark也模拟了cache命中的情况
As this seemed to make no sense, we spent a few days trying to understand what is happening. The result seems to be that if the soft bodies are arranged in memory so that the CPU can access them in a sequential fashion, you get a 2x to 3x increase in speed.
数值计算不是瓶颈。

作者: largewc 时间: 2013-10-18 20:51

ifu 发表于 2013-10-18 20:46
数值计算部分剥离是可以获得加速的。
practically the whole CPU time is spent in the soft body solve ...

说白了，就是把数据流化了，流化的数据加速的办法多的是。

neon只是其中一种，内存随机访问带来的问题是所有的cpu都要面临的，不只是arm。bt的缓存多一倍，bt的核心数也多一倍。绝对不可能是因为cache导致a7那么差。

vs gcc都可以开启openmp，用多核加速这种流化单线程程序。

vs 2012还可以开启c++ amp用gpu来参与流化处理。

作者: largewc 时间: 2013-10-18 20:55
本帖最后由 largewc 于 2013-10-18 20:57 编辑

ifu 发表于 2013-10-18 20:46
数值计算部分剥离是可以获得加速的。
practically the whole CPU time is spent in the soft body solve ...

谁说数值计算不是瓶颈，物理引擎我们曾经制作过一个，思路借鉴的ode，骨骼运算和物理运算，矩阵优化带来的性能提升是非常明显的，一般最差也是把常规计算simd化，包含arm也是如此。这个很难编译器自动完成的，肯定是手工完成的。

物理计算最大的瓶颈在于超多物体的交叉影响，1000个刚体对于cpu计算物理已经基本不可能了，内存1000个刚体才能占据多少，能有1m吗？

作者: ifu 时间: 2013-10-18 21:08

largewc 发表于 2013-10-18 20:51
说白了，就是把数据流化了，流化的数据加速的办法多的是。

neon只是其中一种，内存随机访问带来的问题 ...

没接触过Xcode，这玩意有performance·monitor之类的玩意吗？
你用硬件计数器统计一下pipeline stall cache miss等等就知道瓶颈出在哪里了

作者: ifu 时间: 2013-10-18 21:15

largewc 发表于 2013-10-18 20:55
谁说数值计算不是瓶颈，物理引擎我们曾经制作过一个，思路借鉴的ode，骨骼运算和物理运算，矩阵优化带来的 ...

数值计算可能是瓶颈也可能不是，要具体问题具体分析。
就A7现在碰见的3DMark情况来说数值计算是瓶颈，因为它们的工作人员已经测试过。
这个不光和数量有关还和data layout有关

作者: largewc 时间: 2013-10-18 21:18
本帖最后由 largewc 于 2013-10-18 21:21 编辑

ifu 发表于 2013-10-18 21:08
没接触过Xcode，这玩意有performance·monitor之类的玩意吗？
你用硬件计数器统计一下pipeline stall ca ...

没办法在真机上评测别人的程序吧，无解。

物理由于内存可能性基本没有，物理基本上属于内存访问最少的计算之一了。
物理的特点是交叉访问，物理体之间会存在交叉影响，相当于一个n * n的计算，当然有各种办法减轻了不少，不会是真实的n * n，但是大体也是如此，内存访问却只有n的级别，所以物理不太可能瓶颈在内存。

作者: largewc 时间: 2013-10-21 10:27

开普勒发表于 2013-10-18 18:23
苹果平台的不清楚，我一般用binutils里的objdump来反汇编的。或者你可以试试把你的目标文件拿出来用objdu ...

arm64是双发射的neon，这个可以理解了，这样拆分是为了双发射neon的作用。

现在可以理解a7的性能所谓的“巨大提升”，就是一个双发射的128bit neon，能接近于一个256bit的avx了，geekbench不过就是一个simd的测试，这样的话，a7所谓接近haswell也是有可能的。

作者: acqwer 时间: 2013-10-21 11:16

largewc 发表于 2013-10-21 10:27
arm64是双发射的neon，这个可以理解了，这样拆分是为了双发射neon的作用。

现在可以理解a7的性能所谓的 ...

geekbench并不是测试SIMD的吧，至少PC上的不是.
http://browser.primatelabs.com/geekbench3/126974
http://browser.primatelabs.com/geekbench3/107293

有无AVX，性能几乎没区别，我记得以前别人编译的结果，Geekbench的fp跑的是SSE，连SSE2都没用。

作者: largewc 时间: 2013-10-21 11:20
本帖最后由 largewc 于 2013-10-21 11:26 编辑

acqwer 发表于 2013-10-21 11:16
geekbench并不是测试SIMD的吧，至少PC上的不是.
http://browser.primatelabs.com/geekbench3/126974
ht ...

因为geekbench没用avx，只用了sse而已，新版本应该不止sse1了，我看了，肯定不止sse1，我一阵看看是否支持avx，上次没注意。

虽然neon也是128bit，但是双发射近似于256bit了，只有geekbench编译一个avx版本比，才会比较公平。

simd支持多发射，这个也比较诡异了，之前从来没有见过这么设计的

我认为x86在simd上也不会占优，simd上同样256bit，arm也不会吃亏，simd指令特色决定了。
x86的优势主要还是在常规逻辑，而不是这种特殊领域。

作者: acqwer 时间: 2013-10-21 11:33
本帖最后由 acqwer 于 2013-10-21 11:34 编辑

largewc 发表于 2013-10-21 11:20
因为geekbench没用avx，只用了sse而已，新版本应该不止sse1了，我看了，肯定不止sse1，我一阵看看是否支 ...

we use Xcode 5 on iOS and OS X, Clang 3.3 on Linux, Visual Studio 2012 on Windows, and GCC 4.8 on Android. We're using "-O3 -ffast-math -fvectorize" (or equivalent) compiler optimization switches.

VS用这种设置基本上没SSE2吧。

作者: largewc 时间: 2013-10-21 11:36

acqwer 发表于 2013-10-21 11:33
we use Xcode 5 on iOS and OS X, Clang 3.3 on Linux, Visual Studio 2012 on Windows, and GCC 4.8 o ...

没注意，等等我看看，不过肯定geekbench支持高版本sse，因为出现了高版本的sse指令，我反编译看过的，等一下发截图给你看，这个是肯定的。

应该是128bit的sse，不是256bit的avx

作者: acqwer 时间: 2013-10-21 11:42

largewc 发表于 2013-10-21 11:36
没注意，等等我看看，不过肯定geekbench支持高版本sse，因为出现了高版本的sse指令，我反编译看过的，等一 ...

VS的编译器现在比GCC还烂，矢量化的效果很差。XCode的肯定是做了最优化设置，NDK的优化幅度也在VS默认选项之上。

作者: largewc 时间: 2013-10-21 11:48
本帖最后由 largewc 于 2013-10-21 11:48 编辑

acqwer 发表于 2013-10-21 11:42
VS的编译器现在比GCC还烂，矢量化的效果很差。XCode的肯定是做了最优化设置，NDK的优化幅度也在VS默认选项 ...

http://msdn.microsoft.com/zh-cn/library/vstudio/7t5yh4fd.aspx

/arch:SSE2
允许使用 SSE2 指令。如果 /arch 选项未指定，这是在 x86 平台的默认值命令。

不出意外，geekbench应该基于这个编译的，默认编译选项。

作者: largewc 时间: 2013-10-21 11:50

acqwer 发表于 2013-10-21 11:42
VS的编译器现在比GCC还烂，矢量化的效果很差。XCode的肯定是做了最优化设置，NDK的优化幅度也在VS默认选项 ...

矢量化的效果很差

什么意思呢，不太明白

作者: acqwer 时间: 2013-10-21 11:52

largewc 发表于 2013-10-21 11:48
http://msdn.microsoft.com/zh-cn/library/vstudio/7t5yh4fd.aspx

/arch:SSE2

不是支持就行啊
http://stackoverflow.com/questio ... 11-0-2012-benchmark
VS2012对GCC，差几倍的情况都出现了不少。

作者: largewc 时间: 2013-10-21 11:58
本帖最后由 largewc 于 2013-10-21 11:59 编辑

acqwer 发表于 2013-10-21 11:52
不是支持就行啊
http://stackoverflow.com/questio ... al-c-11-0-2012-benc ...

我怎么看大部分都是ms表现的更好啊，少部分多指令的乘除表现实在太差，不过测试的是amd的u，可能有一些差异，ms的优化应该还是基于intel的为主。

非simd，ms表现更好，可能也是这样吧，ms对simd优化不够，但是常规x86优化，vc比gcc好太多了。

作者: largewc 时间: 2013-10-21 12:01

acqwer 发表于 2013-10-21 11:33
we use Xcode 5 on iOS and OS X, Clang 3.3 on Linux, Visual Studio 2012 on Windows, and GCC 4.8 o ...

大致看了一下，geekbench确定不支持avx，这样的话，haswell能跑到a7一样的分数，非常可怕了。

作者: acqwer 时间: 2013-10-21 12:04

largewc 发表于 2013-10-21 11:58
我怎么看大部分都是ms表现的更好啊，少部分多指令的乘除表现实在太差，不过测试的是amd的u，可能有一些 ...

后面有总和的时间，最好的情况是相当，最差差了几倍。纯X86指令的确是MS做得好，但是新指令的支持被开源社区甩了好大一截。

至于Intel和AMD差异，至少在geekbench的表现中基本符合两家CPU的性能，VS并没有表现出更优化Intel出来。

作者: largewc 时间: 2013-10-21 12:10

acqwer 发表于 2013-10-21 12:04
后面有总和的时间，最好的情况是相当，最差差了几倍。纯X86指令的确是MS做得好，但是新指令的支持被开源社 ...

我的观点是，simd除了特定情况，特别是那种极端测试，影响性能的大部分simd指令都是自己手工写的，不可能是编译器自动编译的，这个不可靠。

ms的观点是sse编译器优化带来的性能提升不明显，msdn之前有一个文档也是这么说的。

我们自己的工程也是如此，真正耗能的部分都是手工写的，gcc默认编译的也差距甚远。

作者: largewc 时间: 2013-10-21 12:19
本帖最后由 largewc 于 2013-10-21 12:22 编辑

acqwer 发表于 2013-10-21 12:04
后面有总和的时间，最好的情况是相当，最差差了几倍。纯X86指令的确是MS做得好，但是新指令的支持被开源社 ...

而且我觉得可能存在别的因素导致的，不一定是vc优化的不到位，没有分析代码不能说明问题。

编译器我还是这个观点，vc比gcc效率高多了。

作者: acqwer 时间: 2013-10-21 14:33
本帖最后由 acqwer 于 2013-10-21 14:34 编辑

largewc 发表于 2013-10-21 12:10
我的观点是，simd除了特定情况，特别是那种极端测试，影响性能的大部分simd指令都是自己手工写的，不可能 ...

如果跑测试软件，编译器差别非常大，跑Spec的时候，ICC在Intel平台上面比GCC平均强了50%，跑普通的非大量运算应用，本来SIMD用的就少，提升当然有限。

微软现在在软件优化上面比开源平台差了好多，编译器这种不好比，就看同样靠优化的浏览器，跑JS除了作弊的日蜘蛛平均能输30%。别说MS觉得JS不重要，微软自己的官方文档还拿日蜘蛛来对比。

作者: largewc 时间: 2013-10-21 14:38
本帖最后由 largewc 于 2013-10-21 14:38 编辑

acqwer 发表于 2013-10-21 14:33
如果跑测试软件，编译器差别非常大，跑Spec的时候，ICC在Intel平台上面比GCC平均强了50%，跑普通的非大量 ...

算不上作弊吧，js微软确实厉害，毕竟微软在做编译器的，谷歌差的更远。

主流浏览器性能不行主要还是微软在html5上支持一直不给力，这是实情，微软在内存使用上也比chrome要谨慎一些。微软只是优化了局部的html5性能，但是整体还是比较差的。

按照以前我的经验来看，msvc比gcc大概快30%左右，icc比msvc还能快30%附近，总体icc比gcc能快50%-70%。

simd上可能ms确实不太在意，也许是实情，过一段时间找找资料看看吧。

ie11我认为已经可以完全取代chrome了，我用了一段时间，速度跟chrome基本看不出差异，而内存占用，ie比chrome好太多。

作者: acqwer 时间: 2013-10-21 14:42
本帖最后由 acqwer 于 2013-10-21 14:43 编辑

largewc 发表于 2013-10-21 14:38
算不上作弊吧，js微软确实厉害，毕竟微软在做编译器的，谷歌差的更远。

主流浏览器性能不行主要还是 ...

http://we.poppur.com/thread-2162828-1-1.html

看这贴，IE11只有sunspider能赢，对于测试软件来说，无用代码删除就是作弊行为，测试首先要保证对比平台的运算量一样，IE就做个检测发现没有全局变量就跳过循环在测试中怎么看都是作弊行为。

IE真正提升很大的是GPU加速，毕竟核心API在微软手上，硬件厂商的支持也更好，JS还是在垫底。

作者: largewc 时间: 2013-10-21 14:45

acqwer 发表于 2013-10-21 14:42
http://we.poppur.com/thread-2162828-1-1.html

看这贴，IE11只有sunspider能赢，对于测试软件来说，无 ...

js跟c#或者java虚拟机应该类似的jit方案，c#就是比java快，难道是作弊？ms在这一点确实比其他家强，这是ms过去的优势而已。

找个html5兼容性测试，ie更差，因为ie确实对html支持不好，浏览器测试好多专门是跑html5的。

作者: acqwer 时间: 2013-10-21 14:53
本帖最后由 acqwer 于 2013-10-21 14:54 编辑

largewc 发表于 2013-10-21 14:45
js跟c#或者java虚拟机应该类似的jit方案，c#就是比java快，难道是作弊？ms在这一点确实比其他家强，这是m ...

kraken和octane都是纯JS测试，当时被质疑的时候，有人测试过调整了sunspider的代码，IE的成绩就掉了一大截。

Rob Sayre在对Firefox 4和其它浏览器进行基准测试时，注意到IE9在SunSpider的math-cordic测试速度是其它浏览器的十倍。在测试中，Chrome和Opera的得分在10ms左右，但IE9只需1ms。Sayre改动了测试代码中的两个影响不大的变量，结果IE9完成测试所需时间是原来的20倍（20ms），而Opera和Chrome在新测试中速度保持不变。

微软给出的解释就是IE增加了无用代码删除的功能，这应该是变相承认作弊了吧。

作者: largewc 时间: 2013-10-21 15:02

acqwer 发表于 2013-10-21 14:53
kraken和octane都是纯JS测试，当时被质疑的时候，有人测试过调整了sunspider的代码，IE的成绩就掉了一大 ...

这个应该只是编译器里面的一个优化而已，取消无用变量。

可能会带来ie的加载速度变慢，sunspider是加载结束后，一次性测试，我怀疑其他测试可能是包含下载和加载速度了，ie js编译优化深度更深可能会带来加载更慢的问题。

作者: largewc 时间: 2013-10-21 15:24

acqwer 发表于 2013-10-21 14:53
kraken和octane都是纯JS测试，当时被质疑的时候，有人测试过调整了sunspider的代码，IE的成绩就掉了一大 ...

sunspider确实不靠谱，最简单一个，你开启测试以后，马上把窗口最小化，成绩可以提升10%。

sunspider的测试不能更好测试浏览器性能，这个确实，平均测试来看，ie应该还是不如chrome。

不过应该还是ie本身的问题。

作者: slice 时间: 2013-10-21 15:36

largewc 发表于 2013-10-21 15:24
sunspider确实不靠谱，最简单一个，你开启测试以后，马上把窗口最小化，成绩可以提升10%。

sunspider的 ...

无用代码删除的功能，只要不影响最终结果。
而且对其他地方使用类似代码是同样有效，而非遇到xxx.exe就xxx之类，那么这只能说是优化。
sunspider踩雷了，只能说其测试样例不全面，不能反应更普遍情况。

作者: largewc 时间: 2013-10-21 15:37

slice 发表于 2013-10-21 15:36
无用代码删除的功能，只要不影响最终结果。
而且对其他地方使用类似代码是同样有效，而非遇到xxx.exe就x ...

我估计苹果的safiri跟ie是同样的优化，看起来苹果iphone5s的google octane的成绩也非常差劲，应该陷入了跟ie一样的麻烦。

现在ie已经好用了，这些分数我觉得无关紧要，只算体验，ie11已经很好用了。

作者: largewc 时间: 2013-10-21 15:38

slice 发表于 2013-10-21 15:36
无用代码删除的功能，只要不影响最终结果。
而且对其他地方使用类似代码是同样有效，而非遇到xxx.exe就x ...

只有浏览器跑分，我觉得只有同平台才有意义，跨平台比浏览器本身就不太靠谱。

作者: 开普勒 时间: 2013-10-21 16:46

largewc 发表于 2013-10-21 10:27
arm64是双发射的neon，这个可以理解了，这样拆分是为了双发射neon的作用。

现在可以理解a7的性能所谓的 ...

这里要小心别被ARM骗了。A15上大部分NEON也是双发射的，但是要注意发射单元是发射微指令。实际上在A15上大部分四向量NEON指令是要被解码成两条二向量NEON微指令的。所以A15上所谓NEON双发射不过只是每周期一条四向量NEON指令罢了。

苹果A7上NEON微指令是什么样子这个还不清楚，需要做一些micro benchmark才能确定。

作者: largewc 时间: 2013-10-21 16:50

开普勒发表于 2013-10-21 16:46
这里要小心别被ARM骗了。A15上大部分NEON也是双发射的，但是要注意发射单元是发射微指令。实际上在A15上大 ...

嗯，但是从xcode编译结果来看，不管是如何，反正a7比a6应该是双发射neon的提升。

也许a6本身还是单发射的neon吧，具体只有苹果知道了。

作者: potomac 时间: 2013-10-21 18:48
提示: 作者被禁止或删除内容自动屏蔽

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