さまざまなインタプリタ/コンパイラのプログラム メモリ フットプリント

Question

以下はその抜粋です K プログラミング言語に関する Wikipedia の項目:

インタプリタのサイズが小さく、言語の構文がコンパクトであるため、K アプリケーションをプロセッサのレベル 1 キャッシュ内に完全に収めることができます。

K プログラムを特に小さくしているのはなぜですか?使用するとき ' K の演算子、 map Haskell などのコンパイルされた関数型言語、または同等のもの for C のようなコンパイルされた命令型言語のループでは、どちらのコンパイラーが生成するか想像できません。 根本的に アセンブリコードが異なるか、インタプリタの内部で何が起こるかが大きく異なる可能性があります。 for ループ。K には、ランタイムとプログラムを非常に小さくする特別な何かがあるのでしょうか?

似たようなのがあるよ 質問 SO ですが、そこにある答えは基本的に何も明確にしていません。

Answer 1

非常にコンパクトなコードを生成する方法があります。たとえば、 http://en.wikipedia.org/wiki/Threaded_code フォースなどの。おそらく K は何らかの形式にコンパイルされていると思われます。

Answer 2

私は上記のウィキペディアの記述の著者ではなく、K を広く使用しているだけです。

コードに関して言えば、K はループを展開したり、プログラム構造に予想以上にサイズを増大させるような変更を加えたりすることはありません。実行可能インタープリタ自体は小さいです。また、プログラムは小さい傾向があります (必ずしもそうとは限りませんが)。マッピングなどの特定の命令を実行するわけではありません。そのため、コード自体がすべてキャッシュ内で実行される可能性が高くなります。

K プログラムは、ストレージ内に小さくタイトなバイトコードであるため、サイズが小さくなる傾向があり、その構文では、特定の操作に対して生成されるコードの量が非常に少量になる傾向があります。

この Java プログラムを比較してください。

int r=0;
for(int i=0; i<100; i++) {
  r+=i;
}

この K プログラムに対して、同じ結果が得られます。

+/!100

実行されるコードの量は同様ですが、プログラム (入力よりもはるかに少ない) に必要なストレージははるかに少なくなります。K は、反復性ストレス損傷のある人に最適です。

データに関しては、単一の命令で複数のデータ項目を処理することが推奨されるため、ランダム アクセスではなく、キャッシュに優しい方法でアクセスがシーケンシャルになる傾向があります。これらすべては、単にプログラムがキャッシュに優しいものになる可能性を高めるだけです。

しかし、これはすべて、K 実行可能ファイル自体と組み合わせた言語内の傾向とベスト プラクティスにすぎません。データにアクセスする前に、大量の追加コード、特殊なケースの多くの関数をリンクし、インデックスをランダム化すると、プログラムは予想どおりキャッシュに対して不利になります。