これは、Kプログラミング言語に関するウィキペディアのエントリからの抜粋です。
インタプリタのサイズが小さく、言語の構文がコンパクトなため、K個のアプリケーションをプロセッサのレベル1キャッシュに完全に収めることができます。
特にKプログラムをそれほど小さくしているのは何ですか？'Kの演算子、mapHaskellのようなコンパイルされた関数型言語、またはCのようなコンパイルされた命令型言語の同等のループを使用する場合、コンパイラが根本的に異なるアセンブリコードを生成することや、インタプリタの内部で発生することがループとは大きく異なるforことは想像できません。。Kのランタイムとプログラムを非常に小さくする特別なものはありますか？for
SOについても同様の質問がありますが、そこにある答えは基本的に何も明確にしません。
非常にコンパクトなコードを生成する方法があります。たとえば、Forthなどのhttp://en.wikipedia.org/wiki/Threaded_code 。Kは何らかの形にコンパイルされている可能性があります。
私は上記のウィキペディアの声明の著者ではなく、Kを広範に使用している人です。
コードに関しては、Kはループを展開したり、プログラム構造に他の変更を加えたりして、予想以上にサイズを大きくすることはありません。実行可能なインタプリタ自体は小さいです。そして、プログラムは小さい傾向があります（必ずしもそうとは限りませんが）。コード自体がすべてキャッシュ内で実行される可能性を高めるのは、マッピングなどの特定の命令の実行ではありません。
Kプログラムは、ストレージ内の小さくてタイトなバイトコードであるため、小さい傾向があり、その構文では、特定の操作に対して非常に少量のコードが生成される傾向があります。
このJavaプログラムを比較してください。
int r=0;
for(int i=0; i<100; i++) {
r+=i;
}
このKプログラムに対して、同じ結果が得られます。
+/!100
実行されるコードの量は同じですが、プログラムに必要なストレージ（入力がはるかに少ない！）ははるかに少なくなります。Kは、反復運動過多損傷のある人に最適です。
データに関しては、単一の命令で複数のデータ項目を処理するように促すことで、ランダムアクセスではなく、キャッシュに適した方法でアクセスをシーケンシャルにする傾向があります。これらはすべて、プログラムがキャッシュフレンドリーになる可能性を高めるだけです。
しかし、これはすべて、K実行可能ファイル自体と組み合わせた言語内の傾向とベストプラクティスにすぎません。大量の追加コード、特殊なケースの多くの関数をリンクし、データにアクセスする前にインデックスをランダム化すると、プログラムは期待どおりにキャッシュに不利になります。