POPPUR爱换

标题: 6发射。。。A7这么强的raw power，A8再改进恐怕得玩多线程了 [打印本页]

作者: ifu 时间: 2013-10-30 13:18
标题: 6发射。。。A7这么强的raw power，A8再改进恐怕得玩多线程了

苹果真是丧心病狂，对得起桌面级的称号。这么强的计算资源不用多线程提高利用率实在可惜。L/S也有必要再增强，至少得像haswell那样 2L+1S
http://www.anandtech.com/show/7460/apple-ipad-air-review/2
With Cyclone Apple is in a completely different league. As far as I can tell, peak issue width of Cyclone is 6 instructions. That’s at least 2x the width of Swift and Krait, and at best more than 3x the width depending on instruction mix. Limitations on co-issuing FP and integer math have also been lifted as you can run up to four integer adds and two FP adds in parallel. You can also perform up to two loads or stores per clock.

其它亮点也不少 CPU GPU 共享 4MB 片上SRAM 远胜 XBOX ONE四两拔千斤的GPU独享32MB ESRAM。
联想到苹果招GPU设计工程师，恐怕这是在为下一步的CPU GPU真正融合计算做准备，毕竟GPU买别人的ip是不太好融合的。

作者: tsplby 时间: 2013-10-30 14:34
不明觉厉

作者: largewc 时间: 2013-10-30 14:44
整数比a15多了一组单元，浮点没变，6并发只是提升利用率，可能有少量的提升

这两个都不足与提供翻倍的性能

翻倍的测试不通过simd的提升是不可能的。

作者: ifu 时间: 2013-10-30 17:01

largewc 发表于 2013-10-30 14:44
整数比a15多了一组单元，浮点没变，6并发只是提升利用率，可能有少量的提升

这两个都不足与提供翻倍的性 ...

执行单元是和指令发射端口相匹配的，见原文中four integer adds and two FP adds in parallel
在饱和吞吐下不需要你所谓的simd就可以翻倍

作者: largewc 时间: 2013-10-30 17:06

ifu 发表于 2013-10-30 17:01
执行单元是和指令发射端口相匹配的，见原文中four integer adds and two FP adds in parallel
在饱和吞吐 ...

four integer adds and two FP adds in parallel

a15是3整数和2浮点

如果都是密集的浮点计算，我倒是想知道，这个6怎么运算出超过2浮点的能力出来？
都是密集整数计算，怎么超过4整数的计算能力出来？

它唯一的作用，就是大规模混合浮点，整数计算的时候，有一定加成而已，但是很有限度。

作者: ifu 时间: 2013-10-30 17:30
本帖最后由 ifu 于 2013-10-30 17:31 编辑

largewc 发表于 2013-10-30 17:06
four integer adds and two FP adds in parallel

a15是3整数和2浮点

那只是anandtech给的一个例子，这只是一个下限。
举极端例子没意思，纯抬杠了。这还可以3x呢...at best more than 3x the width depending on instruction mix..
翻倍又不是所有资源都翻倍，这是有所取舍的。
别光看3整数和2浮点....你让A15同时做3个整数加法看看？

作者: 532 时间: 2013-10-30 18:55

所以堆了一个die size是a15两倍跑三滴马克物理分微增4%的玩意出来么

作者: xf-108 时间: 2013-10-30 19:44
按照你的算法，haswell至少是8发射……

作者: Tempestglen 时间: 2013-10-30 20:51
提示: 作者被禁止或删除内容自动屏蔽

作者: raini 时间: 2013-10-30 21:02

Tempestglen 发表于 2013-10-30 20:51
3dmark自己的程序写的不好。也根本无法体现手机平板的典型应用，与用户体验的相关度很烂。

人家3dmark程序写不好, 要不你去指导一下他们?

作者: the_god_of_pig 时间: 2013-10-30 21:08

Tempestglen 发表于 2013-10-30 20:51
3dmark自己的程序写的不好。也根本无法体现手机平板的典型应用，与用户体验的相关度很烂。

还是SBmark写的好，和你的用户体验严重相关

作者: ifu 时间: 2013-10-30 21:17

xf-108 发表于 2013-10-30 19:44
按照你的算法，haswell至少是8发射……

也不尽然，要是碰见的x86指令都是简单指令那还是4发射

作者: 532 时间: 2013-10-30 21:27

Tempestglen 发表于 2013-10-30 20:51
3dmark自己的程序写的不好。也根本无法体现手机平板的典型应用，与用户体验的相关度很烂。

