是否可以加快./configure？

29

要编译许多CPU核心（说12）工作站上的软件包，配置阶段往往需要更长的时间比实际编译阶段，因为./configure做测试一个接一个，而make -j运行gcc以及其他命令并行。

我觉得剩下的11个内核在大多数情况下都等待空闲时间./configure来完成，这是对资源的巨大浪费。为什么需要按顺序进行测试？每个测试是否相互依赖？我可能会误会，但看起来其中大多数是独立的。

更重要的是，有什么方法可以加快速度./configure吗？

编辑：为了说明这种情况，这是GNU Coreutils的示例

cd /dev/shm
rm -rf coreutils-8.9
tar -xzf coreutils-8.9.tar.gz
cd coreutils-8.9
time ./configure
time make -j24

结果：

# For `time ./configure`
real    4m39.662s
user    0m26.670s
sys     4m30.495s
# For `time make -j24`
real    0m42.085s
user    2m35.113s
sys     6m15.050s

使用coreutils-8.9，./configure所需时间是的6倍make。尽管./configure使用的CPU时间更少（请查看“用户”和“ sys”时间），但由于没有并行化，因此它会花费更长的时间（“实际”）。我已经重复测试几次（相关文件可能保留在内存缓存中），并且时间在10％以内。

— 网络电话
source

4

没有好的构建工具是可笑的，也是可耻的。存在的所有存在纯粹是由于惯性。构建二进制文件是一件如此奇怪，不可预测的事情。

— 马特·乔纳

它按顺序进行测试，因为要找出如何在正在运行的特定系统上进行并行化是一个噩梦。

— Simon Richter

13

我回想起大约10年前Autoconf邮件列表上有关此问题的讨论，当时大多数人实际上只有一个CPU内核。但是什么也没做，我怀疑什么也做不了。很难在中为并行处理设置所有依赖项configure，并以可移植且健壮的方式来进行处理。

根据您的特定情况，可能仍然有几种方法可以加快配置运行速度。例如：

使用更快的外壳。例如，考虑使用dash而不是bashas /bin/sh。（注意：在Debian下，dash已对其进行了修补，因此configure不使用它，因为使用它会破坏很多configure脚本。）
如果您远程运行构建（例如通过ssh），那么我发现控制台输出可能会很慢。考虑致电configure -q。
如果您反复构建同一项目，请考虑使用缓存文件。致电configure -C。有关详细信息，请参见Autoconf文档。
如果您构建许多其他项目，请考虑使用站点文件（config.site）。同样，请参阅文档。
并行构建多个项目。

— 彼得·艾森特劳特
source

2

您能否再解释一下为什么make可以并行化configure还是autoconf不能并行化？

— netvope 2011年

看来我的外壳有些性能问题。sh -c "echo $i" > /dev/null在此系统上运行1000次大约需要10秒钟，而在其他系统上只需要1-2秒钟。

— netvope 2011年

1

GNU make使用相当复杂的C代码来启动和管理多个进程。配置脚本是在可移植的Bourne Shell中编写的。可能，但可能非常困难。

— Peter Eisentraut 2011年

4

整理configure测试之间的依存关系实际上是一种低复杂度的操作（拓扑排序），并且在计算的早期就已解决。真正的问题是，没有人愿意将代码添加到autoconf中来执行此操作，而且许多程序员手动修改了生成的文件。应该对整个系统进行改造，以使配置不再由Shell脚本执行，而是由驻留二进制文件读取元数据文件完成。

— billc.cn 2011年

1

请在邮件列表（指向档案的链接）上添加对上述讨论的引用。

— Karl Richter

3

您已经很聪明地使用ramdrive将源码树驻留在其中，但是请三思而后行-configure的作用是什么？它不仅通过检查您的sourcetree来完成其工作，而且还经常检查系统中库，编译器等的可用性。在这种情况下，访问问题有时存在于磁盘访问中-如果您需要，可以更快地完成访问。基于SSD的根文件系统的示例。

— 布布
source

1

不幸的是，SSD似乎无济于事。我尝试./configure反复运行，但随后的运行几乎与第一次运行一样长。由于系统中有很多可用内存，因此我认为系统正在运行内存缓存中的编译器和库，而无需访问磁盘。

