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

C++ 从RAM驱动器构建真的可以提高速度吗?,c++,windows,performance,makefile,C++,Windows,Performance,Makefile,我正在从事一个项目,该项目有数千个.cpp文件,还有数千个.h和.hpp文件,从SSD运行构建需要28分钟 我们几周前从另一家公司继承了这个项目,但仔细阅读makefile,他们通过.NOPARALLEL虚假目标明确禁用了并行构建;我们想知道他们是否有充分的理由 最坏的情况下,唯一的加速方法是使用RAM驱动器 因此,我按照中的说明进行安装,然后使用以下工具运行基准测试: 固态硬盘 RAM驱动器 我还使用Cygwin运行了dd,与我的SSD相比,RAM驱动器的速度有了显著提高(至少3倍) 但是,我

我正在从事一个项目,该项目有数千个
.cpp
文件,还有数千个
.h
.hpp
文件,从SSD运行构建需要28分钟

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

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

因此,我按照中的说明进行安装,然后使用以下工具运行基准测试:

固态硬盘 RAM驱动器

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

但是,我的构建时间不会改变一分钟

于是我想:也许我的专有编译器调用了一些Windows API,导致了速度的大幅下降,所以我在Cygwin上从源代码构建了fftw

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

嗯。新理论:在Windows中为每个源文件调用编译器有一些巨大的开销,因此,我从构建日志中复制粘贴,并将45个文件传递给编译器,并将其与分别调用编译器45次进行比较。调用一次更快,但对于45个文件,总共只调用了4秒。 我看到了与为每个文件调用一次编译器时相同的“尖头”处理器用法

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

更新#1 我认为,评论人士一直在说,RAM驱动器是一种不必要的东西。无论如何,bc windows都会将输入和输出文件缓存在RAM中。 另外,可能RAM驱动器实现(即驱动程序)是次优的。 所以,我不再使用RAM驱动器了

另外,人们说我应该多次运行45文件构建,以消除缓存开销:我运行了4次,每次运行时间52秒

CPU使用率(编译结束前5秒)

虚拟内存使用 当编译器将内容输出到磁盘时,它实际上首先缓存在RAM中,对吗? 那么这个屏幕截图表明IO不是一个问题,或者更确切地说,它和我的RAM一样快

问题: 既然所有的东西都在RAM中,为什么CPU在更多的时间里没有提高%? 我能做些什么来加快单线程/作业的构建速度吗? (请记住,目前这是单线程构建)

更新2 下面有人建议我应该将compile-45-files调用的affinity设置为1,这样windows就不会在调用多个内核时跳转。 结果是:

100%单核使用率!对于相同的52秒

因此,瓶颈不是硬盘、RAM或缓存,而是CPU

**谢谢大家!**谢谢你的帮助

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


我的机器:英特尔i7-4710MQ@2.5GHz,16GB内存从驱动器读取源代码只占编译软件开销的一小部分。由于解析和生成二进制文件是这个过程中最慢的部分,因此CPU速度要相关得多

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

除了顺序、哑IO(加载源代码/保存中间输出-应该通过SSD和RAM磁盘执行相同的操作来排除)和进程启动(通过编译单个巨型文件来排除)之外,我不明白你为什么还要如此指责操作系统编译器和操作系统之间的交互很少

现在,一旦排除了“磁盘”和处理器,我认为瓶颈是内存速度——不是RAM磁盘IO部分(可能已经被SSD饱和),而是编译过程本身

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


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

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

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

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

这会给你带来很多好处。基本上,您所做的任何其他事情(加速磁盘、超频CPU等)最多只会带来一些小的收益(如果您真的幸运的话,可能会有20%,而适当的构建环境可能会带来小的收益)