t神来说一下什么测试才能体现平板的典型应用吧，皇军招募新人也得开个明盘啊是不

我觉得水果的cpu再屌ios没有文件管理就是一坨屎啊，文件管理算是平板的应用不

顺带按照某些被强迫用osx的群众的说法，osx的文件管理也是落后win三十年

作者: Tempestglen 时间: 2013-10-30 21:55
提示: 作者被禁止或删除内容自动屏蔽

作者: ifu 时间: 2013-10-30 22:37

Tempestglen 发表于 2013-10-30 21:55
网页，游戏，视频回放等等。

3dmark physics，四核和大L2容量的占便宜，physics于是根本不是什么cpu计 ...

3dmark physics在计算资源不足的情况下还是挺考验cpu计算能力的。可惜碰见了A7这个暴力计算怪物，就变成纯随机访存测试了。
单纯加核或者提高主频还是浪费A7的庞大计算资源，对付这种benchmark 增加L/S单元更有效率一些。

作者: 532 时间: 2013-10-30 23:25

Tempestglen 发表于 2013-10-30 21:55
网页，游戏，视频回放等等。

3dmark physics，四核和大L2容量的占便宜，physics于是根本不是什么cpu计 ...

这么说a8不上四核跟30m L2估计玩愤怒的小鸟跟百战天虫啥的“物理”游戏要卡出屎了

作者: potomac 时间: 2013-10-30 23:35
提示: 作者被禁止或删除内容自动屏蔽

作者: Tempestglen 时间: 2013-10-31 08:16
提示: 作者被禁止或删除内容自动屏蔽

作者: ifu 时间: 2013-10-31 09:30
haswell也做不到同时发射 4 INT adds+ 2 FP adds

当然L/S还是比A7强的

作者: 532 时间: 2013-10-31 09:33

Tempestglen 发表于 2013-10-31 08:16
没有一款 atom手机平板玩游戏性能超过同期ipad，你得瑟个啥？我还没来得及鄙视atom得gpu呢！

不是啦，愤怒小鸟那么多物理特效，又没装老黄的显卡能gpu跑物理X，a7的cpu算不过来的啦，L2都卡死了我估计有电话进来都得卡几秒啦

作者: largewc 时间: 2013-10-31 09:39

532 发表于 2013-10-31 09:33
不是啦，愤怒小鸟那么多物理特效，又没装老黄的显卡能gpu跑物理X，a7的cpu算不过来的啦，L2都卡死了我估计 ...

小鸟是box2d，不是bullet，不过原理差不多

作者: largewc 时间: 2013-10-31 09:41
本帖最后由 largewc 于 2013-10-31 09:47 编辑

ifu 发表于 2013-10-31 09:30
haswell也做不到同时发射 4 INT adds+ 2 FP adds当然L/S还是比A7强的

显然a7做不到超过2浮点计算能力，不借助simd，单说浮点的话，看不到a7比a6可能更快的地方。a6三发射端口对于2的浮点来说，也很充裕了。

作者: 532 时间: 2013-10-31 10:45

擦才发现这标题还给高亮了，跟隔壁交易区一样黑亮给群众鞭尸围观的么

小鸟那个说真的，touch4在个别场景一发KO引起太多物体崩塌的话，一样会卡，我也不晓得是不是得i7 5g跑才流畅，台式机上没玩过

作者: largewc 时间: 2013-10-31 10:48

