Orma di memoria del programma per interpreti / compilatori diversi

Question

Ecco un estratto da Wikipedia Entry on K Language di programmazione :

.

.

Le dimensioni ridotte dell'interprete e della sintassi compatta della lingua consente di adattarsi alle applicazioni K di adattarsi interamente all'interno della cache di livello 1 del processore.

Cosa in particolare rende i programmi K così piccoli? Quando si utilizza ' Operator in K, map in linguaggio funzionale compilato come Haskell, o loop equivalente for in un linguaggio imperativo compilato come c, non riesco a immaginare sia il compilatore che genera radicalmente diverso codice di assembly o che cosa succede negli interni dell'interprete sarà molto diverso dal ciclo for. C'è qualcosa di speciale in K che rende il suo runtime e i suoi programmi così piccoli?

C'è un simile Domanda su così, ma le risposte lì fondamentalmente chiariscono Niente.

Answer 1

Ci sono modi per generare un codice molto compatto.Ad esempio, un http://en.wikipedia.org/wiki/threaded_code di avanti e allo stesso modo.È probabile che K è compilato in qualche forma di esso.

Answer 2

Non sono l'autore della dichiarazione di Wikipedia sopra, solo qualcuno che usa ampiamente K.

Come per il codice, K non sta srotolando i loop o facendo altre modifiche alla struttura del programma che lo aumenterebbe in dimensioni oltre ciò che ti aspetti. L'interprete eseguibile stesso è minuscolo. E i programmi tendono ad essere piccoli (anche se non necessariamente così). Non è l'esecuzione di particolari istruzioni per la mappatura, ecc. Che rendono più probabile che il codice stesso esegua tutto all'interno della cache.

K i programmi tendono ad essere piccoli perché sono un piccolo bytecode stretto in stoccaggio e la loro sintassi tende a fornire quantità molto piccole di codice per una determinata operazione.

Confronta questo programma Java:

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

.

Contro questo programma K per produrre lo stesso risultato:

+/!100

.

La quantità di codice che viene eseguita è simile, ma lo storage richiesto dal programma (molto meno digitando!) è molto meno. K è ottimo per quelli con lesioni ripetitive dello stress.

Per quanto riguarda i dati, l'incoraggiamento a lavorare su più elementi di dati con le singole istruzioni tende a rendere l'accesso sequenziale, in modo amichevole alla cache, piuttosto che ad accesso casuale. Tutto ciò rende semplicemente più probabile che il programma sarà cache amichevole.

Ma questa è tutte solo le tendenze e le migliori pratiche all'interno della lingua in combinazione con il programma K è stesso. Se si collega in grandi quantità di codice aggiuntivo, custodia speciale molte funzioni e randomizza i tuoi indici prima di accedere ai tuoi dati, il programma sarà altrettanto scortese alla cache come ti aspetteresti.