Ci sono CPU con riduzione del grafico come SKIM, GRIP e forse la più conosciuta, la Reduceron. (Il set di istruzioni di Reduceron è fondamentalmente un sottoinsieme di Haskell, cioè un linguaggio funzionale pigro, ma ha anche una garbage collection nell'hardware.)
Le architetture FLEET e EDGE si concentrano molto sulla comunicazione. All'inizio del calcolo, il calcolo era costoso, ma la comunicazione (sulla CPU) era praticamente libera. Al giorno d'oggi, è l'opposto: le CPU possono essere elaborate incredibilmente velocemente, spostando i segnali attorno alla CPU è questo il problema. Ma non possiamo influenzare la comunicazione: possiamo solo dire alla CPU di calcolare, la comunicazione sulla CPU avverrà come un effetto collaterale di ciò, al di fuori del nostro controllo. L'architettura di FLEET capovolge il problema: si indicano solo i dati dove andare, il calcolo avviene come un effetto collaterale di quello.
La CPU Azul Vega-3 ha un set di istruzioni RISC a 3 indirizzi piuttosto tradizionale, ma la sua implementazione è strongmente ottimizzata per linguaggi orientati agli oggetti con polimorfismo dinamico. Quindi, non è una CPU orientata agli oggetti, ma è una CPU ottimizzata per l'orientamento agli oggetti. Per esempio. Il codice OO ha molto meno localita 'di tempo e localita' di spazio rispetto al codice ADT. Ma le CPU più moderne dipendono dalla località temporale e spaziale per molte delle loro ottimizzazioni. Queste ottimizzazioni sono per lo più inutili per i linguaggi OO. Ad esempio, il prefetching della memoria per evitare errori di cache. Il Vega, invece di provare a evitare la cache manca, riduce il costo di una mancanza della cache avendo una quantità folle di larghezza di banda di memoria e un controller di memoria molto sofisticato. (Dopo tutto, il costo delle mancate cache è di #misses * cost(miss)
, e abbassare l'uno o l'altro ridurrà il costo totale.) Su un sistema Vega, puoi avere decine di migliaia di errori di cache in volo, e comunque fare progressi con il tuo calcolo.