POPPUR爱换

标题: Futuremark已经解释了为啥A7物理得分低的原因。个人解读一下,欢迎讨论 [打印本页]

作者: ifu    时间: 2013-10-18 11:51
标题: Futuremark已经解释了为啥A7物理得分低的原因。个人解读一下,欢迎讨论
欢迎讨论,谢绝无脑喷
Futuremark已经解释了为啥A7物理得分低的原因,个人认为还是说得通的。
3Dmark这个iphone5s这个物理得分低的原因还在于随机访问造成的cache miss。学CS的大都应该明白这cache miss的恐怖性。
A7的运算资源已经足够丰富,futuremark也提到了单执行物理运算时能获得>2x的性能加成。
3DMark测试中物理运算部分都是随机访问数据。这真正的随机访问对谁来说都是无解,不可预测的。
一般来说cache命中和不命中的执行速度差了一到两个数量级。如果每次访存都是一次miss那A7再强的执行资源也是白搭,对于A7来说3Dmark的物理测试就变成了随机访存测试
可能提高A7在这种随机访存测试中成绩的方法:
1)提高主频。主频高了L/S执行频率也就多了,但L/S始终是瓶颈
2)增加cachesize 现在A7是1MB L2 。增加到2MB或者更多 L2也许就能涵盖这测试的数据规模,至少有助于减少cache miss.
3)再加一组L/S...
4)加核,也就相当于多一组L/S。

那么为什么对baytrail S800 A15,这些影响不大呢?可能原因如下:
1)主频相对它们的前一代有提升,间接增加了L/S的频率
2)核多,间接增加了L/S单元。3Dmark这种物理测试本身并行性很好,不会有什么访存冲突
3)Cache够大。z3770 tegra4 S800这些都是2MB L2 cache。或者2MB刚好涵盖了3Dmark的数据规模,不过这个天晓得。但cache够大在随机访存测试中总是占便宜的



http://community.futuremark.com/forum/showthread.php?177840-Why-iphone5-and-iphone5S-share-same-physics-score/page3
We've looked at this at great length, and the result is quite interesting. We are working with our relevant partners on this to verify, but at current it seems that:

The compiler does do SIMD and Neon. These do not offer any effect. We even tried doing Neon optimizing by hand to see if the compiler is not doing what it should, but no real effect

The Physics test is uses Bullet, and 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. However, once it's inside the physics engine, you see nothing.

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. This is higher if it can run up the memory, a bit lower if it runs down. The way bullet places the bodies in the memory is a lot more random and they are accesses in a jump-back-and-forth manner. When memory is accessed in this way, all speed gains are lost.

iPhone 5 shows none of this behaviour. It is realistic to assume that in the new 5s we see the new prefetch in action, but it cannot gain traction with a random memory access pattern.

It's good to understand that this is not a flaw in Bullet. Arranging complex memory structures in memory to be in a sequential fashion is non-trivial to say the least. Our hacked solution only worked for us as we knew exactly the data that we would be using. Worrying about where your memory segments lie is not something the programmer should have to worry about anyway.

In terms of our Physics test at large, it does not appear that we have an inherent flaw - our use-case is simply such that no gain is seen. Any game/app using Bullet would see the same, and there are naturally other apps that will see the same (in GeekBench, you can see a few tests where the same thing is happening).


作者: ifu    时间: 2013-10-18 12:01
这图说明很有可能在A6的时候就已经撞上了访存墙。A7因为更强的数据预取导致性能反而下降,不命中的数据预取只能是负分

作者: acqwer    时间: 2013-10-18 12:12
说以说Z2580 512K*2,瓶颈更明显。
作者: the_god_of_pig    时间: 2013-10-18 12:21
没能么复杂,apple水平不够把U做畸形了而已,执行单元堆地厉害,结果内存预取一坨

