在 Windows 上编译 Emacs 31 的完整方法

Emacs-general
22

寄，修好了

23

在 Windows 11 IOT LTSC 上成功编译最新 Emacs e5646f7。

顺便说以下，如果有人正在使用 Treemacs，当 Emacs 启动后，Treemacs 侧边栏的图标可能会变成空白方块，并报告如下错误：

ImageMagick error: NoDecodeDelegateForThisImageFormat `PNG' @ error/constitute.c/ReadImage/562

快速搜索后，找到一个临时解决方法。

在 MSYS2 的 UCRT64 bash 中执行如下命令：

$ export MAGICK_HOME="/ucrt64/bin"
$ export MAGICK_CONFIGURE_PATH="/ucrt64/etc/ImageMagick-7"
$ export MAGICK_CODER_MODULE_PATH="/ucrt64/lib/ImageMagick-7.1.1/modules-Q16HDRI/coders"
$ ./runemacs

然后 .emacs.d 目录需要放在 C:/msys64/home/${USER}/ 下。

Refs: syl20bnr/spacemacs#15404 msys2/MINGW-packages#1885

24

-j16 是有用的，但好像只对 CC 有用。ELN 有时候确实会用满所有核心（一下子打印出很多 eln TaskManager 瞬间全蓝了 100%），有时有好像变成单核编译了。不是很清楚 ELN 底层到底有没有跑多核，挺奇怪的ELN 是有跑多核的，但是是一波一波的，并非在任意一个时间点均保持满载。

25

测试了一下多核编译 Emacs，做一下记录：

  • 单核编译

    make clean
make

    耗时非常长，超过 1 个小时（没精确计算）。

  • make -j16，关 Real-time protection

    make clean
make -j16

    耗时 297.255586100 seconds 约 4.9 分钟

  • make -j32，关 Real-time protection

    make clean
make -j32

    耗时 289.304513900 seconds 约 4.8 分钟

  • make -j33，关 Real-time protection

    make clean
make -j33

    耗时 285.129789200 seconds 约 4.75 分钟

  • make -j33，开 Real-time protection

    make clean
make -j33

    耗时 402.939011100 seconds 约 6.7 分钟

  • make -j48，关 Real-time protection

    make clean
make -j48

    耗时 568.440613100 seconds 约 9.47 分钟

  • make -j64 ，关 Real-time protection

    make clean
make -j64

    耗时 701.123747300 seconds 约 11.68 分钟

  • make -j64，开 Real-time protection（默认）

    make clean
make -j64

    耗时 736.384229200 seconds 约 12.27 分钟

结论：

  1. N 设为 “物理核心数 + 1” 为最佳，符合 stackoverflow 上的的说法 。
    • 此时 Real-time protection 占大约 30% 的影响。
  2. N 设为更大的值（即：使用 48 或 64 个逻辑核）并不能提升速度，反而拖慢速度。
  3. 仅考虑编译 Emacs，16 个物理核已经足够，更多物理核的性价比不高。

环境：

EPYC 7543 (32 核 64 线程)，BIOS Determinism = Power，其他保持默认

8 x 64GB RAM 2666

Samsung 990 EVO Plus 2T

Windows 11 IoT LTSC

MSYS64 UCRT

3 个赞