在Visual Studio中"multi-processor compilation"有什么缺点吗？

Are there any disadvantages to "multi-processor compilation" in Visual Studio?

本文关键字：什么 缺点 multi-processor Visual Studio compilation      更新时间：2023-10-16

在Visual Studio中为c++项目使用"多处理器编译"选项时，是否有任何缺点，副作用或其他问题我应该注意?或者，用另一种方式来表达这个问题，为什么在Visual Studio中这个选项默认是关闭的?

/MP的文档说:

不兼容的选项和语言特性
/MP选项与某些编译器选项和语言特性不兼容。如果您使用与/MP选项不兼容的编译器选项，则编译器会发出警告D9030并忽略/MP选项。如果您使用不兼容的语言特性，编译器会发出错误c2813，然后根据当前编译器警告级别选项结束或继续。
注意:
大多数选项是不兼容的，因为如果允许，并发执行的编译器会同时将它们的输出写入控制台或特定文件。其结果是，输出将混杂和乱码。在某些情况下，选项的组合会使性能变差。

它给出了一个表，列出了与/MP不兼容的编译器选项和语言特性:

  • #import预处理器指令(将类型库中的类型转换为c++类，然后将这些类写入头文件)
  • /E, /EP(将预处理器输出拷贝到标准输出(stdout))
  • /Gm(启用增量重建)
  • /showIncludes(将包含文件列表写入标准错误(stderr))
  • /Yc(写入预编译头文件)

与默认禁用其他选项(默认启用/MP)不同，Visual Studio让您手动禁用/阻止这些功能并启用/MP。

根据我们的经验，发现的主要问题有:

  1. 浏览信息由于多个项目同时调用bscmake而无法构建(现在无用的信息，因此应作为项目设置删除)
  2. 链接器由于依赖问题和构建顺序问题而失败，这是在正常构建时通常不会看到的
  3. 批处理编译没有利用多处理器编译的优势，至少在2005-2008年的VS版本中是这样的
  4. 生成关于预编译头文件不兼容的警告，这在构建stdafx时发生，可以忽略，但在进行重建时生成此消息

但是，以上是你可以解决的配置问题，否则应该启用它，因为它会加快构建速度。

因为多处理器编译与许多其他编译选项不兼容，并且对系统资源的使用也更高。这应该由开发者决定他是否值得这么做。您可以在这里找到完整的文档:http://msdn.microsoft.com/en-us/library/bb385193.aspx

虽然使用/MP会带来一些编译速度的好处，但由于工作负载的调度方式，仍然会在表上留下一些性能:https://randomascii.wordpress.com/2014/03/22/make-vc-compiles-fast-through-parallel-compilation/

编译器以"批处理"方式接收作业。(传递给编译器的一组源文件)，并且只有在前一批完成后才开始下一批。这意味着在编译最长的翻译单元之前，其他内核上有未使用的周期。编译器子进程之间不共享数据。

为了进一步提高多核的利用率，我建议切换到ninja。我已经在几个项目中实现了它，它总是一个胜利，例如https://github.com/openblack/openblack/pull/68#issuecomment-529172980

相关文章：