后果就是简单的数学跑分美地很,结果一到大型复杂负载就吃翔了
作者: the_god_of_pig    时间: 2013-10-18 12:23
按这原理,估计跑SPEC也得吃翔
作者: ifu    时间: 2013-10-18 12:24
acqwer 发表于 2013-10-18 12:12
说以说Z2580 512K*2,瓶颈更明显。

Z2580 主频高 2G, A7只有1.3G
如果每次都cache miss 单纯测随机访存 那2G的肯定占便宜。
瓶颈这玩意要具体量化分析的,各个处理器的情况还不太一样。有的处理器可能运算资源是瓶颈,有的可能是访存。
A7这个Futuremark自己也测过移除随机访存限制后速度快了2倍以上。

嗯,哪有Z2580的测试结果?我看看

作者: acqwer    时间: 2013-10-18 12:26
ifu 发表于 2013-10-18 12:24
Z2580 主频高 2G, A7只有1.3G
如果每次都cache miss 单纯测随机访存 那2G的肯定占便宜。
瓶颈这玩意要具 ...

3dmark官网,10000分出头吧
作者: ifu    时间: 2013-10-18 12:28
the_god_of_pig 发表于 2013-10-18 12:21
没能么复杂,apple水平不够把U做畸形了而已,执行单元堆地厉害,结果内存预取一坨

后果就是简单的数学跑 ...

