加速嵌入式linux编译过程答案

【问题标题】：Speed up embedded linux compilation process加速嵌入式linux编译过程
【发布时间】：2021-10-10 10:07:27
【问题描述】：

有一个用于定制硬件的嵌入式 linux (OpenWrt) 项目。内核或应用程序的任何更改都需要重新编译完整的映像或应用程序。并且重新编译非常缓慢。为了减轻这种痛苦，购买了基于 AMD Threadripper 3970X 的工作站，配备 128Gb RAM 和 1Tb SSD。此 CPU 的测试台显示 120 秒的 linux 内核编译时间。但我的编译时间更长。

第一次完整图像编译减少：

到：

重复图像编译减少：

至：

包重新编译 ($ time make package/tensorflow/compile) 减少自：

到：

例如编译时间减少了 2-7 倍。在第一次图像编译期间，所有必要的源代码都需要从网络上下载。我有快速的以太网（100Mb/s）连接，而不是腰部时间。我使用 RAMDISK：

$ sudo mkdir /mnt/ramdisk  
$ sudo mount -t tmpfs -o rw,size=64G tmpfs /mnt/ramdisk

存储所有源、对象和临时文件，因此我相信不会丢失 IO。

make -j64 用来编译它。我看到编译期间很少加载所有 64 个内核：

我主要看到以下内容：

甚至这个：

所以我无法相信无法实现更快的编译。有人可以给我提示/建议如何加快 GCC C/C++ 交叉编译过程。一些搜索将我指向 distcc 和 Parallel GCC，但我没有这方面的经验，所以不确定这是否是我需要的，因为 OpenWrt has almost nothing 在他们的手册中解释了如何加快构建过程。

【问题讨论】：

如果不自己完成整个练习，这是一个很难回答的问题。您能否向我们展示在 CPU 使用率较低的情况下正在运行的构建过程的示例？
如果您的大部分更改都是本地化的，您可能应该查看Ccache。它从缓存中获取以前编译的二进制文件，如果这些文件应该没有改变（即相同的编译器、标志、源和包含，预处理后可能相同）。
“快速以太网”确实是个坏名字。之所以这样命名，是为了将其与以 0.01 Gbit/s 运行的第一代产品区分开来。但即使是“快速以太网”也只有 0.1 Gbit/s；今天，最低限度是 1 Gbit/s。 10Gbit/s 很容易获得。
一个非常敏锐的例子，说明为什么不应该在问题中发布图片。每一个对我来说都是死的，我不打算点击所有这些。由于项目编译方式的依赖性，利用 64 个线程/内核/任何东西可能是不可能的。如果 Y 需要 X，则 Y 无法与 X 并行编译。在 ccache 之后，您可以尝试将编译模块化的痛苦过程，以便更多单元独立，或者如果可能的话至少减少依赖树的深度。
安装ccache。它加快了许多二次构建。

标签： performance embedded-linux cross-compiling openwrt

【解决方案1】：

在linux中，有增量构建的概念，所以第一次构建需要时间，但下次只需要构建更改或额外添加的部分。无需重建一切。在这种情况下，构建会更快。

不会一直加载 CPU 的所有内核。这取决于当前正在运行的任务数量。假设在您的系统中，有 8 个内核，但只有 6 个任务在运行。在这种情况下，所有核心都不会完全加载。

【讨论】：

你所描述的并不是 Linux 独有的。