Ich bin nicht der Autor der obigen Wikipedia-Erklärung, sondern nur jemand, der K ausgiebig nutzt.
Was den Code betrifft, so rollt K keine Schleifen ab und nimmt auch keine anderen Änderungen an der Programmstruktur vor, die den Umfang des Programms über das von Ihnen erwartete Maß hinaus erhöhen würden. Der ausführbare Interpreter selbst ist winzig. Und die Programme neigen dazu, klein zu sein (wenn auch nicht unbedingt so). Es ist nicht die Ausführung bestimmter Anweisungen für das Mapping usw., die es wahrscheinlicher macht, dass der Code selbst vollständig im Cache ausgeführt wird.
K-Programme sind in der Regel klein, weil sie einen kleinen, kompakten Bytecode speichern und ihre Syntax dazu neigt, sehr kleine Mengen an Code für eine bestimmte Operation zu liefern.
Vergleichen Sie dieses Java-Programm:
int r=0;
for(int i=0; i<100; i++) {
r+=i;
}
Gegen dieses K-Programm wird das gleiche Ergebnis erzielt:
+/!100
Die Menge des auszuführenden Codes ist ähnlich, aber der vom Programm benötigte Speicherplatz (viel weniger Tipparbeit!) ist viel geringer. K eignet sich hervorragend für Personen mit Verletzungen durch wiederholte Belastung.
Was die Daten anbelangt, so wird durch die Ermutigung, mehrere Datenelemente mit einem einzigen Befehl zu bearbeiten, der Zugriff eher sequentiell und damit cachefreundlich als zufällig erfolgen. All dies macht es lediglich wahrscheinlicher, dass das Programm cache-freundlich ist.
Aber das sind alles nur Tendenzen und bewährte Verfahren innerhalb der Sprache in Kombination mit der ausführbaren Datei K selbst. Wenn Sie große Mengen an zusätzlichem Code einbinden, viele Funktionen mit Spezialfällen versehen und Ihre Indizes vor dem Zugriff auf Ihre Daten randomisieren, wird Ihr Programm genauso unfreundlich gegenüber dem Cache sein, wie Sie es erwarten würden.