水果的数据预取已经很厉害,你可以看一下geekbench的访存部分成绩。
要真随机谁来了也得吃瘪,能预测就不是随机了。
作者: ifu    时间: 2013-10-18 12:30
the_god_of_pig 发表于 2013-10-18 12:23
按这原理,估计跑SPEC也得吃翔[shifty>

SPEC里面的数据访问还是很有规律的,再加上用数据集training一下想miss都很难。
作者: eternal0    时间: 2013-10-18 12:33
说白了就是以前赛扬和奔腾的差距,缓存在某些应用上有巨大的影响力,服务器U动辄30M的L3也不是摆设。
作者: acqwer    时间: 2013-10-18 12:36
eternal0 发表于 2013-10-18 12:33
说白了就是以前赛扬和奔腾的差距,缓存在某些应用上有巨大的影响力,服务器U动辄30M的L3也不是摆设。

问题是3dmark物理测试并不是一个缓存敏感的测试,所以他的分析明显是错误的。
作者: the_god_of_pig    时间: 2013-10-18 12:38
ifu 发表于 2013-10-18 12:28
水果的数据预取已经很厉害,你可以看一下geekbench的访存部分成绩。
要真随机谁来了也得吃瘪,能预测就不 ...

不要提geekbench了行吗?开个微架构讨论贴结果拿geekbench说事儿?

作者: the_god_of_pig    时间: 2013-10-18 12:39
ifu 发表于 2013-10-18 12:30
SPEC里面的数据访问还是很有规律的,再加上用数据集training一下想miss都很难。

扯吧,SPEC不miss?当年k8就靠个IMC就日了P4你以为靠的是什么?

作者: ifu    时间: 2013-10-18 12:43
acqwer 发表于 2013-10-18 12:36
问题是3dmark物理测试并不是一个缓存敏感的测试,所以他的分析明显是错误的。

目前这个3DMark是一个基于随机访存的数值计算benchmark,Futuremark的工作人员也指出了这一点。
我也并不是只把和缓存挂钩。如果3Dmark 的data fooprint足够大足够随机,那就不会和cache size挂钩,那就和L/S挂钩了。
但3Dmark 的data fooprint只有它自己的工作人员知道,并且也不会透露的。
作者: ifu    时间: 2013-10-18 12:46
the_god_of_pig 发表于 2013-10-18 12:39
扯吧,SPEC不miss?当年k8就靠个IMC就日了P4你以为靠的是什么?

没有完全不miss的除非完全塞入cache,但是通过training会尽可能减少miss.你以为Profiling是干啥?
作者: ifu    时间: 2013-10-18 12:47
eternal0 发表于 2013-10-18 12:33
说白了就是以前赛扬和奔腾的差距,缓存在某些应用上有巨大的影响力,服务器U动辄30M的L3也不是摆设。

不只是缓存,缓存只是可能性中的一种
作者: ifu    时间: 2013-10-18 12:51
the_god_of_pig 发表于 2013-10-18 12:38
不要提geekbench了行吗?开个微架构讨论贴结果拿geekbench说事儿?

geekbench当然有意义。如果连基本规律访存预期都做得不够好,那么在geekbench访存部分就得挂。
跑好geekbench的处理器不一定牛,但跑不好geekbench的处理器一定弱。
作者: acqwer    时间: 2013-10-18 12:58
ifu 发表于 2013-10-18 12:51
geekbench当然有意义。如果连基本规律访存预期都做得不够好,那么在geekbench访存部分就得挂。
跑好geek ...

这句话纯粹是废话,跑不跑得好本来就是相对的,处理器A比处理器B跑的分高,就是处理器A跑的好,没比较你怎么看得出谁跑的好?
作者: ifu    时间: 2013-10-18 12:59
acqwer 发表于 2013-10-18 12:58
这句话纯粹是废话,跑不跑得好本来就是相对的,处理器A比处理器B跑的分高,就是处理器A跑的好,没比较你怎 ...

所以geekbench是有意义的
作者: acqwer    时间: 2013-10-18 13:06
ifu 发表于 2013-10-18 12:59
所以geekbench是有意义的

geekbench可是能测出1M L2的PE和X2内存性能相当的结果,这个“内存”测试的意义何在?
作者: the_god_of_pig    时间: 2013-10-18 13:14
ifu 发表于 2013-10-18 12:46
没有完全不miss的除非完全塞入cache,但是通过training会尽可能减少miss.你以为Profiling是干啥?

SPEC是极度依赖内存的,无论带宽还是延迟都对结果有巨大影响。缓存系统是考察重点中的重点,你以为Cache miss那么容易消除?如果能轻易把跑SPEC的Cache miss都掩藏了SPEC早就沦为Geekbench了


作者: the_god_of_pig    时间: 2013-10-18 13:17
ifu 发表于 2013-10-18 12:51
geekbench当然有意义。如果连基本规律访存预期都做得不够好,那么在geekbench访存部分就得挂。
跑好geek ...

你见过哪个实际负载/实际测试把访存和int/fp分开跑的?
作者: 532    时间: 2013-10-18 15:37
iPhone 5 shows none of this behaviour. It is realistic to assume that in the new 5s we see the new prefetch in action, but it cannot gain traction with a random memory access pattern.

所以爱疯5s烂还是三滴马克烂我们选哪个
作者: largewc    时间: 2013-10-18 16:18
本帖最后由 largewc 于 2013-10-18 16:18 编辑
the_god_of_pig 发表于 2013-10-18 13:17
你见过哪个实际负载/实际测试把访存和int/fp分开跑的?


我刚才反编译了一下xcode的代码,大概理解了,a7不过支持128bit的neon而已。

新版本的xcode可以优化编译成neon了,老版本xcode不支持而已。

如果这样,geekbench用sse4针对bt优化一下,分数可以高得多。


等一下我贴代码分析一下好了。
作者: ifu    时间: 2013-10-18 19:15
largewc 发表于 2013-10-18 16:18
我刚才反编译了一下xcode的代码,大概理解了,a7不过支持128bit的neon而已。

新版本的xcode可以优化 ...

呵呵,如果仅支持128bit的neon就可以性能牛逼的话。高通的S800就不会被扣上高频低能的帽子了。
你还是对随机访存没有真正认识:)
作者: largewc    时间: 2013-10-18 19:17
ifu 发表于 2013-10-18 19:15
呵呵,如果仅支持128bit的neon就可以性能牛逼的话。高通的S800就不会被扣上高频低能的帽子了。
你还是对 ...

krait不过浮点单发射而已,整数能力krait跟a15差距并不大。