532 发表于 2013-10-31 10:45
[sweatingbullets>擦才发现这标题还给高亮了，跟隔壁交易区一样黑亮给群众鞭尸围观的么

[sweatingbullet ...

多到一定程度啥也会卡，游戏一般控制在一定范围内。

box2d我们自己做过一个小东西自己玩，但是没有做过商品游戏。

bullet和ode都做过商业游戏。

作者: ifu 时间: 2013-10-31 10:58

largewc 发表于 2013-10-31 09:41
显然a7做不到超过2浮点计算能力，不借助simd，单说浮点的话，看不到a7比a6可能更快的地方。a6三发射端口对 ...

浮点本来在日常应用中所占比例就小。
haswell也只能同时发射2条浮点指令，没人会认为haswell和a6一个档次吧

作者: largewc 时间: 2013-10-31 11:07

ifu 发表于 2013-10-31 10:58
浮点本来在日常应用中所占比例就小。
haswell也只能同时发射2条浮点指令，没人会认为haswell和a6一个档次 ...

haswell确实也只有两个，但是haswell支持avx，加入向量矩阵的专项指令显然可以大幅度加速3d程序。
arm可能未来的版本也会加入这个吧，那时候浮点同频差距就不会太了。

arm再加入这些东西以后，带来的编译问题也会加重，不过这个对于苹果来说并不是什么太大的问题。

我继续维持苹果可能会做出最强的arm的结论，未来苹果会从指令集和微构架入手改良arm，继续堆叠运算单元的时代将要过去了。

作者: shadowlich 时间: 2013-10-31 11:23
提示: 作者被禁止或删除内容自动屏蔽

作者: acqwer 时间: 2013-10-31 11:55
LZ又是从哪里看出A7只有一组L/S呢，莫非是Apple内部的CPU开发人员？

作者: 532 时间: 2013-10-31 11:59

acqwer 发表于 2013-10-31 11:55
LZ又是从哪里看出A7只有一组L/S呢，莫非是Apple内部的CPU开发人员？

最起码也是官方发炎人，前些天还“在此我正式宣布a7 ipc是a6两倍”来着

作者: acqwer 时间: 2013-10-31 12:01

four integer adds and two FP adds in parallel

这是SIMD的情况下吧

作者: acqwer 时间: 2013-10-31 12:03

532 发表于 2013-10-31 11:59
[sweatingbullets>最起码也是官方发炎人，前些天还“在此我正式宣布a7 ipc是a6两倍”来着

其实原文有这一句

You can also perform up to two loads or stores per clock.

不过砖家没看懂罢了。

作者: largewc 时间: 2013-10-31 12:25

acqwer 发表于 2013-10-31 12:01
这是SIMD的情况下吧

应该不是，simd的话fp应该有8组了。

估计整数确实叠到了4组

a7两组l/s吧，ifu转的那段话不是说了。

作者: the_god_of_pig 时间: 2013-10-31 12:31
本帖最后由 the_god_of_pig 于 2013-10-31 12:34 编辑

acqwer 发表于 2013-10-31 12:03
其实原文有这一句

不过砖家没看懂罢了。

最近好像流行在无源码的情况下靠数单元和cache判断瓶颈，所以在预设观点的前提下无视某些单元也是正常的

作者: ifu 时间: 2013-10-31 12:47

acqwer 发表于 2013-10-31 11:55
LZ又是从哪里看出A7只有一组L/S呢，莫非是Apple内部的CPU开发人员？

同时只能2L ，2S，(1L+1S) 当然不如 haswell的2L+1S

作者: ifu 时间: 2013-10-31 12:48

shadowlich 发表于 2013-10-31 11:23
LZ你谈苹果就谈苹果，不要在没搞清楚的情况下就扯xbox。人家的32M ESRAM明明CPU/GPU都可以用。到你这里就成 ...

作者: acqwer 时间: 2013-10-31 12:52
本帖最后由 acqwer 于 2013-10-31 12:57 编辑

ifu 发表于 2013-10-31 12:47
同时只能2L ，2S，(1L+1S) 当然不如 haswell的2L+1S

不知和只有1L 1S的Nehalem或者Core2相比，哪个更瓶颈呢？
[img]
http://images.anandtech.com/revi ... ure/nehalemexec.png[/img]

作者: ifu 时间: 2013-10-31 12:53

532 发表于 2013-10-31 11:59
[sweatingbullets>最起码也是官方发炎人，前些天还“在此我正式宣布a7 ipc是a6两倍”来着

“在此我正式宣布a7 ipc是a6两倍”找来看看？

作者: ifu 时间: 2013-10-31 12:57

largewc 发表于 2013-10-31 11:07
haswell确实也只有两个，但是haswell支持avx，加入向量矩阵的专项指令显然可以大幅度加速3d程序。
arm可 ...

这玩意就simd了，大部分非数值之类的程序能向量化的不多。
要重负载浮点计算GPU融合才是大势，不知道水果啥时候能融合

作者: acqwer 时间: 2013-10-31 13:00

largewc 发表于 2013-10-31 12:25
应该不是，simd的话fp应该有8组了。

估计整数确实叠到了4组

如果是一次多少指令就不会用4adds这种特指了吧，Conreo的128bit的SIMD 描述就是4 fp adds or muls每周期。

作者: eraser666 时间: 2013-10-31 13:04
intel真是丧心病狂 L4那给CPU和Iris Pro共用
顺便也把Kaveri加进你的丧心病狂名单吧

请不要看到几行字就高潮

作者: shadowlich 时间: 2013-10-31 13:37
提示: 作者被禁止或删除内容自动屏蔽

作者: ifu 时间: 2013-10-31 13:50

acqwer 发表于 2013-10-31 12:52
不知和只有1L 1S的Nehalem或者Core2相比，哪个更瓶颈呢？

这不能简单直接比，还涉及到TLB size和cache size之类

作者: acqwer 时间: 2013-10-31 14:01

ifu 发表于 2013-10-31 13:50
这不能简单直接比，还涉及到TLB size和cache size之类

和双核的Nahelem比Cache也是A7大，TLB size A7没数据，你是不是要脑补个很低的数字出来啊。

最核心的问题在于，连你和T神这种智商的外行都看得出来的而且并不难解决的问题，苹果的开发人员居然看不出，你是黑苹果呢还是黑苹果呢还是黑苹果呢？

作者: eraser666 时间: 2013-10-31 14:09

acqwer 发表于 2013-10-31 14:01
和双核的Nahelem比Cache也是A7大，TLB size A7没数据，你是不是要脑补个很低的数字出来啊。

最核心的问 ...

继续搬出之前的结论

T神根本不是果粉，是最近很流行的一个词，反串黑

这位大神，不作评论

作者: ifu 时间: 2013-10-31 14:21

acqwer 发表于 2013-10-31 14:01
和双核的Nahelem比Cache也是A7大，TLB size A7没数据，你是不是要脑补个很低的数字出来啊。

最核心的问 ...

还没发生的事你就别急吼吼的脑补扣帽子了。
苹果的开发人员是有所取舍的，无序随机访问在他们关注的领域占多大比重还在是个问号。所有处理器在设计时都有它们针对的目标应用领域。目前看来A7在平板电脑和手机所关注的浏览器性能上相比A6提升了一倍性能，从这个意义上说A7是成功的。

作者: acqwer 时间: 2013-10-31 14:27

ifu 发表于 2013-10-31 14:21
还没发生的事你就别急吼吼的脑补扣帽子了。
苹果的开发人员是有所取舍的，无序随机访问在他们关注的领域 ...

别转进嘛，给出个合理的解释来。

说无序随机访问的作用，基本上所有的系统都是无序随机，能做到循序内存访问用的并不多，Cache优化的重点是无序随机访问，循序内存访问主要用在数据流，基本上是Cache无关，因为Cache再大也不够用。

当然，作为果黑，这样说的确没问题，水果就是搞个跑分高的烂货忽悠果粉，一到实际应用就露馅了。

作者: acqwer 时间: 2013-10-31 14:31
本帖最后由 acqwer 于 2013-10-31 14:32 编辑

目前看来A7在平板电脑和手机所关注的浏览器性能上相比A6提升了一倍性能，从这个意义上说A7是成功的。

平板电脑关注的是浏览器性能？都测试这个是因为平板手机上面压根就没几个靠谱的测试好吧，3dmark、GFX和Geekbench这种都把每个项目单独列出来才能凑出几页测试。

作者: xf-108 时间: 2013-10-31 16:19

largewc 发表于 2013-10-31 11:07
haswell确实也只有两个，但是haswell支持avx，加入向量矩阵的专项指令显然可以大幅度加速3d程序。
arm可 ...

avx已经扩展到双发射256位，马上要拓展到512甚至1024位。
128位的东西有什么资格差不多？

作者: ifu 时间: 2013-10-31 18:01

acqwer 发表于 2013-10-31 14:27
别转进嘛，给出个合理的解释来。

说无序随机访问的作用，基本上所有的系统都是无序随机，能做到循序内 ...

通过futuremark工作人员的描述和实验仅能将瓶颈定位为无序访存，要进一步精确定位就需要用performance monitor之类咚咚通过硬件计数器来查看程序运行时情况。
我理解你果黑的立场，但3DMark物理测试何尝不是跑分，总不能因为它使得A7跑分低就被抬高到实际应用一类。

作者: ifu 时间: 2013-10-31 18:02

acqwer 发表于 2013-10-31 14:31
平板电脑关注的是浏览器性能？都测试这个是因为平板手机上面压根就没几个靠谱的测试好吧，3dmark、GFX和G ...

对大多数人来说上网绝对是平板的主要应用。
嗯，我也希望有更多的跨平台benchmark

作者: largewc 时间: 2013-10-31 18:07

ifu 发表于 2013-10-31 18:01
通过futuremark工作人员的描述和实验仅能将瓶颈定位为无序访存，要进一步精确定位就需要用performance mo ...

我认为不是缓存问题，最大的问题还是a7的浮点仍然是两个的缘故

不过a7比我想象的出色，上网a7确实理想，我怀疑intel受此影响，明年的cherry trail整数叠到三组。

作者: ifu 时间: 2013-10-31 18:14

shadowlich 发表于 2013-10-31 13:37
这图只说明了ESRAM是挂在GMC上的，为何CPU不能访问？是否因为DRAM是挂在NB上的，所以GPU也不能访问呢？

A7这4MB SRAM对CPU来说被当作L3 cache，是透明的。ESRAM能么？笑话。
你再好好看看那个图

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

largewc 发表于 2013-10-31 18:07
我认为不是缓存问题，最大的问题还是a7的浮点仍然是两个的缘故

不过a7比我想象的出色，上网a7确实理想 ...

futuremark的人把数据layout优化后性能提升了2倍，要是浮点资源不足的话layout优化也是白搭
希望明年Intel能升级架构，有竞争才有进步

作者: largewc 时间: 2013-10-31 18:22

ifu 发表于 2013-10-31 18:20
futuremark的人把数据layout优化后性能提升了2倍，要是浮点资源不足的话layout优化也是白搭
希望明年Int ...

另外一个帖子我已经贴了t神说的那个函数，还是那个问题，不连续化的只有碰撞检测的物体，如果把碰撞体连续化了，simd指令会自动起作用了。

作者: ifu 时间: 2013-10-31 18:43

largewc 发表于 2013-10-31 18:22
另外一个帖子我已经贴了t神说的那个函数，还是那个问题，不连续化的只有碰撞检测的物体，如果把碰撞体连续 ...

采不采用simd指令在程序执行之前已经决定了的。
除非futuremark的测试中针对layout写了有simd的和没simd的两个版本你的观点才成立。但futuremark的开发人员描述中未提到这一点

作者: largewc 时间: 2013-10-31 18:45

ifu 发表于 2013-10-31 18:43
采不采用simd指令在程序执行之前已经决定了的。
除非futuremark的测试中针对layout写了有simd的和没simd ...

嗯，这个我同意了，我加大内存量，试试core有没有所谓的这个缓存点，测试一下就好了

作者: largewc 时间: 2013-10-31 19:06

ifu 发表于 2013-10-31 18:43
采不采用simd指令在程序执行之前已经决定了的。
除非futuremark的测试中针对layout写了有simd的和没simd ...

futuremark说了已经编译器已经simd化了，后来为了测试，又手工simd化也不影响性能，说明默认编译的simd性能还可以。

或许是因为a6的simd + 内存乱序都到了瓶颈，所以顺序以后，simd本身仍然存在很大瓶颈，并不会加速。

而a7的simd已经冗余了，内存部分瓶颈会带来整体瓶颈。

作者: ifu 时间: 2013-10-31 19:46

largewc 发表于 2013-10-31 19:06
futuremark说了已经编译器已经simd化了，后来为了测试，又手工simd化也不影响性能，说明默认编译的simd性 ...

嗯，A6的计算资源没有A7这么暴力所以在A6上访存不成为瓶颈，或者说计算能力和随机访存性能在3DMark物理跑分上是合拍的。
A7更为强大的prefetch加重了访存压力，无效的prefetch使得访存瓶颈更为明显。所以就出现A7得分不如A6的一幕

作者: Tempestglen 时间: 2013-10-31 20:19
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 20:27

Tempestglen 发表于 2013-10-31 20:19
你的英语令人着急啊。

futuremark的意思是，编译器确实开启了SIMD（neon），但是，没有效果，之后手动 ...

编译器已经开了simd，但是对于性能没有效果，手动编写simd，仍然对性能没有效果，是这个意思难道不对？

这个说明默认的simd性能已经足够高了

作者: largewc 时间: 2013-10-31 20:30

Tempestglen 发表于 2013-10-31 20:19
你的英语令人着急啊。

futuremark的意思是，编译器确实开启了SIMD（neon），但是，没有效果，之后手动 ...

simd肯定是起作用了，只不过瓶颈确实不在这里，这个我现在认可了，有什么问题吗？

作者: Tempestglen 时间: 2013-10-31 20:37
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 20:49
本帖最后由 largewc 于 2013-10-31 20:50 编辑

Tempestglen 发表于 2013-10-31 20:37
编译器开了SIMD，没有效果，意思就是和没开SIMD一样，根本没有矢量化。

所以，哪里来的默认的SIMD性能 ...

我刚编译过PSolve_Links，可以肯定，100%进行simd编译了，无论是xcode还是vs 2012下，而且这个函数属于simd较为理想的情况。

手动simd的话还是可以显著继续提高性能，在基于avx指令的情况下，对PSolve_Links我初步修改了一些结构，初步试验了一下。

明天我找一个iphone5测试一下吧，现在手上没有设备。

我的3630qm大体在小额内存的情况下（200-300k左右），连续可以提升25%左右
而在大额内存的情况下（20m附近），连续可以提升50%性能

作者: largewc 时间: 2013-10-31 20:52

Tempestglen 发表于 2013-10-31 20:37
编译器开了SIMD，没有效果，意思就是和没开SIMD一样，根本没有矢量化。

所以，哪里来的默认的SIMD性能 ...

这个仅限于测试，并不能用在物理引擎中，因为没办法连续

作者: Tempestglen 时间: 2013-10-31 20:54
提示: 作者被禁止或删除内容自动屏蔽

作者: Tempestglen 时间: 2013-10-31 20:56
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 20:58
本帖最后由 largewc 于 2013-10-31 21:01 编辑

Tempestglen 发表于 2013-10-31 20:54
那么futuremark那人的意思，是指对5S进行了simd编译，没有相对于iphone5的更好效果？这就讲得通了。

你 ...

嗯，更正一下，3630qm小额的情况下确实连续只能影响不到10%性能

也就是a7的缓存问题带来瓶颈，双发射的neon指令优化也毫无价值，被缓存问题掩盖了

就是working set

作者: largewc 时间: 2013-10-31 21:00

Tempestglen 发表于 2013-10-31 20:56
没办法连续不要紧，连有规律的访存都做不到？有规律而不连续，prefetch一样起作用。

没办法，还是这个问题，碰到的东西是随机的，这玩意肯定是new出来的，而不是一个整体内存。

作者: Tempestglen 时间: 2013-10-31 21:01
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 21:05

Tempestglen 发表于 2013-10-31 21:01
也就是说3dmark physics这种复杂程度的场景所需要的working set，对于双核A7的1M L2来说太大了？所以随机 ...

很有可能，a7的simd还是比较强的，毕竟是avx级别的。

作者: Tempestglen 时间: 2013-10-31 21:07
提示: 作者被禁止或删除内容自动屏蔽

作者: Tempestglen 时间: 2013-10-31 21:12
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 21:17

Tempestglen 发表于 2013-10-31 21:12
http://ark.intel.com/products/71459/Intel-Core-i7-3630QM-Processor-6M-Cache-up-to-3_40-GHz

3630qm ...

2.x m的时候，大概性能影响20%

4.x m - 6.x的时候，大概性能影响30%

13.xm的时候，大概影响就有40%了

估计3dmark不是1m的数据量，而是若干m。

作者: ifu 时间: 2013-10-31 21:22

largewc 发表于 2013-10-31 20:49
我刚编译过PSolve_Links，可以肯定，100%进行simd编译了，无论是xcode还是vs 2012下，而且这个函数属于 ...

最好有个iphone5s跟iphone5以及haswell做对比

这样才知道哪个数据规模是拐点以及消除了访存屏障后和haswell的差距究竟有多大。

作者: largewc 时间: 2013-10-31 21:22

Tempestglen 发表于 2013-10-31 21:12
http://ark.intel.com/products/71459/Intel-Core-i7-3630QM-Processor-6M-Cache-up-to-3_40-GHz

3630qm ...

仔细测试了一下，大概发现3630qm的阈值大概是1m附近，低于1m以后，连续内存影响度就很小了

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

ifu 发表于 2013-10-31 21:22
最好有个iphone5s跟iphone5以及haswell做对比这样才知道哪个数据规模是拐点以及消除了访存屏障后和h ...

你赞助我一个iphone5s就可以测试

a7看来内存瓶颈是存在的

我仍然保留a7非simd部分的浮点性能，没有simd的部分a7浮点不会有太多加成。

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

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

ifu 发表于 2013-10-31 21:22
最好有个iphone5s跟iphone5以及haswell做对比[lol>这样才知道哪个数据规模是拐点以及消除了访存屏障后和h ...

而且这个是柔体部分，我觉得意义也不大，物理要是测cpu，还是纯跑刚体合适。

柔体交给gpu较为合理，反正pc端的游戏大都是这样的，不会用cpu跑柔体的。

作者: Tempestglen 时间: 2013-10-31 21:32
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 21:34

Tempestglen 发表于 2013-10-31 21:32
3630qm的L2到底多大呢？

处理器信息

处理器 Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz
运行速度 2400.0 MHz
核心/线程四核
核心代号 Ivy Bridge-MB SV
功耗 45.0 W
插座 rPGA988B
一级缓存指令: 32 KBytes, Data: 32 KBytes
二级缓存集成: 256 KBytes
三级缓存 6 MB
特性 MMX　SSE　SSE-2　SSE-3　SSSE-3　SSE4.1　SSE4.2　AVX　EMT64　VT　EIST　TM1　TM2　Turbo Boost

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

Tempestglen 发表于 2013-10-31 21:32
3630qm的L2到底多大呢？

在1m以内的情况下，avx手工优化是有加成的，如果在20m的情况下，avx手工优化几乎没有价值。

作者: ifu 时间: 2013-10-31 21:39

Tempestglen 发表于 2013-10-31 21:31
如果3dmark physics（ice storm）的working set大于2M比如是3M，那么S所有sox都卡在IO瓶颈上， S800/5420 ...

S800/5420/bt/A7其实也没在随机访存上占优，不过S800/5420/bt的高主频和更多的核掩盖了这一切。
你把S800/5420/bt正规化到1C1GHz你就会发现它们的性能还是不如A7的。
S800/5420/bt的计算资源不能和A7相提并论，所以它们的瓶颈也未必在随机访存上。
要能有个小数据规模S800/5420/bt/A7/A6/haswell大比拼就好了

作者: ifu 时间: 2013-10-31 21:42

largewc 发表于 2013-10-31 21:00
没办法，还是这个问题，碰到的东西是随机的，这玩意肯定是new出来的，而不是一个整体内存。

自己写mempool预分配优化？

作者: largewc 时间: 2013-10-31 21:44

ifu 发表于 2013-10-31 21:42
自己写mempool预分配优化？

没意义，因为对象数量和大小都不是固定的，类型甚至都不是固定的，所以没实质价值

这个可以交给gpu加速，我试试c++ amp交给gpu可以快多少。

作者: largewc 时间: 2013-10-31 21:58

ifu 发表于 2013-10-31 21:42
自己写mempool预分配优化？

放弃了，太麻烦，暂时我们用不到以后再说吧

作者: ifu 时间: 2013-10-31 21:58

Tempestglen 发表于 2013-10-31 21:07
就是说如果working set小到 L2可以容纳的地步，什么连续不连续有无规律都已经不重要了？你需要测试一下2M， ...

数据集要为L2的几分之一才行，cache的组织方式和替换策略使得数据集不可能完全占用cache

作者: ifu 时间: 2013-10-31 22:07

largewc 发表于 2013-10-31 21:58
放弃了，太麻烦，暂时我们用不到以后再说吧

是比较麻烦，在程序行为以及数据规模有预期的情况下对核心数据用自己的mempool还是可以收到不错的效果。
某些情况下手工插入prefetch指令也能管些用，很多对CPU来说无序的访问对人来说还是有规律的，至少可以提前预知....比如二叉树

作者: largewc 时间: 2013-10-31 22:08

ifu 发表于 2013-10-31 21:39
S800/5420/bt/A7其实也没在随机访存上占优，不过S800/5420/bt的高主频和更多的核掩盖了这一切。
你把S80 ...

但是s800和bt确实可以更高频，而且bt可以稳定频率去跑，最终拼的还是最终性能，而不是一个理论的同频性能。

现在可以肯定，单核性能a7大体跟高频bt相当，因为bt更均衡，所以实际性能还是要比a7好一些的，同频bt比不了a7.。

我对x86的优势理解是，在同功耗的情况下，x86可以获得比arm更好的性能，这是x86的特性决定的。

未来这种趋势会更明显，功耗的优劣已经反转了。

作者: largewc 时间: 2013-10-31 22:11
本帖最后由 largewc 于 2013-10-31 22:13 编辑

ifu 发表于 2013-10-31 22:07
是比较麻烦，在程序行为以及数据规模有预期的情况下对核心数据用自己的mempool还是可以收到不错的效果。
...

mempool我们有的，只是对小额内存和相对尺寸固定的有用

物理的数组都是不确定长度的，引用的对象更是连类型都不确定，这玩意不太可能连续的

简单来说，随便一个body，碰撞提，它可能是球，可能是盒子，可能是圆柱，也可能是柔体，你怎么连续化？mempool也无能为力。

甚至就只算柔体，柔体的样子和顶点数量，也都是不确定的，头发有几片，估计只有美术自己清楚，衣服几个面，估计也只有美术清楚。

你连一个可以预测的范围估计能困难，所以mempool不会有加成

而且物理对象的数量是随时变的，特别是联机游戏，随机怪物，随机出现的角色，有大量的free和malloc，很难用mempool来优化。物理引擎也是容易造成内存碎片的地方。

作者: Tempestglen 时间: 2013-10-31 22:26
提示: 作者被禁止或删除内容自动屏蔽

作者: ifu 时间: 2013-10-31 22:32

largewc 发表于 2013-10-31 22:11
mempool我们有的，只是对小额内存和相对尺寸固定的有用

物理的数组都是不确定长度的，引用的对象更是 ...

实在无法连续分配内存的情况下，可以通过手工prefetch优化。像我前面提的二叉树查找，如果bullet有的话就可以手工prefetch优化。

btw:A7的64位模式下对象的创建和销毁是有大幅性能提升的
http://www.mikeash.com/pyblog/fr ... -arm64-and-you.html
Adding it all together, it's a pretty big win. My casual benchmarking indicates that basic object creation and destruction takes about 380ns on a 5S running in 32-bit mode, while it's only about 200ns when running in 64-bit mode. If any instance of the class has ever had a weak reference and an associated object set, the 32-bit time rises to about 480ns, while the 64-bit time remains around 200ns for any instances that were not themselves the target.

In short, the improvements to Apple's runtime make it so that object allocation in 64-bit mode costs only 40-50% of what it does in 32-bit mode. If your app creates and destroys a lot of objects, that's a big deal.

作者: westlee 时间: 2013-10-31 22:34
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 22:36

ifu 发表于 2013-10-31 22:32
实在无法连续分配内存的情况下，可以通过手工prefetch优化。像我前面提的二叉树查找，如果bullet有的话就 ...

怎么优化二叉树查找？我很好奇，要知道，这个树是自衡二叉树，不停得在增减东西的。

作者: Tempestglen 时间: 2013-10-31 22:44
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 22:46
本帖最后由 largewc 于 2013-10-31 22:49 编辑

westlee 发表于 2013-10-31 22:34
不同缓存数量的c2d在新3dmark中的成绩。

具体的缓存数量就不用科普了吧。

估计是a7缓存设计有问题，我的3630因此带来的影响是缓慢提升的，而且即使到超过了20m影响也超不过50%。代码我是用avx优化的，不会比双发射的neon更慢的。

而且这个只计算了PSolve_Links，没考虑前端的问题

而且我估计这个PSolve_Links占总消耗大概50%左右，3dmark的那段话应该意思是剥离PSolve_Links可以加速一倍，也就是消耗占据一半，即使a7缓存不是问题，PSolve_Links加速一倍，不过也就是减少了25%的消耗而已。

缓存对core的影响估计不到25%，应该是20%以内

作者: Tempestglen 时间: 2013-10-31 22:53
提示: 作者被禁止或删除内容自动屏蔽

作者: largewc 时间: 2013-10-31 23:00

Tempestglen 发表于 2013-10-31 22:53
1）futuremark的人说psolve link消耗了几乎所有的cpu时间。

2）我刚才举了cortex A15和cyclone的例子。 ...

应该不止PSolve_links，这个只是soft body solver的后端部分而已，soft body solver应该前端消耗也不少。

3dmark的意思应该是拆开PSolve_links就能提速一倍，后来又找了各种办法优化PSolve_links，通过连续内存可以提升一倍性能

但是PSolve_links本身只能占据一半消耗。对于core可能连一半都不到

作者: Tempestglen 时间: 2013-10-31 23:02
提示: 作者被禁止或删除内容自动屏蔽

作者: ifu 时间: 2013-10-31 23:02

largewc 发表于 2013-10-31 22:36
怎么优化二叉树查找？我很好奇，要知道，这个树是自衡二叉树，不停得在增减东西的。

这个很容易，最傻瓜的方法贪婪预取就行了。按照具体实现还可以有进一步的优化。
这些文章你可以参考一下
http://embedded.cs.uni-saarland. ... achePrefetching.pdf
http://www.eecg.toronto.edu/~moshovos/research/dep-pref.pdf

作者: ifu 时间: 2013-10-31 23:04

largewc 发表于 2013-10-31 22:46
估计是a7缓存设计有问题，我的3630因此带来的影响是缓慢提升的，而且即使到超过了20m影响也超不过50%。 ...

TLB 也有影响的

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