如何让 Windows 在编译 C++ 时像 Linux 一样快? [英] How do I get Windows to go as fast as Linux for compiling C++?
问题描述
我知道这不是一个编程问题，但它是相关的.
I know this is not so much a programming question but it is relevant.
我从事一个相当大型跨平台项目.在 Windows 上我使用 VC++ 2008.在 Linux 上我使用 gcc.项目中有大约 40k 个文件.Windows 在编译和链接同一项目时比 Linux 慢 10 到 40 倍.我该如何解决?
I work on a fairly large cross platform project. On Windows I use VC++ 2008. On Linux I use gcc. There are around 40k files in the project. Windows is 10x to 40x slower than Linux at compiling and linking the same project. How can I fix that?
单个更改增量构建在 Linux 上需要 20 秒，在 Windows 上需要 > 3 分钟.为什么?我什至可以在 Linux 中安装黄金"链接器，并将该时间缩短到 7 秒.
A single change incremental build 20 seconds on Linux and > 3 mins on Windows. Why? I can even install the 'gold' linker in Linux and get that time down to 7 seconds.
同样，git 在 Linux 上比 Windows 快 10 到 40 倍.
Similarly git is 10x to 40x faster on Linux than Windows.
在 git 情况下，git 可能不是以最佳方式使用 Windows，而是使用 VC++?您可能会认为 Microsoft 想让他们自己的开发人员尽可能高效，而更快的编译将大有帮助.也许他们试图鼓励开发人员使用 C#?
In the git case it's possible git is not using Windows in the optimal way but VC++? You'd think Microsoft would want to make their own developers as productive as possible and faster compilation would go a long way toward that. Maybe they are trying to encourage developers into C#?
作为简单的测试，找到一个有很多子文件夹的文件夹并做一个简单的
As simple test, find a folder with lots of subfolders and do a simple
dir /s > c:list.txt
在 Windows 上.执行两次并计时第二次运行，以便它从缓存中运行.将文件复制到 Linux 并执行等效的 2 次运行并为第二次运行计时.
on Windows. Do it twice and time the second run so it runs from the cache. Copy the files to Linux and do the equivalent 2 runs and time the second run.
ls -R > /tmp/list.txt
我有 2 个规格完全相同的工作站.HP Z600s，内存为 12gig，8 核，频率为 3.0ghz.在一个包含大约 400k 个文件的文件夹上，Windows 需要 40 秒，Linux 需要 <1 秒.
I have 2 workstations with the exact same specs. HP Z600s with 12gig of ram, 8 cores at 3.0ghz. On a folder with ~400k files Windows takes 40seconds, Linux takes < 1 second.
是否有我可以设置的注册表设置来加速 Windows?什么给?
Is there a registry setting I can set to speed up Windows? What gives?
一些稍微相关的链接，与编译时间相关，不一定是 i/o.
A few slightly relevant links, relevant to compile times, not necessarily i/o.
显然 Windows 10(不是 Windows 7)中存在关闭进程持有全局锁的问题.当使用多个内核进行编译并因此使用多个进程时，会出现此问题.
Apparently there's an issue in Windows 10 (not in Windows 7) that closing a process holds a global lock. When compiling with multiple cores and therefore multiple processes this issue hits.
/analysis 选项会对性能产生不利影响，因为它会加载 Web 浏览器.(这里不相关，但很高兴知道)
The /analyse option can adversely affect perf because it loads a web browser. (Not relevant here but good to know)
推荐答案
除非有一个铁杆的 Windows 系统黑客出现，否则你只会得到党派评论(我不会这样做)和猜测(这是我要尝试什么).
Unless a hardcore Windows systems hacker comes along, you're not going to get more than partisan comments (which I won't do) and speculation (which is what I'm going to try).
文件系统 - 您应该在同一个文件系统上尝试相同的操作(包括
dir).我遇到了 this，它针对各种参数对一些文件系统进行了基准测试.
File system - You should try the same operations (including the
dir) on the same filesystem. I came across this which benchmarks a few filesystems for various parameters.
缓存.我曾经尝试在 RAM 磁盘上的 Linux 上运行编译，发现由于内核处理缓存的方式，它比在磁盘上运行它慢.这是 Linux 的一个可靠卖点，可能是性能如此不同的原因.
Caching. I once tried to run a compilation on Linux on a RAM disk and found that it was slower than running it on disk thanks to the way the kernel takes care of caching. This is a solid selling point for Linux and might be the reason why the performance is so different.
Windows 上的错误依赖规范.也许 Windows 的 Chromium 依赖规范不如 Linux 正确.当您进行小的更改时，这可能会导致不必要的编译.您或许可以在 Windows 上使用相同的编译器工具链来验证这一点.
Bad dependency specifications on Windows. Maybe the chromium dependency specifications for Windows are not as correct as for Linux. This might result in unnecessary compilations when you make a small change. You might be able to validate this using the same compiler toolchain on Windows.
这篇关于如何让 Windows 在编译 C++ 时像 Linux 一样快?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
