媲美A15：iphone5s CPU持续全开频率只有900Mhz

acqwer

Tempestglen 发表于 2013-10-31 17:22
1）你先拿出bullet受益于prefetch的证据来，看看地球人是如何预测随机数据的，大家开开眼。

2）流数据 ...

只要是链表的数据结构，预取都是有效的，如果没效果，那么瓶颈就不在内存读取。这句话你可以去问中科大的高才生，看对不对。

largewc

acqwer 发表于 2013-10-31 17:24
只要是链表的数据结构，预取都是有效的，如果没效果，那么瓶颈就不在内存读取。这句话你可以去问中科大的 ...

我贴了t神认为的问题函数，请t神来优化一下吧。

物理引擎的核心就是树结构，我是想不到树结构还能怎么规律化内存，树要解决的问题就是超大规模的数据的快速排序查找，目的就是要解决无规律问题的。

largewc

acqwer 发表于 2013-10-31 17:24
只要是链表的数据结构，预取都是有效的，如果没效果，那么瓶颈就不在内存读取。这句话你可以去问中科大的 ...

ode有一个函数可以控制迭代次数

dWorldSetQuickStepNumIterations (dWorldID, int num)
  Set the number of iterations that the QuickStep method performs per step.  

这个函数不被调用，默认就是20的迭代，也就是后端计算20遍，计算20遍这种不但有规律，甚至内存都只用同一块的，当然预读取会很明显加速

largewc

acqwer 发表于 2013-10-31 17:24
只要是链表的数据结构，预取都是有效的，如果没效果，那么瓶颈就不在内存读取。这句话你可以去问中科大的 ...

防止t神不认，再加点吧

ode的中文介绍
http://www.cppblog.com/gaimor/archive/2010/02/26/108477.html


7.设置和获取仿真步迭代器个数

1void dWorldSetQuickStepNumIterations (dWorldID, int num);
2int dWorldGetQuickStepNumIterations (dWorldID);
默认的迭代器个数为20.迭代器越多则结果越精确但是速度会变慢

acqwer

largewc 发表于 2013-10-31 17:30
ode有一个函数可以控制迭代次数

dWorldSetQuickStepNumIterations (dWorldID, int num)

反复迭代当然是Cache最喜欢的代码，就如小规模的SuperPI和不少JS测试。所以以后水果都只跑这种代码吧。

largewc

acqwer 发表于 2013-10-31 17:37
反复迭代当然是Cache最喜欢的代码，就如小规模的SuperPI和不少JS测试。所以以后水果都只跑这种代码吧。

ode整理到连续内存估计可以加速不少的，因为要重复访问

不过不太影响真实游戏，因为即使用ode，没一个游戏敢用20的迭代的

acqwer

Tempestglen 发表于 2013-10-31 17:41
1）连续化是指连续放置在内存中？还是指有规律化？假设如你所说物理计算的内存使用无法有规律化。那么就有 ...

A7是2M的L2（2*1M），那张图很清楚了

largewc

Tempestglen 发表于 2013-10-31 17:41
1）连续化是指连续放置在内存中？还是指有规律化？假设如你所说物理计算的内存使用无法有规律化。那么就有 ...

我认为连续的优势主要还是simd化吧，如果node不是指针，改成成员，预先填入固定数值，这样就完全连续了

一旦这样可以，代码马上就可以simd化了，这样获得2-3倍提升还是很容易的。


        struct        Link : Feature
        {
                //Node*                                        m_n[2];                        // Node pointers
                Node                                        m_n[2];                        //改成成员就连续化了，这样也就可以simd化了
                btScalar                                m_rl;                        // Rest length               
                int                                                m_bbending:1;        // Bending link
                btScalar                                m_c0;                        // (ima+imb)*kLST
                btScalar                                m_c1;                        // rl^2
                btScalar                                m_c2;                        // |gradient|^2/c0
                btVector3                                m_c3;                        // gradient
        }

largewc

Tempestglen 发表于 2013-10-31 17:48
何以见得？ 在1M左右，延迟开始飙升，这是双核A7的表现，不是单核的曲线吧。

我认为关键还是a7的浮点仍然是两个运算单元，不simd不可能有大幅度提升的。

a7整数堆到4 alu还是超过了我的预期，我认为a7设计的依然很出色。

视频解码原来是ipad的软肋，这次应该不会了。

网页浏览我原以为只是苹果的软件优化，现在这个收回，a7的整数能力确实强大了不少。同频bt整数肯定不如a7，估计3770的整数单核能力跟a7比，也基本属于一个等级的。

acqwer

Tempestglen 发表于 2013-10-31 17:48
何以见得？ 在1M左右，延迟开始飙升，这是双核A7的表现，不是单核的曲线吧。

延迟都是测试单核心，如果测试多核的话就存在通讯的问题了，程序并不知道测试的数据到底是在哪个核心的Cache中。

看了原文
While I originally assumed that this SRAM might be reserved for use by the ISP, it turns out that it can do a lot more than that. If we look at memory latency (from the perspective of a single CPU core) vs. transfer size on A7 we notice a very interesting phenomenon between 1MB and 4MB:

ifu

acqwer 发表于 2013-10-31 17:50
延迟都是测试单核心，如果测试多核的话就存在通讯的问题了，程序并不知道测试的数据到底是在哪个核心的 ...

L2是共享的，单双核心看到的都是1MB

largewc

Tempestglen 发表于 2013-10-31 18:32
你能不能调整一下bullet的working set（热工作集）也就是footprint的大小？  看看对最终性能有无影响。 存 ...

嗯，改天测试一下吧，可以专门测试这个函数就好了，我看看是否存在这个内存瓶颈点

不过这个柔体后期计算部分，是可以交给gpu计算的，这玩意显然是gpu发挥更好的地方。

largewc

Tempestglen 发表于 2013-10-31 18:32
你能不能调整一下bullet的working set（热工作集）也就是footprint的大小？  看看对最终性能有无影响。 存 ...

不一定是bullet是这么多，应该是3dmark的场景复杂度是这么多，不知道3dmark缩小一些物理复杂度是否可以降低内存部分


不过手上没有iphone5s，测不了，汗

largewc

Tempestglen 发表于 2013-10-31 18:44
四个字，完全扯淡。是不是链表跟预取结果好坏没有直接关系，取决于malloc给链表分配的地址，使用链表的基 ...

这个确实如此，不过一般类似苹果或者自己引擎的sdk，都有内存池优化，new出来的内存是经过处理的，malloc通常没有这个加成，不过貌似微软和安卓的sdk默认都没有这个东西。

内存池可以对小额内存进行快速分配和回收，尽量把内存放到一个连续空间内了。

largewc

Tempestglen 发表于 2013-10-31 18:46
降低 working set，必须降低场景复杂度？

应该是吧，要么降低碰撞复杂度，减少碰撞机会