反编译xcode5的结果来看a7性能提升的主要因素

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，差几倍的情况都出现了不少。

帐号		自动登录	找回密码
密码			注册