c++ - 使用 SSD 加快编译时间

Question

我想尝试加快 C++ 项目的编译时间。他们有大约 3M 行代码。

当然，我并不需要总是编译每个项目，但有时有很多源文件被别人修改，我需要重新编译所有的文件（例如，当有人更新ASN.1源文件时）。

我测量过编译一个中间项目（不涉及所有源文件）大约需要三分钟。我知道这并不过分，但有时等待编译真的很无聊..

我试图将源代码移动到 SSD（旧的 OCZ Vertex 3 60 GB），经过基准测试，它比 HDD 快 5 到 60 倍（尤其是在随机读/写方面）。无论如何，编译时间几乎相同（可能快 2-3 秒，但应该有机会）。

也许将 Visual Studio bin 移动到 SSD 会带来额外的性能提升？

只是为了完成这个问题：我有一个 W3520 Xeon @2.67 GHz 和 12 GB 的 DDR3 ECC。

score 28 · Accepted Answer

这在很大程度上取决于您的构建环境和其他设置。例如，在我的主编译服务器上，我有 96 GiB 的 RAM 和 16 个内核。HDD相当慢，但这并不重要，因为所有内容都缓存在RAM中。

在我的桌面上（有时我也会编译）我只有 8 Gib 的 RAM 和六个内核。在那里进行相同的并行构建可能会大大加快速度，因为并行运行的六个编译器会占用足够的内存，以使 SSD 速度差异非常明显。

影响构建时间的因素有很多，包括 CPU 与 I/O“边界”的比率。根据我的经验（Linux 上的GCC ），它们包括：

代码的复杂性。大量元模板使其使用更多 CPU 时间，更多类似 C 的代码可能使生成对象的 I/O（更多）占主导地位
临时文件的编译器设置，例如-pipeGCC。
正在使用优化。通常，优化程度越高，CPU 工作就越占主导地位。
并行构建。一次编译一个文件可能永远不会产生足够的 I/O 来使当今最慢的硬盘达到任何极限。然而，一次编译八个（或更多）内核可能会。
正在使用的操作系统/文件系统。似乎过去的一些文件系统对并行构建的许多文件的访问模式感到窒息，本质上是将 I/O 瓶颈置于文件系统代码中，而不是底层硬件。
用于缓冲的可用 RAM。操作系统缓冲 I/O 的力度越大，HDD 速度就越不重要。这就是为什么尽管有足够的空闲内核，但有时 amake -j6可能比 a 慢。make -j4

简而言之：这取决于足够多的事情来做出任何“是的，它会帮助你”或“不，它不会帮助你”的纯粹猜测，所以如果你有可能尝试一下，那就去做吧。但是不要花太多时间在它上面，每尝试将编译时间减半，试着估计一下你（或你的同事，如果你有的话）重建项目的频率，以及它与可能节省的时间。

score 12 · Accepted Answer

C++ 编译/链接受处理速度的限制，而不是 HDD I/O。这就是为什么您没有看到编译速度有任何提高的原因。（将编译器/链接器二进制文件移动到 SSD 将无济于事。当您编译一个大项目时，编译器/链接器和必要的库会被读入一次内存并留在那里。）

在编译 C 项目时，我已经看到将工作目录移动到 SSD 或 ramdisk 有一些小的加速（这比大量使用模板等的 C++ 项目花费的时间要少得多），但还不足以让它值得。

score 5 · Accepted Answer

我发现，当代码位于 SSD（具有八核Core i7、12 GB RAM的系统）上时，编译大约 100 万行 C++ 的项目的速度提高了大约两倍。实际上，我们获得的最佳性能是为系统使用一个 SSD，为源使用第二个 SSD——这并不是说构建速度快得多，而是操作系统在进行大型构建时响应速度更快。

产生巨大差异的另一件事是启用并行构建。请注意，有两个单独的选项都需要启用：

多处理器编译与其他几个标志（包括最小重建，我认为）不兼容，因此请检查输出窗口是否有警告。我发现在设置 MP 编译标志的情况下，所有内核的负载都接近 100%，因此您至少可以看到 CPU 正在被积极使用。

score 0 · Accepted Answer

没有提到的一点是，当使用ccache和高度并行的构建时，您会看到使用 SSD 的好处。

score -3 · Accepted Answer

我确实用 SSD 替换了我的硬盘驱动器，希望它能减少我的 C++ 项目的编译时间。简单地用 SSD 替换硬盘驱动器并不能解决问题，并且两者的编译时间几乎相同。

然而，在最初的失败之后，我成功地将编译速度提高了大约六倍。

执行以下步骤以提高编译速度。

5 回答 5