在编译期间估计相对 CPU 使用率

Posted 2023-02-22

【中文标题】在编译期间估计相对 CPU 使用率

【英文标题】：Estimating relative CPU usage during compilation

【发布时间】：2009-03-18 10:23:19

【问题描述】：

今天早上编译的时候我有个想法。

给定一台专用的 Linux 机器（例如运行 Fedora），用户远程登录并编译（使用 gcc）他们的 c++ 软件，该软件存储在他们自己的机器上（在一个小型 LAN 上），通过符号链接链接到Linux 盒子。

假设现在每个用户都在编译完全相同的代码... 一位用户可以在 10 分钟内编译和链接他的代码。

是否需要 2 个用户共 20 分钟才能同时编译 3 或 10 个用户呢？

是否存在随着用户增加而导致收益递减的开销？

作为一个额外的问题 - 在此设置中您有哪些提高编译效率的技巧？

【参考方案1】：

我建议distcc。

【讨论】：

我正在使用 distcc3 进行编译。在我的新开发工作站到来之前，我正在使用 Windows 机器上的全屏虚拟机。为了加快速度，我在办公桌下的两台 P4 Dell Optiplex 上安装了 distcc，否则它们大部分时间都处于闲置状态，我对结果非常满意。

【参考方案2】：

根据项目源的大小，保存可能是在编译之前将所有文件本地复制到构建机器。如果编译器必须根据需要通过网络拉取所有文件，这将引入一些开销，因为网络访问比磁盘访问慢很多。

如果您编写脚本或使用仅将修改后的文件复制到构建机器的工具，那么开销将大大减少。在这种情况下，构建机器基本上会保留源文件的本地镜像，每次编译时，它都会更新任何修改过的文件，然后编译。显然，如果您有很多用户和/或大型项目文件，那么您会遇到存储/空间问题。

【参考方案3】：

由于以下原因，总会产生开销：

调度需求 时间冲突的 I/O 操作

最后一个对您来说是最重要的，因为网络访问比磁盘访问慢得多。预缓存（首先在本地获取所有文件，然后开始编译）可能会有所帮助。已经开始的构建不会受到新的并发用户的阻碍。

【讨论】：

那么预缓存然后启动的构建不会受到新构建连接、预缓存然后同时启动的影响？

它不会受到新版本预缓存的严重影响。但是，它将受到新版本的 CPU 使用率的影响。这个想法是 CPU 使用率不会因为 IO 等待而下降。

【参考方案4】：

编译主要受 CPU 限制，因此假设您有足够的 RAM，您可以预期编译时间大致为（每个任务的时间）*（任务数）/（系统中的 CPU/内核数）。 （奇怪的是，我在我的一个项目的 3 核系统上运行了“make -j”，并且速度提高了 3 倍以上，因此可能存在某种阻塞问题，阻止了顺序 make 全速运行。）

为什么用户不在自己的电脑上编译他们的程序？

【讨论】：

我们编写多平台代码，所以我们使用windows在本地构建，并且只有在我们每个人都准备好部署/测试的构建时才在目标linux机器上编译