关于计时的一个问题

[sxysxy]

关于计时的一个问题

[sxysxy]

但另一方面，在计时时进行cuda流同步，会降低CPU（执行python代码）和GPU（执行cuda kernels）的并行程度。加入计时后的程序运行时间会有一点不可忽略的增加。

[Maxwell-Lyu]

感谢您对这个问题的深入分析，“对每步操作进行单独计时，需要在操作头尾执行sync”这个结论应该是正确的。
CUDA kernel的执行是异步的没错，事实上我们从python调用在cuda上计算的函数，几乎都不会等待计算完成。除了一些意外情况，在pytorch的repo当中也有人指出这个bug。
但是有一些情况会符合预期地，去等待执行完成，然后将结果返回，比如手动调用synchronize，或者移动结果到CPU，faiss的检索就是后者的情况。

[sxysxy]

问题在于

timerNMT.start()
x = NMTModel(input)
timerNMT.stop()
timerKNN.start()
knn_retrieve(x)
timerKNN.stop()

faiss检索的时候隐式地进行了流同步，也就是在knn_retrieve(x)的内部进行了流同步，那么x=NMTModel(input)的大部分运行时间，也会被计入timerKNN中。在最开始，我没有在timer开始前进行同步的时候，测试也“复现出”和之前很多论文中提到的，KNN检索远比NMT模型耗时的现象。但后来加入同步之后，发现KNN检索的时间远比NMT少。

PCK KNN-MT论文说他们把推理延迟降低了最多57%。但是我在KNN-BOX框架下用Vanilla KNN-MT测试IT Medical Law Koran等数据集，推理阶段KNN检索所占用的总用时都远远不到57%。

PCK KNN-MT论文公开的代码以及还有Revised-Key KNN-MT公开的代码，都是基于原始KNN-MT论文的代码实现的，它们没有单独对NMT和KNN计时的代码。不过我发现他们的代码在运行的时候发现GPU利用率极低，远不如KNN-BOX。

所以KNN-MT速度慢到底是因为facebook研究院的号称在“10亿量级的索引可以做到毫秒级检索的性能”的FAISS慢，还是原始KNN-MT的代码优化太差导致的呢？KNN-MT加速的研究工作是否还有的做呢？