— netvope

1

如果您尝试重复运行./configure（并且它是由autoconf进行的），则应将所有结果缓存起来，并且效果很好。如果您需要更多帮助，可以发布配置脚本供我们查看。我非常确定这里有很多上师

— bubu

我实际上在两次运行之间对其进行了清理（./configure始终在新提取的源树中运行）。我将在原始帖子中添加更多详细信息（此处的空间有限）。

— netvope 2011年

我只是在不清理文件夹的情况下进行了测试（即./configure立即运行另一个./configure），并且两次运行大约花费相同的时间。这是否意味着缓存可能无法在我的系统上正常工作？

— netvope 2011年

我将获取coreutils并尝试在有时间的时候进行配置。敬请关注。

— bubu

3

如果您使用的是ondemand cpu调控器，请尝试使用性能控制器。这对i7和a8-3850的帮助为40-50％。在q9300上并没有太大的区别。

在四核CPU上，您可能会做

for cpu in `seq 0 3`; do sudo cpufreq-set -g performance -c $cpu; done

（-r选项应该可以使您不必为每个内核进行cpufreq-set设置，但是在我的计算机上它不起作用。）

缓存选项可以提供更多帮助。

— 丹·凯格尔
source

3

./configure脚本有很多类型。有很多流行的工具（autconf是其中的一种）可以帮助开发人员创建./configure脚本，但是没有规则说每个开发人员都必须使用这些工具，然后即使在这些工具中，这些脚本的方式也可能存在很大差异。被构造。

我不知道./configure可以并行运行的任何流行脚本。由流行工具构建的大多数脚本至少会缓存其部分或全部结果，因此，如果再次运行它（make clean无论如何都无需先执行），则第二次运行速度会更快。

这并不是说无法完成...但是我怀疑autoconf，例如，对于大多数工作人员，这样做的动机很少，因为对于大多数软件包而言，配置阶段相对于实际的编译和链接而言是非常快的阶段。

— 脆弱的
source

2

但是，使用这些工具有一个很好的理由：它们已经成熟，并且可以跟踪许多微小的细节。我认为，如果您不能简单地将configure脚本指向您的交叉编译器并使它有90％的可能性可以立即使用，那么Linux在嵌入式世界中的地位将不高。

— Simon Richter

2

在这种情况下，硬盘驱动器是瓶颈。为了加快构建速度，请在具有快速驱动器的系统上构建（阅读：访问时间短）。关于SSD光盘，有很多大惊小怪的地方，但是有人批评它们不会以积极的方式影响编译时间。也就是说，在SSD上构建并没有比在不错的SATA驱动器上构建快得多。我不记得我在哪里读这篇文章，因为这篇文章已有两年了。

无论如何... Untar撞击并从那里建造。

mkdir /tmp/tmp 
mount -t tmpfs -o size=400M tmpfs /tmp/tmp 
cd /tmp/tmp
tar xjf somesourcetarball-1.1.33.tar.bz2

— ЯрославРахматуллин
source

1

谢谢，但是我已经在/ dev / shm上编译了，这是一个tmpfs :-)

— netvope 2011年

0

由于我们有十几个具有（相当）低单核性能的CPU，因此您的问题在今天甚至可能更加重要。持续集成（CI）的自动化构建确实会为每次提交浪费大量CPU时间/精力。与分支之间的跳跃相同。

因此，请在https://gitlab.com/gnuwget/wget2/wikis/Developer-hints:-Increasing-speed-of-GNU-toolchain上查看/阅读有关加速操作的提示。

“为什么它需要按顺序进行测试？……”实际上，可以并行完成一些操作，而其他一些则必须按顺序进行。有几件事取决于构建环境-配置脚本本身与系统无关。它甚至不包含bashisms，因此它可用于纯POSIX shell。

如果您要编写可移植的软件，则没有其他构建系统（如自动工具）。但是，如果您不介意（广泛）的可移植性，请避免使用自动工具-那里有大量快速而完善的构建工具。

— 蒂姆·鲁森Rockdaboot
source