Nah Lock:一个无锁的内存分配器

　　对于64核的机器,完成时间的图表很难看懂,但是,我发现"工作"图表是并行和顺序执行特性的可读混合体.Y轴是线程数*完成时间(num_threads * time-to-completion).由于我期待着工作负载是平滑的分布,这就成为全部已做工作的一个大概统计.(相对于图中的曲线而言)好的斜率应该小于等于0.超过单一线程情况下(Y值)的Y值提供了近似的开销情况.

在第二个测试中,在线程分配和释放的全局池中,块的迁移非常高.

警告:这些测试有缺陷.请往下看.

在第三个测试中,单个线程生产块,供其它线程释放,块的迁移也非常高. 

在第三个测试中,单个线程生产块,供其它线程释放,块的迁移也非常高. (此句原文中出现重复)

随着线程间通过全局池发送块的通讯开销占据主导,测试2和测试3会产生缺陷.在6核机器上运行测试2, 76%的运行时间花费在nalloc之外,大多数操作位于无锁栈之上.我已经将池划分为多个栈,同时%100保证栈位于不同的高速缓存线.测试需要重写,用来隐式的转换块,或者只是降低频率.在这点上,我宁愿加入Alex R.的探求,通过块迁移来查明真正的工作负载.

课程回顾

• 如果你已有一个奢华的解决方案,你需要提前了解你的问题可能的瓶颈.

• 反过来,甚至当它只是可能的情况下,尝试和失败可能是唯一的方式,来更好的权衡利弊,并处理这些瓶颈.

• 你不能心存侥幸的围绕快速单线程代码,来编写一个快速并行包装器.你必须关注并行程序的串行部分,因为它们之间可能通过一种隐晦的方式来竞争或沟通.这是SAXPY的教训(尽管SAXPY有一个不同的隐含议题),但是我已经忘记它了.

• 如果你是理论上的完美并行,但是没有看到完美加速,考虑共享内存 和/或者 共享缓存 VS 工作集大小的效果.

• LibreOffice图表在LibreOffice之外看起来更丑陋.

勘误表

"加速"可能是我的"性能"图表更具描述性的名字.

参考

• jemalloc

• tcmalloc

• Streamflow

• NBMalloc

• Lockless    Malloc

• Maged    Michael + his malloc

• Synthesis