我试着用gensim库中实现的word2vec进行并行。我注意到，我越是增加线程，训练就越是缓慢，我不知道为什么。
谢谢你的提前
Gensim的默认&原始方式指定训练语料库，用于 Word2Vec (&相关模型)是通过一个单一的可迭代对象，它可以依次提供每个文本实例。然后，一个单一的主线程从可迭代对象中读取，将成批的文本分发给任意数量的工作线程（由该线程控制的 workers 参数）。)
这仍然面临着一些性能瓶颈，无法充分利用大量的线程，尤其是当线程数量增长时。
首先如果可迭代对象本身也在做任何耗时的工作来准备每个项目--比如标记化或预处理，或者IO到一个滞后的远程源--那么单个主线程发送文本的速度可能不如许多工作者处理文本的速度，成为限制因素。(你可以通过确保你的iteratable做尽可能少的IO或regextext-scanninglookup--比如使用内存中已经token化的语料，或者只从磁盘上读取已经token化的预处理语料，只需要在whitespacelinebreaks上进行简单的itemtoken拆分，就能在一定程度上帮助解决这个问题。)
第二种Python的 "全局解释器锁"（GIL）意味着大多数纯Python代码一次只能由一个线程运行。Gensim使用Cython的& 库代码，使大部分工作者最密集的任务在GIL瓶颈之外发生，但每个线程的控制循环& 线程间结果交接的某些方面仍然需要GIL。所以随着工作线程数量的增长，对GIL的争夺就会成为更多的限制因素--因此即使是16个以上的核心，训练吞吐量也经常在5-12个线程左右达到最大值。(一些加强训练某些方面的参数选择--如更大的向量大小或更多的负例--可以减少争夺，但可能不会改善运行时间，因为这些选项只是为更多的计算回收了争夺的时间。)
gensim的最新版本包含了另一种提供语料的方法。如果 你可以将你的语料库作为一个 单一档案 其中每个文本是 本行 满堂红 隔行如隔山. 在这种情况下，每个worker都可以在文件的范围内打开自己的视图，使他们的训练完全可以在没有GILinterthread交接的情况下进行。
要使用这种替代方法，请在您的语料库中使用 corpus_file 参数，作为文件的路径。
这个参数在 Word2Vec 类文档 和有一些更多的讨论，它的使用，在 gensim 3.6.0 版的发布说明。.
有了这个选项，一般来说，每增加一个额外的 workers 线程，最多以CPU可用核数为限。(注意，最初的一次通关词汇建设调查语料库仍然是单线程的。)