只是编译对比了一下而已,a7所谓的xcode的优化,不过是默认neon化了而已。
作者: ifu    时间: 2013-10-18 19:33
largewc 发表于 2013-10-18 19:17
krait不过浮点单发射而已,整数能力krait跟a15差距并不大。

只是编译对比了一下而已,a7所谓的xcode的 ...

整数能力差别当然也很大,你可以找相关测试对比一下。
a7的SIMD优化anandtech在geekbench部分的分析中已经提过,例如DGEMM这个例子
http://www.anandtech.com/show/7335/the-iphone-5s-review/4
The DGEMM operations aren't vectorized under ARMv7, but they are under ARMv8 thanks to DP SIMD support so you get huge speedups there from the recompile.
但A7显然不只这么简单,例如SFFT
The SFFT workload benefits handsomely from the increased register space, significantly reducing the number of loads and stores
如果你真的对A7的64位有兴趣,推荐你读读这篇文章:
http://www.mikeash.com/pyblog/fr ... -arm64-and-you.html

作者: ifu    时间: 2013-10-18 19:48
acqwer 发表于 2013-10-18 12:26
3dmark官网,10000分出头吧

找了一下3dmark官网http://www.3dmark.com/search?locale=zh_CN,没找到查3DMark Unlimited ice storm物理成绩的地方。
你在哪里找到的成绩?
很感兴趣其它CPU在3DMark Unlimited ice storm下的物理成绩
作者: largewc    时间: 2013-10-18 20:42
ifu 发表于 2013-10-18 19:33
整数能力差别当然也很大,你可以找相关测试对比一下。
a7的SIMD优化anandtech在geekbench部分的分析中已 ...

他们认真分析了xcode编译的结果了吗,我上面说了,armv7开启的话,循环unroll这个优化没有了,很奇怪,而arm64开启以后,则有这个效果。

我认为苹果刻意区分了32和64的区别,突出新a7的优势。
作者: ifu    时间: 2013-10-18 20:58
largewc 发表于 2013-10-18 20:42
他们认真分析了xcode编译的结果了吗,我上面说了,armv7开启的话,循环unroll这个优化没有了,很奇怪,而 ...

