This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

6678 复数矩阵相乘 耗时统计



工程师好,我们要进行资源评估,我跑C:\ti\dsplib_c66x_3_4_0_0\packages\ti\dsplib\src\DSPF_sp_mat_mul_gemm_cplx下的例程,在release下,优化级别选3,用TSCH和TSCL方式来统计16*16的矩阵A与16*16的矩阵B相乘的耗时,显示跑了127091个指令周期,相当于耗时0.127ms,不知道这种统计方法准确不准确

  • TSCH, TSCL是以CPU clock计时的,可以用来统计指令执行周期数。
  • 工程师你好,我发现用2*2的两个复数矩阵相乘release下耗时2ns,64*64的两个复数矩阵相乘的release下耗时0.132s,不是按照乘加计算的比例增加的,是不是由于矩阵的维度过大不一样,一级缓存一下子装不下,一次计算不过来 ,隐含的有数据搬移的耗时,比如ddr到二级缓存中的搬移的耗时,二级缓存到一级缓存的耗时

  • 理论上来讲,都可以优化到按运算量的比例增加,关键是看数据流程能否优化到这个样子,这里面的因素比较多,除了你说的可能的大块拆分成小块的拆分外以及后续的再次重组外,还有cache miss带来的stall,接口间调用代理的跳转延迟,使用RTOS后tick中断带来的中断上下文切换以及任务调度的OS消耗。
    实际上,功底强的话,上述部分是可以规避/优化的,但是大矩阵无论如何都要进行内存交换,这个避免不了。
    2ns下的2*2运算,仅仅是上述情况都不存在且cache完全覆盖下的使用内联指令并经并行优化+全寄存器缓存(即不仅中间运算数据,最初的数据输入和最终的运算结果同样保存在寄存器,否则单存的数据加载/存储都分别至少需要4个cycle,当然大矩阵可以使用并行执行抵消一部分)后的极端简单情况。
  • 你好,我查到Ti工程师发表的论文,基于bios系统8核的大矩阵计算相乘的浮点计算能力,我能不能根据我的矩阵大小的规模,统计出乘加计算量,然后根据他给出该规模的方阵的GFLOPS能力,来进行我的资源评估
  • 芯片的理论计算能力和你的算法实现后所需要的算力,都是定数。芯片能提供的算力*利用率*在最大延迟时间下的累积 必须大于等于你的算法实现需要的算力!

    那么,我们有以下路子可以去优化之:
    1. 使用更高算力的芯片,这个在选型确定后就没办法了,我们只能利用预研或已有的经验/数据去估计;
    2.优化利用率:这个主要从系统设计的流程上去做,核心目的就一个“让DSP最大限度地时间在并行地做运算”,主要是使用背景传输/优化算法流程结构已减少跳转延迟/尽可能关闭中断等外界干扰/合理进行内存布局提高cache覆盖等,另,其中的“并行度”与算法实现有关。
    3.系统的更高层次构架下,尽可能充裕预留延迟(比较难,这个涉及产品指标,一般最初就定死了,比如做高速飞行器跟踪,都得卡在us级延迟)
    4.算法实现:这个是联通第二点,是DSP优化的最主要两块。这里就要求对算法以及运算器件(DSP)的ISA有充分的了解了,涉及到的我知道的可以搞的除了2中包含的算法流程优化外,还有:计算/流程上充分利用DSP的并行指令/SPLOOP指令缓存/内联指令/算法针对更高效的DSP专属指令进行优化等。
    同时,数据结构也是一块,很可能为了适应更高的4里所涉及的算法运算优化,得重构已有的数据结构。


    ti哥给的那个示例,除非你也是用的他的模式,那么可以很大程度上类比过来。