Lispバイナリサイズ

Question

私は人工知能に興味があるので、最近Lispに試してみることに決めました。 普通のlispコンパイラsbclを使って非常にbasic applicationをコンパイルした後、結果のバイナリが非常に大きかった（約43MB）ことに気付きました。 私はその理由に興味があります。この共通の問題は（共通の）lispであり、この動作の技術的背景は何ですか？

Answer 1

Common Lispの実装では、いくつかの異なるアーキテクチャがある：

• インタプリタ
• バイトコードエンジンはCコンパイラを介し
• コンパイル（CLISPは例である）
• （ECLは一例です）ネイティブコードコンパイラ（SBCL、LispWorks、Clozure CL）

通常、インタープリターとバイトコードeエンジンは最小量のメモリを使用します。したがって、CLISPは非常に小さい。 SBCL OTOHは、比較的大きなネイティブコードを生成します。

第二には、アプリケーションを作成するには、いくつかの異なる方法があります：Cコードに

プラスもう少しなどをコンパイルする最適化された画像

画像保存

を保存

1. DLLにコンパイルする。

   SBCLは基本的に1です。データとコードを含むメモリをダンプし、ランタイムを含みます。 実行中のシステム（ドキュメント、ソースコードリンク、引数リスト、シンボル名、デバッグ情報、コンパイラ自体など）にあるすべてのものは、イメージ+ランタイムにダンプされます。さらに、ネイティブコードが生成されたSBCLは大きく、ランタイムメモリに潜在的に多くのコード情報があり、SBCLにはすべての独自の機能（コンパイラを含む）が含まれています。

   開発中に、最適化されていないアプリケーションやイメージ（外部ランタイム）を使用すると、コードやデータを読み込む時間を節約できます。私は100MB以上の画像でそれを使ってきました。

   たとえば、LispWorksは1と2を実行します。ドキュメント（コンパイラのようないくつかの機能、ソース参照など）を選択的に削除する配信プロセスがあります。これはツリーシェーカーを使用しており、未使用の機能を削除できます。

   画像を最適化すると、圧縮された方法で書き込んで、起動時に復元することもできます。 SBCLは、これを例えば許可します。

   バリアント3は過去に行われましたが、現在は使用されていません（一部の特殊なツールやアプリでは使用されていません）。 Thinlisp、Stella、CycL、...はそのような配送ツールです。過去には、そのようなツールの商用ベンダーもいました（これはもう存在しません。IIRCの最後の所有者はOracleです）。アップデート：実際にはmocl、最近のCommon LispアプリケーションジェネレータiOSとAndroid用です。これは、Common Lispの大きなサブセットを取り、小型のスタンドアローンのモバイルアプリにコンパイルします。たとえばiOS上では、Appleの提供するCコンパイラ用のコンパクトなCコードを生成します。