应该有分析编译结果,例如SFFT(there's something like a 30% reduction in instructions for the A64 codepath compared to the A32 codepath here).
水果倒未必会做这下三滥的手法,A7的大部分提升还是来源处理器本身的改进。要知道A7比A6晶体管数目涨得惊人,A7单核规模都快两个CortexA15了
anantech测试过32位模式(armv7)下A7的性能,A7 32bit vs A6 32bit 本身就有50%以上的性能提升。
作者: largewc    时间: 2013-10-18 21:16
ifu 发表于 2013-10-18 20:58
应该有分析编译结果,例如SFFT(there's something like a 30% reduction in instructions for the A64 co ...

我觉得性能最大的改良可能是a7内存性能的提升,1.33g比1.0g大幅度提升了内存访问速度,看geekbench2的分数来看

a6是1670,而a7是2227

(2227 - 1670) / 1670 = 0.3335

大体应该接近于DDR2跟DDR3的差距,除此之外应该还有小幅度优化。

这东西可以大幅度加速大部分程序,但是对于一些堆内存依赖不高,对cpu依赖更高的一些计算来说,提升就不明显了。
作者: ifu    时间: 2013-10-18 22:09
largewc 发表于 2013-10-18 21:16
我觉得性能最大的改良可能是a7内存性能的提升,1.33g比1.0g大幅度提升了内存访问速度,看geekbench2的分数 ...

DDR3对于DDR2来说优势仅限于带宽,延迟反而有副作用会增大。
geekbench里类似bzip2这种测试不可能瓶颈在于带宽。A7在32位模式下一样获得30%的性能提升。
BZip2 Compress
Single-core         3.30 MB/sec        A6
Single-core         4.36 MB/sec        A7 32bit
Single-core         4.51 MB/sec     A7 64bit
Single-core         4.29 MB/sec     haswell@1.3G 64bit
haswell的带宽够惊人了把,还是和A7一个水平。A7的访存性能有改进,但改进不仅限于内存。
作者: acqwer    时间: 2013-10-19 11:11
ifu 发表于 2013-10-18 19:48
找了一下3dmark官网http://www.3dmark.com/search?locale=zh_CN,没找到查3DMark Unlimited ice storm物理 ...

http://community.futuremark.com/hardware/mobile
作者: acqwer    时间: 2013-10-19 11:13
ifu 发表于 2013-10-18 20:58
应该有分析编译结果,例如SFFT(there's something like a 30% reduction in instructions for the A64 co ...

这个明显只是根据结果来推断的,你不会不知道geekbench直接分成32和64两个版本,可以分开跑吧。
作者: the_god_of_pig    时间: 2013-10-19 13:46
ifu 发表于 2013-10-18 22:09
DDR3对于DDR2来说优势仅限于带宽,延迟反而有副作用会增大。
geekbench里类似bzip2这种测试不可能瓶颈在 ...

拿geekbench出来有什么用,说服力=0

作者: Tempestglen    时间: 2013-10-20 08:55
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 10:55
Tempestglen 发表于 2013-10-20 08:55
双核A7一共1M L2?

这是最好的结论,证明计算能力而言A7确实比A6 double了,至于L2偏小,那是为了照顾4寸 ...

YY个屁啊?

结论明明是水平低下把内存访问做成了一坨屎,居然YY成L2不足,还有没有救?等了半天15000分结果等来了6589性能,真是“令人高兴的消息”啊哈哈


bay trail放到了8寸设备上,你的A7X能放到mini上吗?放不上就老老实实承认A7X功耗爆炸被byt秒飞

作者: 532    时间: 2013-10-20 11:10
比同频转战到比同样的L2了么,遮羞布除了洞洞装蕾丝装还有什么花样
作者: Tempestglen    时间: 2013-10-20 14:03
提示: 作者被禁止或删除 内容自动屏蔽
作者: YsMilan    时间: 2013-10-20 14:30
Tempestglen 发表于 2013-10-20 14:03
你YY个屁啊?

你没看见A7的计算性能在A6基础上double了?不错,A7在跑3dmark时的瓶颈在内存随机访问, ...

求神喻示:L2缓存32MB的Xeon是哪个星球上的产品?
作者: YsMilan    时间: 2013-10-20 14:56
Tempestglen 发表于 2013-10-20 14:03
你YY个屁啊?

你没看见A7的计算性能在A6基础上double了?不错,A7在跑3dmark时的瓶颈在内存随机访问, ...

看半天终于大概明白点了,原来神的意思是A7比A6快,因此同样大小的2MB L2对A6来说够用,对A7来说不够?
那只好继续求神喻:
对Q9550来说够用的12MB L2换代到了I7 920缓存为何反而减小成1MB+8MB了?
作者: Tempestglen    时间: 2013-10-20 15:14
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 15:17
Tempestglen 发表于 2013-10-20 14:03
你YY个屁啊?

你没看见A7的计算性能在A6基础上double了?不错,A7在跑3dmark时的瓶颈在内存随机访问, ...

哈哈哈,气急败坏憋了半天就YY出这么一串屁话出来,哈哈

L2太可怜了,替水果的三流团队背了黑锅啊

作者: the_god_of_pig    时间: 2013-10-20 15:19
Tempestglen 发表于 2013-10-20 15:14
A7/A6都是1M L2吧。

3dmark的locality工作做得不好,程序写得不好。locality就是程序员的份内工作。这 ...

咦,3dmark编的不好?3dmark跑在bay trail上怎么没吃鳖啊,是不是intel给钱黑水果啊哈哈哈

作者: YsMilan    时间: 2013-10-20 15:22
Tempestglen 发表于 2013-10-20 15:14
A7/A6都是1M L2吧。

3dmark的locality工作做得不好,程序写得不好。locality就是程序员的份内工作。这 ...

缓存访问与程序无关,这个是常识
作者: Tempestglen    时间: 2013-10-20 15:25
提示: 作者被禁止或删除 内容自动屏蔽
作者: YsMilan    时间: 2013-10-20 15:27
Tempestglen 发表于 2013-10-20 15:25
我们都知道二级缓存的重要性。CPU在缓存中找到有用的数据被称为命中,当缓存中没有CPU所需的数据时(这 ...

这段话说的意思其实是A7的内存访问性能烂到家了...
作者: Tempestglen    时间: 2013-10-20 15:30
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 15:32
Tempestglen 发表于 2013-10-20 15:30
现在早就不是程序员可以无视硬件架构编程同时还想要获取高性能的时代了,程序员必须注重自己代码的locali ...

是吗?怎么就你的水果吃鳖了啊?别的atom 6589什么的怎么都跑地好好地啊?

作者: Tempestglen    时间: 2013-10-20 15:32
提示: 作者被禁止或删除 内容自动屏蔽
作者: YsMilan    时间: 2013-10-20 15:33
Tempestglen 发表于 2013-10-20 15:30
现在早就不是程序员可以无视硬件架构编程同时还想要获取高性能的时代了,程序员必须注重自己代码的locali ...

好啊,请神谕下为何同样的Futuremark写的代码在ARM上跑locality就不足,在Atom下跑就没事呢?
作者: ifu    时间: 2013-10-20 15:57
acqwer 发表于 2013-10-19 11:11
http://community.futuremark.com/hardware/mobile

多谢。。。
作者: ifu    时间: 2013-10-20 16:02
the_god_of_pig 发表于 2013-10-20 15:19
咦,3dmark编的不好?3dmark跑在bay trail上怎么没吃鳖啊,是不是intel给钱黑水果啊哈哈哈[biggrin>[bigg ...

我帖子写得很清楚了,这种随机访存,如果L/S单元数量都差不多的情况下。频率高的和核多的占优。
其实这benchmark是有些问题的,真正的游戏不可能不对这做优化。
看一则新闻
AMD主要进行了Basemark、3DMark和PCMark的测试,结果在测试中,A10-6800K低则领先i5-4670K达4%(PCMark 8),最高则能够领先46%(3DMark For Windows FireStrike Extreme)。
当然FireStrike未必同mobileunlimited算法一致
作者: Tempestglen    时间: 2013-10-20 16:08
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 16:17
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 16:25
ifu 发表于 2013-10-20 16:02
我帖子写得很清楚了,这种随机访存,如果L/S单元数量都差不多的情况下。频率高的和核多的占优。
其实这b ...

清楚?CPU的性能表现什么时候成了靠数单元和缓存就能推测出来的了?
--------------------
3dmark总分和CPU测试分数都分不清?


作者: the_god_of_pig    时间: 2013-10-20 16:29
Tempestglen 发表于 2013-10-20 16:17
首先,你别搅浑水,cyclone不代表所有的arm。

其次,我已经请求futuremark做其他试验,他们之前不是把 ...

笑死人了

还计算性能?在你脑子里CPU是用来堆执行资源的?

作者: Tempestglen    时间: 2013-10-20 16:39
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 16:41
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 16:46
Tempestglen 发表于 2013-10-20 16:41
坐等furturemark的试验,用事实打脸!目前futuremark已经证明了A7的新式prefetch被他们完全浪费。只要他们 ...

YY前先去找找你的15000分的脸

作者: Tempestglen    时间: 2013-10-20 16:49
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 16:51
转进了半天就是想找辙开除3dmark,还装地挺有理,笑死人了


Now it completely depends on the game as to what kind of load it puts on the CPU, but I would say that "easy" serialized memory access is something most commonly seen in very narrow tasks (file compression, image manipulation) and it doesn't tend to happen in more complex systems like game engines.


还YY分数无效,看看人是怎么回的哈哈哈

http://community.futuremark.com/forum/showthread.php?177840-Why-iphone5-and-iphone5S-share-same-physics-score/page3

作者: the_god_of_pig    时间: 2013-10-20 16:55
Tempestglen 发表于 2013-10-20 16:49
人家把函数拖出来,使用连续访存的方式跑了一遍,结果成绩X2,X3,果然是我说的15000分的水平。futuremar ...

继续YY,随你便
反正A7烂货的水平已经臭大街了,吹了半天的团队做了个瘸脚架构,5410面积战平6589,外加比前代性能倒车,史无前例啊

作者: Tempestglen    时间: 2013-10-20 16:57
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 17:06
提示: 作者被禁止或删除 内容自动屏蔽
作者: limpentium    时间: 2013-10-20 17:17
5s是不是很烫
作者: limpentium    时间: 2013-10-20 17:19
本帖最后由 limpentium 于 2013-10-20 17:20 编辑

silvermont功耗
有没有5s大
作者: the_god_of_pig    时间: 2013-10-20 17:21
Tempestglen 发表于 2013-10-20 16:57
程序写得烂的是bullet,不是3dmark公司的。开源的程序,大家随便用,不等于就是高效的程序。

你不要忘 ...

geekbench写的好,你去玩Geekbench吧,千万不要玩游戏,写得不好呀
作者: the_god_of_pig    时间: 2013-10-20 17:22
Tempestglen 发表于 2013-10-20 17:06
我现在用着5S,无比流畅,比老婆的5流畅多了。远不是6589和silvermont之流可比的。
i粉现在只剩下用代码 ...

系统是太监,能不流畅吗?
作者: limpentium    时间: 2013-10-20 17:24
t神确定你这帖子是用你的5s”流畅“地发出来的?
作者: Tempestglen    时间: 2013-10-20 17:25
提示: 作者被禁止或删除 内容自动屏蔽
作者: limpentium    时间: 2013-10-20 17:27
难道只有geekbench能支持t神的”大水果不败神论“了吗?
作者: Tempestglen    时间: 2013-10-20 17:28
提示: 作者被禁止或删除 内容自动屏蔽
作者: westlee    时间: 2013-10-20 17:53
提示: 作者被禁止或删除 内容自动屏蔽
作者: YsMilan    时间: 2013-10-20 18:14
本帖最后由 YsMilan 于 2013-10-20 18:15 编辑
Tempestglen 发表于 2013-10-20 16:17
首先,你别搅浑水,cyclone不代表所有的arm。

其次,我已经请求futuremark做其他试验,他们之前不是把 ...


就是就是,对付随机存取这种烂方法A7居然体现不出对A6的优势来,这不是A7内存访问烂是什么?
水果这几年看来都是吃干饭的
要不T神可以命令下A7的L2今后100%命中吧

作者: westlee    时间: 2013-10-20 18:15
提示: 作者被禁止或删除 内容自动屏蔽
作者: westlee    时间: 2013-10-20 18:25
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 18:40
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 18:41
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 18:42
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 18:44
提示: 作者被禁止或删除 内容自动屏蔽
作者: raini    时间: 2013-10-20 18:49
吓尿了!T神一说locality吓死了,怎么这个都成了程序员的职责了!莫非现在都返回到汇编写程序的年代了?不过T神永远是正确的,T神说内存应该是locality的就locality吧,毕竟T神连线程都不懂,何况还能懂多任务系统内存的复杂性吗?
不如让T神给大家演示一下,怎么用C,或者T神偏爱的Obj C搞个locality的程序来?
作者: Tempestglen    时间: 2013-10-20 18:50
提示: 作者被禁止或删除 内容自动屏蔽
作者: YsMilan    时间: 2013-10-20 19:09
本帖最后由 YsMilan 于 2013-10-20 19:13 编辑
Tempestglen 发表于 2013-10-20 18:40
A7当然可以1v2对付那些S800/bt/5420什么的,但是遇到bullet这种随机内存访问的程序, 总不能把1M L2当2M ...


按你逻辑,烂代码导致L2命中率低是吧
那能低到什么程度呢?极端点就算命中率为0吧,那相当于L2废掉
换句话说,没L2的A7比没L2的A6快4%...代码都一样啊
结论:苹果这几年都是吃干饭的,除了L2缓存有点改进,也就是你的顺序读取,运算器加内存访问也就4%的进步...大水果壮哉!
作者: YsMilan    时间: 2013-10-20 19:11
本帖最后由 YsMilan 于 2013-10-20 19:12 编辑
Tempestglen 发表于 2013-10-20 18:44
一看你就是智商缺乏,对付随机访存,火星人也没有什么好办法,就是堆L2容量增加S/L增加频率而已,这方面一 ...


随机访存就是A7跟A6半斤八两的借口?
就问你一句,同样关掉L2,Core2快还是PD快?
就你也来谈智商...
作者: Tempestglen    时间: 2013-10-20 19:19
提示: 作者被禁止或删除 内容自动屏蔽
作者: Tempestglen    时间: 2013-10-20 19:20
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 19:32
某专业人士要是还在这混估计某神已经被喷死了
作者: Tempestglen    时间: 2013-10-20 19:40
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 19:45
Tempestglen 发表于 2013-10-20 18:50
说了半天, 你是在强调prefetch的重要性,问题是A7的prefetch就是比A6强大得多得多。

prefetch对付loc ...
如果给A7配备2M L2,跑physics也是A15的2倍

快去给apple写信,告诉他们你发现了性能翻番的方法

作者: the_god_of_pig    时间: 2013-10-20 19:49
Tempestglen 发表于 2013-10-20 19:40
不好意思,我正是咨询了某专业人士才敢发表上述观点:prefetch对随机访存无效,楼主也是这么认为的,就你 ...

数数单元外加对着程序的语言描述YY一下就算出性能,i粉没那本事啊

作者: Tempestglen    时间: 2013-10-20 20:05
提示: 作者被禁止或删除 内容自动屏蔽
作者: the_god_of_pig    时间: 2013-10-20 20:09
Tempestglen 发表于 2013-10-20 20:05
locality本来就是编译器/微架构/程序员三方通力合作才能完成的事情。

A7从微架构上讲,完全具备1v2对 ...

你就扯淡吧

作者: westlee    时间: 2013-10-20 20:42
提示: 作者被禁止或删除 内容自动屏蔽
作者: ifu    时间: 2013-10-20 20:57
westlee 发表于 2013-10-20 20:42
ice storm physics分数:

3.0-3.2g的e3300,1m l2 ,ice storm大约22000。

1)这个要看数据规模 footprint,如果cache 都不命中,那肯定是频率高的占便宜,原因我贴中已经说明
2)ICE STORM不是3DMark mobile Unlimited,算法也不见得一样
作者: ifu    时间: 2013-10-20 21:11
Tempestglen 发表于 2013-10-20 18:50
说了半天, 你是在强调prefetch的重要性,问题是A7的prefetch就是比A6强大得多得多。

prefetch对付loc ...

A7配备2M L2跑3DMark physics也未必A15的2倍。因为2MB未必能保证cache 都命中。
作者: ifu    时间: 2013-10-20 21:24
westlee 发表于 2013-10-20 18:15
内存本来就是随机访问的,连续读写才是少见的。

DRAM(Dynamic Random Access Memory),即动态随机存 ...

这是两个概念,DRAM是指可以随机访问。
3DMark这事是每次访问都是真随机毫无规律可言,这其实对所有处理器来说都是一常灾难,除非cache足够大但这不现实
好的程序员会很注意data layout来充分利用cache避免cache miss
作者: 532    时间: 2013-10-20 21:27
那到底怎样才能跑一万五,要排t神去水果搞cpu layout的还是派ifu去三滴马克做死程?
作者: westlee    时间: 2013-10-20 22:23
提示: 作者被禁止或删除 内容自动屏蔽
作者: westlee    时间: 2013-10-20 22:25
提示: 作者被禁止或删除 内容自动屏蔽




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