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

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，必须降低场景复杂度？

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

largewc

Tempestglen 发表于 2013-10-31 18:53
维持原来的场景复杂度，一半一半得计算，如何？把working set降低到1M，让A7的L2能装下。

一半一半计算跟完整计算没任何区别

我看了你转的那段话

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.

应该意思是physics测试主要是消耗在PSolve_links，屏蔽PSolve_links可以获得2倍速度提升

这个符合常识，因为对于柔体物理后期加工反而是消耗大户，所以物理引擎才需要支持gpu，主要还是柔体物理的需求。



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.

这个应该就是随即内存的问题，我只要测试这个函数就行了，外部传入一些参数看看缓存是否会影响core吧，反正我手上没有a7