ジュリアは毎回スクリプトをコンパイルしますか？
Julia言語は毎回スクリプトをコンパイルしますが、代わりにJuliaでバイナリをコンパイルできませんか？ Juliaが出力を表示するのに2,3秒かかったprintln関数を使用した小さなhelloworldスクリプトを試しました！毎回コンパイルするのではなく、バイナリを作れるほうがいいです
更新：この質問をして以来、ジュリアにはいくつかの変更がありました。 Juliaの更新についてはもうフォローしていませんが、この質問をしたので、似たようなものを探している場合は、Juliaをフォローしているユーザーによる以下の回答とコメントを確認してください。
また、スクリプトの読み込みに約150ミリ秒かかることを知っておくと便利です。
現在、Julia JITは起動時に標準ライブラリ全体をコンパイルしています。私たちは状況を認識しており、現在LLVM JIT出力のキャッシュに取り組んで状況を改善していますが、それまでは（REPLを使用する場合を除いて）回避策はありません。
キノの答えは正解ですが、何が起こっているのか、それについて何を計画しているのかについて、もう少し詳しく説明できます。
現在、LLVM JITモードのみがあります。
- いくつかの単純なトップレベルのステートメントには非常に簡単なインタープリターがあります。
- 他のすべてのコードは、実行前にマシンコードに変換されます。コードは、コードが適用されているランタイム型の値を使用して積極的に特殊化され、動的型推論を使用してプログラムを通じて伝播されます。
これが、タイプアノテーションなしでコードが記述されている場合でもJuliaが優れたパフォーマンスを得る方法です。f(1)を呼び出すと、_Int64_に特化したコードが得られます— 64ビットシステムでの_1_のタイプ; f(1.0)を呼び出すと、_Float64_（すべてのシステムでの_1.0_のタイプ）に特化した新しくバージョンが取得されます。関数のコンパイルされた各バージョンは、取得する型を認識しているため、Cのような速度で実行できます。これを妨害するには、型ではなく実行時データに依存する戻り型を持つ「type-unstable」関数を作成して使用しますが、コア言語と標準ライブラリの設計ではそうしないように細心の注意を払っています。
Juliaのほとんどはそれ自体で記述され、解析、型推論、およびjit処理されるため、システム全体を最初からブートストラップするには15〜20秒かかります。それをより速くするために、解析し、型推論し、型推論されたASTのシリアル化されたバージョンをファイル_sys.ji_にキャッシュする段階的なシステムがあります。次に、このファイルがロードされ、Juliaの実行時にシステムを実行するために使用されます。ただし、LLVMコードまたはマシンコードは_sys.ji_にキャッシュされないため、Juliaが起動するたびにすべてのLLVMジッターを実行する必要があるため、約2秒かかります。
この2秒の起動遅延は非常に煩わしく、修正する計画があります。基本的な計画は、Juliaプログラム全体をバイナリにコンパイルできるようにすることです。実行可能な実行可能ファイル、または単に共有Cライブラリであるかのように他のプログラムから呼び出すことができる_.so_/_.dylib_共有ライブラリのいずれかです。 。バイナリの起動時間は他のCプログラムと同じであるため、2秒の起動遅延はなくなります。
補遺1： 2013年11月以降、Juliaの開発バージョンは、標準ライブラリをバイナリコードとしてプリコンパイルするため、2秒の起動遅延がなくなりました。起動時間はPythonおよびRubyよりも10倍遅いため、改善の余地はありますが、かなり高速です。次のステップは、パッケージとスクリプトのプリコンパイルを許可して、Julia自体がすでに実行しているのと同じくらい高速に起動できるようにすることです。
補遺2： 2015年6月以降、Juliaの開発バージョンは多くのパッケージを自動的にプリコンパイルし、すばやくロードできるようにしています。次のステップは、Juliaプログラム全体の静的コンパイルです。