使用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.

Answer 1

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

在我的桌面上(我有时也编译)我只有8个内存和六个内核.进行相同的并行构建可能会大大加快,因为并行运行的六个编译器会占用足够的内存,因此SSD的速度差异非常明显.

有许多因素会影响构建时间,包括CPU与I/O"绑定"的比率.根据我的经验(Linux上的GCC),它们包括:

代码的复杂性.大量的metatemplates使得它使用更多的CPU时间,更多类似C的代码可能使生成的对象的I/O(更多)占主导地位
临时文件的编译器设置,例如-pipeGCC.
使用优化.通常,优化程度越高,CPU工作占主导地位.
并行构建.一次编译一个文件可能永远不会产生足够的I/O来获得今天最慢的硬盘到任何限制.然而,可能同时使用八个核心(或更多)进行编译.
正在使用的OS /文件系统.似乎过去的一些文件系统已经扼杀了并行构建的许多文件的访问模式,实质上是将I/O瓶颈放入文件系统代码而不是底层硬件.
可用于缓冲的RAM.操作系统可以更积极地缓冲I/O,硬盘速度越不重要.这就是为什么有时候a 尽管有足够的空闲内核但make -j6可能比a慢make -j4.

简而言之:它取决于足够的东西来制造任何"是的,它会帮助你"或"不,它会帮助你"纯粹的猜测,所以如果你有可能试一试,那就去做吧.但是不要花太多时间在上面,因为你试图将编译时间缩短到一半,试着估计你(或你的同事,如果你有的话)可以重建项目的频率,以及它与节省了可能的时间.

Answer 2

C++编译/链接受处理速度的限制,而不受HDD I/O的限制.这就是为什么你没有看到编译速度的任何增加.(将编译器/链接器二进制文件移动到SSD将不会执行任何操作.编译大型项目时,编译器/链接器和必要的库将被读入内存一次并保留在那里.)

在编译C项目时,我已经看到了将工作目录移动到SSD或ramdisk的一些小的加速(这比使用大量模板等的C++项目耗时少得多),但还不足以让它值得.

开启优化后,处理速度非常重要(差异大约为10%),但在非优化版本中,SSD确实比硬盘快3-4倍.当然,编译器放置中间文件的临时文件目录也应该在SSD上.然后,磁盘当然必须支持修剪,否则这是一个非常短的旅程. (5认同)
@Dave这可能已经尝试过,但编译过程中决策过程非常繁重,因此涉及大量的分支和相互依赖性.它不能很好地扩展到许多"哑"核心,这对于本质上并行的任务来说非常出色. (3认同)
这一切都很大程度上取决于您的构建环境和其他设置.例如,在我的主编译服务器上,我有96GiB的RAM和16个内核.hdd相当慢,但这并不重要,因为所有内容都缓存在RAM中.在我的桌面上(我有时也编译)我只有8Gib的ram和6个核心.做同样的并行构建可能会大大加快,因为并行运行的6个编译器占用了足够的内存,因为ssd速度差异非常明显. (2认同)
多长时间才有人制作使用GPU和CPU的编译器 (2认同)

Answer 3

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

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

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