6发射。。。A7这么强的raw power，A8再改进恐怕得玩多线程了

largewc

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

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

ifu

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

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

自己写mempool预分配优化？

largewc

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

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

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

largewc

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

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

ifu

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

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

ifu

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

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

largewc

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

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

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

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

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

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

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

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

ifu

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.

largewc

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

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

largewc

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%以内

largewc

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可能连一半都不到

ifu

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

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

ifu

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

TLB 也有影响的