Quote:
Originariamente inviato da cdimauro
OK, ma come il tizio del thread diceva, non c'erano montati nemmeno i dischi, e aveva soltanto 16GB di memoria installati. Quindi non penso che il consumo fosse dovuto al sistema stracarico di roba, ma al sistema quasi vuoto.
E' un peccato non avere altri dati per poter capire quanto incida realmente la CPU sul consumo.
|
Nel thread a cui ti riferivi si parlava del
consumo del sistema completo:
http://amigaworld.net/modules/newbb/...orum=33#737012
Non dei core, non della mainboard, ma del sistema
completo.
Anche con "solo" 16GB di ram installata e nessun disco montato hai un sacco di roba oltre i core (tipo due alimentatori capaci di reggere il sistema in configurazione massima e che supportano l'hot-swap, da soli nella pura e semplice parte switching si mangiano almeno un 8% circa del consumo totale).
Quote:
Originariamente inviato da cdimauro
Anch'io mi riferivo esclusivamente all'emulazione delle singole istruzioni, peraltro soltanto in user-space (negli 80186 e 65C02 non esiste il concetto di kernel-space: è tutto user  ).
Purtroppo al momento non ho sotto mano il codice dei miei emulatori, ma appena lo recupero posto qualche spezzone, così sarà facile capire quali dipendenze ci sono in gioco e perché non posso essere eliminate riordinando il codice. |
Ricorda che presupponendo che il codice binario venga eseguito su un S.O. "completo" e con processore che supporta la separazione tra user-space e kernel-space, paradossalmente l'emulazione lato user-mode diventa molto più semplice.
Niente ISR, niente istruzioni che su un 80186 o su un 6502 permettono di manipolare porte di I/O ed altra roba che sarebbero normalmente vietata in user-space, ecc.
Quote:
Originariamente inviato da cdimauro
Un'ISA come x86 ha pochi registri, ma li sfrutta parecchio, per cui si fa ampio uso di tecniche di register-renaming nelle microimplementazioni. Tutto ciò può facilmente venire implementato da un'ISA VLIW che ha parecchi registri a disposizione e può sfruttarli proprio per il renaming tracciando opportunamente il loro utilizzo.
|
Ma in quel modo si carica di molto più lavoro il decoder misto hardware/software dell'architettura VLIW "con set d'istruzioni esterno non-VLIW".
Mentre invece con più registri (ma non troppi) visibili al compilatore è esso a svolgere il grosso dell'ottimizzazione e quindi la decodifica verso istruzioni VLIW è più semplice ed efficiente.
Per questo il set d'istruzioni ha ancora una discreta influenza sulle prestazioni ottenibili.
Quote:
Originariamente inviato da cdimauro
Last but not least, già il primo Crusoe aveva una cache L2 con linee di ben 128 byte = ben 1024 bit. Probabilmente è questo che ha frenato il clock, causa problematiche di clock skew.
|
La cache L2 è due gerarchie di memoria al di sotto dei registri interni, quindi le ragioni per scegliere una certa dimensione non sono gli stessi dei registri interni.
La dimensione delle linee di cache L2 ed L3 viene cambiata di generazione in generazione in base all'ampiezza dei bus verso la ram e della frequenza massima di lavoro della cpu e della ram.
Attualmente negli x86 di Intel è stabile sui 64byte.
Il motivo principale dell'attuale "standardizzazione" a 64byte è legato alla tecnologia dei moduli di ram.
Le DDR hanno un canale che trasferisce 64bit per fronte (8byte), ma danno il massimo di prestazioni quando sono in burst mode, ovvero trasferiscono 4 gruppi di 8 byte consecutivamente (32byte totali).
A questo punto considera che la configurazione comune è avere DUE canali DDR e questo spiega la "standardizzazione" attuale su linee da 64byte.
Ma ad esempio in passato gli Itanium mcKinley avevano una L2 line size di 128byte ed i Pentium 4 avevano una L2 line size di 64byte ma con un opzione per leggere/scrivere due cache line consecutive (nel caso fossero stati abbinati ad un northbridge con memory controller con più di due canali o che supportasse una tipologia di ram con una banda di I/O più elevata).