从RAM驱动器构建真的可以提高速度吗？

Question

我正在做一个有数千个的项目。cpp文件加上数千个。h和。hpp，从SSD运行构建需要28分钟。

我们几周前从另一家公司继承了这个项目，但是仔细阅读makefile，他们通过明确地禁用了并行构建。不平行假目标；我们想知道他们是否有充分的理由。

最坏的情况下，唯一的加速方法是使用RAM驱动器。

因此，我按照Tekrevue的说明安装了Imdisk，然后使用CrystalDiskMark运行基准测试：

我还使用Cygwin运行了dd，与我的SSD相比，RAM驱动器的速度有了显著提高（至少3倍）。

然而，我的构建时间没有改变一分钟！

然后我想：也许我的专有编译器调用了一些视窗应用编程接口，导致了巨大的减速，所以我在Cygwin上从源代码构建了fftw。

我所期望的是，我的处理器使用率将增加到某个最大值，并在构建期间保持在该值。相反，我的用法非常尖刻：编译的每个文件一个。我知道即使是Cygwin也必须与windows交互，因此我仍然使用尖利的proc，这让我认为问题不在于我的编译器。

好的。新理论：在Windows中为每个源文件调用编译器有一些巨大的开销，所以我从我的构建日志中复制粘贴并将45个文件传递给我的编译器，并将其与单独调用编译器45次进行比较。调用ONCE更快，但45个文件总共只有4秒。我看到了与为每个文件调用一次编译器时相同的“尖刺”处理器用法。

为什么即使从RAM驱动器运行，我也不能让编译器运行得更快？开销是多少？

更新#1评论者一直在说，我认为，内存驱动器是一种不必要的bc窗口将输入和输出文件缓存在内存中。另外，也许RAM驱动器实现（即驱动器）是次优的。所以，我不再使用内存驱动器了。

另外，人们说我应该多次运行45文件构建，以消除缓存的开销：我运行了4次，每次都是52秒。

问：既然一切都在内存中，为什么CPU%没有更多的时间更高？我能做些什么来使单线程/作业构建更快吗？请记住，目前这是单线程构建）

UPDATE 2下面有人建议，我应该将编译45文件调用的亲和力设置为1，这样窗口就不会在调用时反弹到多个核心。结果：

所以瓶颈不是硬盘、内存或缓存，而是中央处理器。

**谢谢大家！感谢你的帮助

========================================================================

我的机器：英特尔i7-4710MQ@2.5GHz，16GB内存

Answer 1

您的跟踪显示23%的CPU使用率。您的CPU有4个实际内核（通过超线程使其看起来像8个）。所以，你只使用了一个核心到它的绝对最大值（正负2%，这可能比你预期的精度更好）。

由此得出的明显结论是，构建过程受CPU限制，因此提高磁盘速度不太可能产生多大影响。

如果您想要更快的构建，您需要找出当前makefile的问题所在，或者在没有问题的情况下编写全新的makefile，这样您就可以支持部分和并行构建。

那可以让你收获很多。本质上，你所做的任何其他事情（加速磁盘、超频CPU等）。）充其量只会带来微小的收益（如果你真的很幸运，也许20%，一个合适的构建环境可能会给大多数典型的构建带来至少20:1的改进）。

Answer 2

从驱动器读取源代码是编译软件开销中非常非常小的一部分。由于解析和生成二进制文件是这个过程中最慢的部分，因此CPU速度要相关得多。

**更新您的图形显示一个非常繁忙的CPU，我不知道你希望看到什么。除非构建是多线程的，并且您的内核停止调度其他不太密集的线程，否则这肯定是繁忙处理器的图表。

Answer 3

我不明白你为什么要责怪操作系统，除了顺序、愚蠢的IO（加载源代码/保存中间输出——这应该通过看到固态硬盘和内存盘执行相同的操作来排除）和进程启动（通过编译单个IO来排除巨型文件）编译器和操作系统之间几乎没有交互。

现在，一旦你排除了“磁盘”和处理器，我预计瓶颈是内存速度——不是内存磁盘IO部分（可能已经被固态硬盘饱和了），而是编译过程本身。

这实际上是一个很常见的问题，目前处理器的速度通常比内存快，而内存往往是瓶颈（这就是为什么目前编写缓存友好型代码至关重要的原因）。处理器可能会浪费大量时间等待从主内存中提取缓存外数据。

无论如何，这都是猜测。如果你想要一个可靠的答案，像往常一样，你必须要有个人资料。从这样的列表中抓取一些采样分析器，看看编译器在哪里浪费时间。就我个人而言，我希望看到大量的缓存未命中（如果您为ramdisk烧掉了太多的RAM，甚至会出现页面错误），但任何情况都可能发生。