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

acqwer

Tempestglen 发表于 2013-10-31 16:47
ODE就是啊，我已经贴图了。人家 在prefetch帮助下实现了60%的性能提升。bullet倒好，估计A7的prefetch还不 ...

T神的意思就是A7只能运行ODE这种规模的小型应用了？

slice

Tempestglen 发表于 2013-10-31 16:47
ODE就是啊，我已经贴图了。人家 在prefetch帮助下实现了60%的性能提升。bullet倒好，估计A7的prefetch还不 ...

问题是ODE这60%的提升，抵上ODE和bullet的效率差距了不？
例如用算20遍这种简单粗暴的逻辑,能prefetch又怎样呢?
已经局限了自己的使用场景.

raini

Tempestglen 发表于 2013-10-31 16:47
ODE就是啊，我已经贴图了。人家 在prefetch帮助下实现了60%的性能提升。bullet倒好，估计A7的prefetch还不 ...

你得了吧！人家说是一个物理引擎吗？
纯粹是某种计算方式下，这种计算方式能泛化到一个物理引擎的设计吗？

raini

Tempestglen 发表于 2013-10-31 16:51
如果数据都是 无规律得随机得放在内存里，那还要L2，L3干什么？反正根本不可能预测到下一步需要到内存哪个 ...

这SB从一个极端走到了另一个极端！

raini

Tempestglen 发表于 2013-10-31 16:51
如果数据都是 无规律得随机得放在内存里，那还要L2，L3干什么？反正根本不可能预测到下一步需要到内存哪个 ...

所以A7的prefetch功能强大到根本都不需要访问内存了？
这SB怎么能SB到这个程度呢？

acqwer

Tempestglen 发表于 2013-10-31 16:51
如果数据都是 无规律得随机得放在内存里，那还要L2，L3干什么？反正根本不可能预测到下一步需要到内存哪个 ...

T神先google一下看看链表是什么啊，当然是可以预测可优化的。没有任何证据表明bullet不能受益于prefetch，事实上同等规模的X86和ARM处理器都运行良好。

真正prefetch无效的倒是流数据和纯粹的矢量运行处理那些，因为Cache肯定不够。

raini

acqwer 发表于 2013-10-31 16:55
T神先google一下看看链表是什么啊，当然是可以预测可优化的。没有任何证据表明bullet不能受益于prefetc ...

这货一看到某高材生生说prefetch无用，就吵着要取消cache，这都是什么样的神逻辑神展开呀！

largewc

Tempestglen 发表于 2013-10-31 16:47
ODE就是啊，我已经贴图了。人家 在prefetch帮助下实现了60%的性能提升。bullet倒好，估计A7的prefetch还不 ...

我都解释过了，ode默认的模式毫无商业价值，如果取消后端20倍计算，ode一样也是前端消耗为主的，后端根本不构成压力

acqwer

largewc 发表于 2013-10-31 17:05
我都解释过了，ode默认的模式毫无商业价值，如果取消后端20倍计算，ode一样也是前端消耗为主的，后端根本 ...

物理引擎的后端部分应该是可以矢量化的吧，那么A7跑的比A6快不少。

largewc

acqwer 发表于 2013-10-31 17:08
物理引擎的后端部分应该是可以矢量化的吧，那么A7跑的比A6快不少。

理论上是可以的，其实前端的碰撞检测也可以simd化的，估计3dmark没有花力气优化。

acqwer

Tempestglen 发表于 2013-10-31 17:10
Futuremark的人已经说了，3dmark physics使用的物理引擎bullet，里面有个PSolve_links函数，cpu的耗费时 ...

A7是每个核心1M的L2，比竞争对手都大得多。看图就知道了

largewc

Tempestglen 发表于 2013-10-31 17:17
bullet与ODE的横向pk性能，与  本议题无关。
例如，
ODE不利用prefetch时的性能指数为1，利用好之后性能 ...

        struct        Link : Feature
        {
                Node*                                        m_n[2];                        // Node pointers
                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
        };

void                                btSoftBody::PSolve_Links(btSoftBody* psb,btScalar kst,btScalar ti)
{
        for(int i=0,ni=psb->m_links.size();i<ni;++i)
        {                       
                Link&        l=psb->m_links;
                if(l.m_c0>0)
                {
                        Node&                        a=*l.m_n[0];
                        Node&                        b=*l.m_n[1];
                        const btVector3        del=b.m_x-a.m_x;
                        const btScalar        len=del.length2();
                        const btScalar        k=((l.m_c1-len)/(l.m_c0*(l.m_c1+len)))*kst;
                        const btScalar        t=k*a.m_im;
                        a.m_x-=del*(k*a.m_im);
                        b.m_x+=del*(k*b.m_im);
                }
        }
}

bulllet的这个函数，这个显然是后端计算，link就是碰撞检测以后的碰撞点，这个函数是引用到物理响应。

m_links内部不是已经连续化了吗，不连续化的是link的node*，node*是表示检测到碰到的物体指针，这个还是老问题，前端碰撞检测你怎么给我连续化。

acqwer

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

2）流数据 ...

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

largewc

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

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

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