meiqua

想了下，有个地方很可能会产生波动：[内存分配](https://github.com/meiqua/shape_based_matching/blob/4c2e0930962982e1180601cc01ec04cbdb28e242/fusion.h#L1493) 可能因为这一块是多线程，不断地销毁再申请内存导致这种嵌入式性能的平台扛不住。可以试试先把一块固定的内存给好

可以通过c++的placement new实现

整体耗时可能也有点帮助

需要改一些代码，有时间我看看

简单改了下，试试这个[fix_memo branch](https://github.com/meiqua/shape_based_matching/tree/fusion_fix_memo)

没有在GPU上跑。这样的话需要更细致的profile看看，可以这样： 1. 先把openmp关掉看一下，确认是不是openmp带来的问题 2. 更细致地对fusion每个阶段计算耗时，尽量缩小范围看哪一部分跳动

linux默认加上了，GPU本来就没用到

关掉openmp，时间会波动吗

process是主要运算函数，波动的话肯定是这个。可以在里面测试下各部分耗时

一般加-fopenmp会自动定义这个宏。波动的话，先不开openmp测一下时间，这样单线程比如容易确定是哪部分