Lisp二进制大小 [英] Lisp binary size
问题描述
由于我对人工智能感兴趣，因此我最近决定尝试一下Lisp. 使用通用的Lisp编译器
As i am Interested in artificial intelligence, I recently decided to give Lisp a try. After compiling a very basic application with the common lisp compiler sbcl I noticed that the resulting binary was very big (around 43MB). I am interested of the reason for that. Is this common issue for (common) lisp and what is the technical background of this behavior?
推荐答案
Common Lisp实现中有几种不同的体系结构:
There are several different architectures in Common Lisp implementations:
- 口译员
- 字节码引擎(CLISP是示例)
- 通过C编译器进行编译(以ECL为例)
- 本机代码编译器(SBCL，LispWorks，Clozure CL)
通常，解释器和字节码引擎使用的内存量最小. CLISP因此很小. SBCL OTOH生成相对较大的本机代码.
Typically the Interpreter and the byte code engine use the smallest amount of memory. CLISP thus is very small. SBCL OTOH generates relatively large native code.
第二，创建应用程序的方法有几种:
Second, there are several different ways to create applications:
- 保存图像
- 保存优化的图像
- 编译为C代码
加上一些其他功能，例如编译为DLL.
Plus some more like compiling to DLLs.
SBCL基本上执行1.它转储包含数据和代码的内存，并包含运行时. 因此，您在运行系统中拥有的所有内容(文档，源代码链接，参数列表，符号名称，调试信息，编译器本身等)都将转储到image + runtime中.另外，SBCL生成的本机代码很大，运行时内存中可能有很多代码信息，并且SBCL包括其所有功能(包括编译器).
SBCL basically does 1. It dumps the memory containing data and code and includes the runtime. Thus everything you have in the running system (documentation, source code links, argument lists, symbol names, debug infos, the compiler itself, ...) will be dumped into the image+runtime. Additionally SBCLs generated native code is large, there is potentially a lot of code information in the runtime memory and SBCL includes all its own functionality (including the compiler).
在开发过程中，经常将这样的未优化应用程序或图像(与外部运行时)一起使用，以节省加载代码和数据的时间.我已经将它用于大于100MB的图像.
During development one often work(s/ed) with such unoptimized applications or images (with the external runtime) to save time to load code and data. I've used it myself with images which were larger than 100MB.
LispWorks执行1和2.它具有一个交付过程，您可以在其中选择性地删除内容(例如文档，某些功能，例如编译器，源引用等).这也使用了摇树器，可以删除未使用的功能.
LispWorks for example does 1 and 2. It has an delivery process where you can selectively remove stuff (like documentation, some functionality like the compiler, source references, ...). This is also using a tree-shaker, which can remove unused functionality.
优化图像还可能意味着以某种压缩方式对其进行写入，并在启动时对其进行解压缩.例如，SBCL允许这样做.
Optimizing an image could also mean to write it in some compressed way and decompressing it on start up. SBCL allows this for example.
变体3过去已经完成，但目前尚未使用(某些专用工具和应用程序除外). Thinlisp，Stella，CycL等是此类交付工具.过去也有这种工具的商业供应商(但是已经不复存在了，IIRC的最后所有者是Oracle).更新:实际上， mocl ，这是iOS和Android的最近的Common Lisp应用程序生成器.它需要Common Lisp的很大一部分，并将其编译为小型独立移动应用程序.例如，在iOS上，它为Apple提供的C编译器生成紧凑的C代码.
Variant 3 was done in the past, but is currently not in use (other than in some specialized tools and apps). Thinlisp, Stella, CycL, ... are such delivery tools. In the past there was also a commercial vendor for such a tool (but this does not exist no more, IIRC the last owner of it is/was Oracle). Update: actually mocl, a recent Common Lisp application generator for iOS and Android does it. It takes a large subset of Common Lisp and compiles it to small, stand-alone mobile apps. For example on iOS it generates compact C code for Apple's provided C compiler.
这篇关于Lisp二进制大小的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
