14

私は人工知能に興味があるので、最近 Lisp を試してみることにしました。一般的な Lisp コンパイラsbclを使用して非常に基本的なアプリケーションをコンパイルした後、結果のバイナリが非常に大きい (約 43MB) ことに気付きました。その理由に興味があります。これは (一般的な) Lisp の一般的な問題であり、この動作の技術的背景は何ですか?

4

1 に答える 1

29

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 を行います。LispWorks には、(ドキュメント、コンパイラなどの一部の機能、ソース参照などのような) ものを選択的に削除できる配信プロセスがあります。これは、未使用の機能を削除できるツリーシェーカーも使用しています。

画像を最適化するということは、画像を何らかの圧縮方法で書き込んで、起動時に解凍することを意味する場合もあります。たとえば、SBCL ではこれが可能です。

バリアント 3 は過去に行われましたが、現在は使用されていません (一部の専用ツールとアプリを除く)。Thinlisp、Stella、CycL などは、そのような配信ツールです。過去には、そのようなツールの商用ベンダーもありました (しかし、これはもはや存在しません。IIRC の最後の所有者は Oracle です/Oracle でした)。更新: 実際には、iOS および Android 用の最近の Common Lisp アプリケーション ジェネレーターであるmoclがそれを行います。Common Lisp の大部分を取り込んで、小さなスタンドアロンのモバイル アプリにコンパイルします。たとえば、iOS では、Apple が提供する C コンパイラ用のコンパクトな C コードを生成します。

于 2012-06-14T15:39:02.733 に答える