lisp - Lisp 二进制大小

Question

由于我对人工智能很感兴趣，所以我最近决定尝试一下 Lisp。在使用通用 lisp 编译器sbcl编译了一个非常基本的应用程序后，我注意到生成的二进制文件非常大（大约 43MB）。我对此的原因很感兴趣。这是（常见）lisp 的常见问题吗？这种行为的技术背景是什么？

Answer 1

Common Lisp 实现中有几种不同的架构：

• 口译员
• 字节码引擎（CLISP 就是一个例子）
• 通过 C 编译器编译（ECL 就是一个例子）
• 本机代码编译器（SBCL、LispWorks、Clozure CL）

通常解释器和字节码引擎使用最少的内存。因此 CLISP 非常小。SBCL OTOH 生成相对较大的本机代码。

其次，有几种不同的方式来创建应用程序：

1. 保存图像
2. 保存优化的图像
3. 编译成 C 代码

加上一些更像是编译为 DLL。

SBCL 基本上做了 1. 它转储包含数据和代码的内存并包含运行时。因此，您在运行系统中的所有内容（文档、源代码链接、参数列表、符号名称、调试信息、编译器本身……）都将转储到映像+运行时。此外，SBCL 生成的本机代码很大，运行时内存中可能存在大量代码信息，并且 SBCL 包含其所有自己的功能（包括编译器）。

在开发过程中，经常使用此类未优化的应用程序或图像（使用外部运行时）来节省加载代码和数据的时间。我自己使用过大于 100MB 的图像。

例如，LispWorks 做了 1 和 2。它有一个交付过程，您可以在其中有选择地删除内容（如文档、编译器等某些功能、源代码引用等）。这也使用了 tree-shaker，它可以删除未使用的功能。

优化图像也可能意味着以某种压缩方式编写它并在启动时对其进行解压缩。例如，SBCL 允许这样做。

变体 3 过去已完成，但目前未使用（某些专用工具和应用程序除外）。Thinlisp、Stella、CycL……就是这样的交付工具。过去也有此类工具的商业供应商（但这已不复存在，IIRC 的最后所有者是/曾经是 Oracle）。更新：实际上mocl是一个最新的 iOS 和 Android 通用 Lisp 应用程序生成器。它采用 Common Lisp 的一个大子集并将其编译为小型的独立移动应用程序。例如，在 iOS 上，它为 Apple 提供的 C 编译器生成紧凑的 C 代码。