Opteron Dual Core: il lancio tra alcune settimane

[Fx]

Originariamente inviato da xeal
Però l'875 (Dual @2.2Ghz) costa praticamente quanto un singolo Itanium2 a 1.3 Ghz, probabilmente se la gioca tranquillamente anche con applicazioni fpu intensive, il vero cavallo di battaglia di Itanium (anche se a questo punto il salasso arriverebbe con i costi delle licenze sw...).

se vai sul sito della SPEC (www.spec.org) scoprirai che due opteron 248 hanno un fp_rate di oltre 32, due itanium 2 a 1.4 invece arrivano a circa 38: è lecito aspettarsi che un opteron dual core a 2.2 ghz performi molto meglio rispetto a un itanium 2 a 1.3 ghz anche sulla virgola mobile, oltre che sul resto.

personalmente penso che l'unica pecca che ha l'opteron è che non ci siano delle versioni con una cache l2 più generosa, anche se c'è da dire che con la quantità di banda che si ritrova a disposizione di sicuro è meno determinante che su processori come lo xeon, il quale ha un bus decisamente inadeguato (ed è un motivo per cui è meno scalabile dell'opteron)

[mrt75]

non vedo l'ora che escano anche gli altri

[xeal]

Originariamente inviato da Fx
personalmente penso che l'unica pecca che ha l'opteron è che non ci siano delle versioni con una cache l2 più generosa, anche se c'è da dire che con la quantità di banda che si ritrova a disposizione di sicuro è meno determinante che su processori come lo xeon, il quale ha un bus decisamente inadeguato (ed è un motivo per cui è meno scalabile dell'opteron)

Considera che i K8 non sono particolarmente "sensibili" agli aumenti di cache, sia per la banda passante e le basse latenze di accesso alla memoria, sia perchè hanno le pipeline abbastanza corte, ragion per cui hanno un elevato valore di instruction per cycle e, se qualcosa va storto nella predizione di un salto, non devono buttare a mare (e sostituire con altro codice ricercato nella cache o in memoria) troppi dati . Certo, ci saranno sicuramente dei casi in cui una cache più ampia porterebbe qualche vantaggio in più (anche se farebbe crescere le latenze di ricerca), però è anche vero che chi produce cpu gioca sempre un po' al "risparmio" e cerca di non mettere cose che "non servono" (o che ragionevolmente si potrebbero non mettere). Non credo che la cache di un processore venga progettata mai come la più grande possibile, né in base al principio "meglio abbondare", ma piuttosto come la minima indispensabile per ottenere le prestazioni volute in un certo ambito, tanto, se serve, si può sempre "revisionare" il core aggiungendo quella che serve (entro i limiti di progettazione). Ricordo, ad esempio, che l'aumento della cache in Itanium, tempo fa, consentiva, tra l'altro, alle cpu meno veloci di recuperare qualcosa nel calcolo degli interi, che non è certo la "specialità della casa" per questa architettura, almeno stando alle dichiarazioni di Intel (che sembravano un po' esagarate per un semplice aumento di cache, ma questi sono altri discorsi).


X BEMPINO: credo che joe4th certi dettagli li conosca bene, da quel che ho capito lui con i server ci lavora (e li compra anche...) Più che altro, si facevano considerazioni sul prezzo in relazione al segmento di destinazione

Bye

[Fx]

xeal: sono d'accordo. il punto è che se è vero che l'opteron è estremamente competitivo per il segmento workstation / server x86, lascia campo aperto agli itanium per il segmento superiore. imho, vedendo le performance di cui è capace, una versione con ampia dotazione di cache e arricchita delle feature che servono potrebbe esser capace di andare a infastidire parecchio sia gli itanium 2 che i power5 in quel segmento. in quel segmento i vantaggi di avere tanta cache sono molti e superano di molto gli svantaggi (che hai correttamente sottolineato).

[xeal]

x Fx: sul calcolo intero (basialare, ad esempio, per la gestione dei database) Opteron non sfigura in nessun segmento (e in questo campo Itanium non è certo un fulmine di guerra). C'è poca storia sul calcolo in virgola mobile, ma li una cache più grande cambierebbe ben poco: il fatto è che Itanium ha una fpu veramente mostruosa, c'è poco da dire (e da fare); l'unità in virgola mobile dei K8 è molto buona (e mi pare che abbia delle affinità con quelle dei risk), ma putroppo nel mondo degli x86 si è affermato il ricorso a unità supplementari (le unità SIMD: mmx, sse, 3dnow...) e difficilmente si avrà un'inversione di rotta (specialmente in tempi brevi), per cui per l'introduzione (in versioni future) di una fpu estremamente efficiente la vedo dura (a meno di creare una cpu server che non abbia nulla a che spartire con quelle destinate al settore desktop/workstation). Del resto, per come la vedo io, non è che Itanium è avvantaggiato rispetto a Opteron perchè ha una cache più grande, ma sarebbe (in misura variabile a seconda del contesto, ovviamente) svantaggiato se così non fosse (e in qualsiasi segmento), o comunque ha un quantitativo di cache che è il "minimo indispensabile" per avere buone prestazioni (in ogni scenario d'uso), così come l'opteron (non a caso i quantitativi più grandi, fino a 24 MB credo, sono previsti per gli Itanium multicore).

Naturalmente ci saranno degli scenari in cui una cache più grande gioverebbe, ma potrebbero essere pochi nel complesso (come nel caso del PM avvantaggiato dai suoi 2MB di L2 nel superPI con precisione fissata a "1 million" perchè l'applicazione e i suoi dati stanno tutti nella cache per la durata dell'esecuzione del test: si tratta di un caso, in generale la L2 in quel processore sopperisce alla limitata ampiezza di bus, e in ambito server una situazione del genere si verifica raramente): sicuramente i progettisti di AMD avranno fatto "quattro calcoli" per dimensionare la cache, e in ambito desktop, per avere un raffronto, nel passare da 512 KB a 1 MB, come dal single al dual channel, è difficile registrare distacchi abissale (laddove ce ne siano), proprio in virtù dell'ampia banda passante grazie all'integrazione del controller della memoria. Del resto, non sottovaluterei troppo l'aumento della latenza di ricerca con l'aumentare della dimensione della cache (essendo organizzata come un database molto efficiente, i dati vanno in qualche modo ricercati in essa, non vi si può accedere proprio "a colpo sicuro" ): se non ricordo male, Itanium impiega una ventina di cicli di clock per trovare i dati nella cache, mentre presumo che Opteron (non ricordo i valori), avendo una cache più piccola, necessiti di qualche ciclo in meno, e di conseguenza, a fronte di una banda verso la memoria notevole, molto vicina nei valori reali ai limiti teorici (e resa ancor più ampia dal NUMA, ove supportato), un aumento della cache e delle latenze di ricerca dei dati potrebbe non essere particolarmente vantaggioso (lo so, sto un po' cavillando, ma non conoscendo valori certi posso solo fare supposizioni, del resto, i progettisti dei K8 avranno fatto le dovute considerazioni e se pensassero di poter insidiare pesantemente itanium e gli altri risk-like in quel segmento semplicemente sovradimensionando la cache - che comunque ha dei limiti progettuali, non ricordo quali siano - credo che non ci penserebbero due volte ).

Comunque, non conosco con esattezza gli scenari di calcolo di quel particolare settore, quindi mi baso solo su quel che conosco delle architetture di questi processori, fidandomi delle capacità dei progettisti, sia per quanto riguarda gli ingegneri di AMD, sia per quanto riguarda quelli di Intel-HP.

Ciao

[Fx]

un solo appunto: nei server di quella fascia una grossa quantità di cache ti serve non solo come pezza ai vari colli di bottiglia che comunque i processori intel tradizionalmente hanno ma anche e soprattutto per tenere "a portata di mano" le informazioni più usate, esattamente come per la cache di una cpu desktop; la differenza è che nei server di quella fascia vengono fatti girare numeri enormi di processi, che si "mangiano" ognuno una fettina di cache: una volta che l'hanno finita, per i restanti processi è come (circa ) se la cpu non avesse la cache. e se hai "finito" la cache, anche se l'opteron lavorare efficacemente con la ram comunque non è bello

[cdimauro]

In futuro potrebbero anche esserci processori Opteron con 4 o più core: non ci sarebbe alcun problema nell'usarli negli attuali sistemi a 1, 2, 4 o 8 "socket". Fisicamente, quindi, non ci sarebbe alcun problema: al più i processori si contenderebbero maggiormente la banda dell'unico memory controller e dei vari bus hyper transport disponibili.

Quanto al confronto con Itanium, come è stato sottolineato da xeal, gli Opteron sono decisamente meno sensibili al quantitivo di cache integrato rispetto a questi concorrenti: la cache potrebbe essere importante soltanto in particolari ambiti.
Infatti altre CPU per server sono dotate di notevoli quantità di cache proprio perché devono condividere il bus, e quindi la banda di memoria, fra di loro, mentre gli Opteron, essendo dotati ognuno di un proprio controller per la memoria, possono accedere in maniera esclusiva alla memoria localmente installata, con i vantaggi che si possono immaginare.
Per questo motivo la banda aggregata totale del sistema si ritrova moltiplicata per il numero di Opteron presenti, e infatti mentre le altre CPU incorrono in un degrado prestazionale consistente all'aumentare dei processori, gli Opteron presentano un degrado nettamente inferiore (anzi, le applicazioni SMP che sfruttano il NUMA possono funzionare anche meglio).
Quantità di cache maggiori potrebbero aver senso soltanto per sistemi dual o multicore, per gli stessi motivi per cui ne fanno ricorso le altre CPU, ma in generale gli attuali sistemi a n vie basati su Opteron partono col vantaggio di avere, appunto, ognuno n accessi "concorrenti" alla memoria.

[Michelangelo_C]

Non ho capito una cosa: ogni opteron ha un memory controller integrato nella CPU, quindi ogni processore può fare un accesso alla memoria a sè, indipendentemente dagli altri. Però questo mi sembra strano, perchè a quanto sopevo può essere effettuato un solo accesso per volta alla memoria, non è così?

[xeal]

Originariamente inviato da Fx
un solo appunto: nei server di quella fascia una grossa quantità di cache ti serve non solo come pezza ai vari colli di bottiglia che comunque i processori intel tradizionalmente hanno ma anche e soprattutto per tenere "a portata di mano" le informazioni più usate, esattamente come per la cache di una cpu desktop; la differenza è che nei server di quella fascia vengono fatti girare numeri enormi di processi, che si "mangiano" ognuno una fettina di cache: una volta che l'hanno finita, per i restanti processi è come (circa ) se la cpu non avesse la cache. e se hai "finito" la cache, anche se l'opteron lavorare efficacemente con la ram comunque non è bello

E' un aspetto interessante, che però non ho voluto toccare in quanto non sono particolarmente "ferrato" sulla gestione della cache (credo che cdimauro possa dire qualcosa di più preciso in merito ). Dipende tutto da come viene gestita: è probabile (o comunque possibile) che durante un context switch la cache venga svuotata (parzialmente o del tutto) per far posto alle informazioni necessarie al nuovo porcesso, e che quindi rimangano ben pochi dati a pronti all'uso per gli altri processi, a meno che non siano state appositamente bloccate alcune linee (se la banda verso la memoria è notevole, potrebbe risultare conveniente rispetto all'esecuzione di calcoli complessi per decidere come sistemare i dati nella cache e quali sostituire); comunque, ripeto, non ne so abbastanza sull'argomento, quindi rilancio la palla sperando che qualcuno possa chiarire meglio .

[xeal]

Originariamente inviato da cdimauro
In futuro potrebbero anche esserci processori Opteron con 4 o più core: non ci sarebbe alcun problema nell'usarli negli attuali sistemi a 1, 2, 4 o 8 "socket". Fisicamente, quindi, non ci sarebbe alcun problema: al più i processori si contenderebbero maggiormente la banda dell'unico memory controller e dei vari bus hyper transport disponibili.

Quindi potrebbe diventare sempre più utile "sistemare" in maniera conveniente gli algoritmi di scheduling della cpu (eventualmente modificando anche quelli interattivi) per tener conto dei "raggruppamenti" di core fisici al fine di limitare il possibile degrado prestazionale, sia cercando il più possibile di assegnare i thread "affini" allo stesso "gruppo" (ovvero alla stessa cpu fisica), sia tenendo conto, eventualmente, di "tendenze" a compiere IO-burst oppure cpu burst da parte dei processi, per fare in modo, ad esempio, che (forse si tratterebbe del caso più favorevole) due dei core presenti (la metà, in generale) si contendano il bus hyper transport e i rimanenti il bus verso la memoria. Naturalmente sempre che ciò non comporti un overhead eccessivo o comunque non renda gli algoritmi poco efficienti/precisi (un po' come succede, se non ricordo male, per le versioni adattate al time sharing, o comunque alla schedulazione a breve termine, dello shortest job first, buono invece per lo scheduling a medio termine, non troppo per quello a lungo termine). Magari poi risulta più conveniente lasciare le cose come stanno, specialmente in un cluster, dove le prestazioni complessive tendono a essere più influenzate dalle strutture di comunicazione tra le unità che si spartiscono il lavoro (per cui un sistema a 8 vie con cpu quad-core potrebbe anche avere prestazioni migliori rispetto a 4 sistemi analoghi con cpu single core), almeno credo...

[xeal]

Originariamente inviato da Michelangelo_C
Non ho capito una cosa: ogni opteron ha un memory controller integrato nella CPU, quindi ogni processore può fare un accesso alla memoria a sè, indipendentemente dagli altri. Però questo mi sembra strano, perchè a quanto sopevo può essere effettuato un solo accesso per volta alla memoria, non è così?

Per quanto ne so, in virtù del memory controller integrato gli Opteron possono gestire la memoria in maniera "proprietaria", ovvero puoi assegnare N GB di memoria a ogni processore, che gestisce solo quella come se non ci fossero né gli altri processori, né gli altri banchi (se poi un processore deve accedere alla memoria gestita da un altro interviene il bus hyper transport).

[cdimauro]

Originariamente inviato da Michelangelo_C

Non ho capito una cosa: ogni opteron ha un memory controller integrato nella CPU, quindi ogni processore può fare un accesso alla memoria a sè, indipendentemente dagli altri. Però questo mi sembra strano, perchè a quanto sopevo può essere effettuato un solo accesso per volta alla memoria, non è così?

Infatti è così: per Opteron intendo la CPU che integra i due core e l'unico memory controller.

[cdimauro]

Originariamente inviato da xeal

E' un aspetto interessante, che però non ho voluto toccare in quanto non sono particolarmente "ferrato" sulla gestione della cache (credo che cdimauro possa dire qualcosa di più preciso in merito ). Dipende tutto da come viene gestita: è probabile (o comunque possibile) che durante un context switch la cache venga svuotata (parzialmente o del tutto) per far posto alle informazioni necessarie al nuovo porcesso, e che quindi rimangano ben pochi dati a pronti all'uso per gli altri processi,

Infatti, è ciò che avviene normalmente.

a meno che non siano state appositamente bloccate alcune linee

In cache possono anche rimanere le linee di codice/dati relative a porzioni di memoria condivisa con altri processi / thread.

(se la banda verso la memoria è notevole, potrebbe risultare conveniente rispetto all'esecuzione di calcoli complessi per decidere come sistemare i dati nella cache e quali sostituire); comunque, ripeto, non ne so abbastanza sull'argomento, quindi rilancio la palla sperando che qualcuno possa chiarire meglio .

A mio avviso bloccare le linee di cache non è generalmente conveniente, perché:
- prima o poi un context switch si verificherebbe (e potrebbe anche essere in mezzo al pezzo di codice che ha bloccato quelle linee), e il nuovo processo / thread si troverebbe con parte della cache inutilizzabile, quindi incidendo negativamente sulle prestazioni;
- sarebbe necessario scrivere del codice in assembly per gestire le linee di cache;
- si legherebbe il codice a una particolare architettura / piattaforma.

La cosa migliore da fare è utilizzare delle tecniche di prefetching, rese disponibili ormai da tutte le implementazioni SIMD, per anticipare il caricamento dei dati necessari, in modo da renderli immediatamente disponibili al momento del bisogno, e per marcare alcuni dati in modo che non finiscano ad occupare inutilmente spazio nella cache (es: faccio un'operazione su certi dati, che poi sono sicuro di non usare più, e che quindi dovrebbero andare esclusivamente in memoria).

[cionci]

Originariamente inviato da Michelangelo_C

perchè a quanto sopevo può essere effettuato un solo accesso per volta alla memoria, non è così?

Il collegamento con la memoria è a doppio canale...quindi in teoria gli accessi contemporanei sono due...poi ogni CPU può accedere anche alla memoria delle altre CPU (in un sistema SMP), con una latenza maggiore, ma sempre con buone prestazioni...quindi considerando questo in teoria gli accessi contemporanei alla memoria possono essere anche di più... Inoltre metti che la presenza di 1152 Kb di cache L1+L2 fanno sì che raramente due task debbano accedere contemporaneamente alla memoria...

[cdimauro]

Originariamente inviato da xeal

Quindi potrebbe diventare sempre più utile "sistemare" in maniera conveniente gli algoritmi di scheduling della cpu (eventualmente modificando anche quelli interattivi) per tener conto dei "raggruppamenti" di core fisici al fine di limitare il possibile degrado prestazionale, sia cercando il più possibile di assegnare i thread "affini" allo stesso "gruppo" (ovvero alla stessa cpu fisica), sia tenendo conto, eventualmente, di "tendenze" a compiere IO-burst oppure cpu burst da parte dei processi, per fare in modo, ad esempio, che (forse si tratterebbe del caso più favorevole) due dei core presenti (la metà, in generale) si contendano il bus hyper transport e i rimanenti il bus verso la memoria. Naturalmente sempre che ciò non comporti un overhead eccessivo o comunque non renda gli algoritmi poco efficienti/precisi (un po' come succede, se non ricordo male, per le versioni adattate al time sharing, o comunque alla schedulazione a breve termine, dello shortest job first, buono invece per lo scheduling a medio termine, non troppo per quello a lungo termine). Magari poi risulta più conveniente lasciare le cose come stanno, specialmente in un cluster, dove le prestazioni complessive tendono a essere più influenzate dalle strutture di comunicazione tra le unità che si spartiscono il lavoro (per cui un sistema a 8 vie con cpu quad-core potrebbe anche avere prestazioni migliori rispetto a 4 sistemi analoghi con cpu single core), almeno credo...

A mio avviso il problema della "sistemazione" dei processi/thread non dovrebbe essere delegato al s.o., ma all'applicazione, nel caso in cui questa abbia la possibilità di gestire più CPU per smistare loro il suo lavoro.

Questo perché chi ha scritto l'applicazione è la persona più indicata per stabilire, a seconda del sistema su cui gira (SMP "classico", SMP multi core, SMP multi core con HT, SMP multicore NUMA), in che modo da smistare il lavoro per trarne il maggior beneficio.

Invece un s.o. / scheduler ha una visione "statica", prestabilita da chi l'ha scritto, e le scelte che fa non sono valide e "ottimali" per tutti i casi.

Tutto questo IMHO, chiaramente...

[cdimauro]

Originariamente inviato da cionci

Il collegamento con la memoria è a doppio canale...quindi in teoria gli accessi contemporanei sono due...

Sì, ma non è possibile fare due accessi a locazioni di memorie diverse: la logica di indirizzamento della memoria è condivisa per entrambi i canali.

[cionci]

Originariamente inviato da cdimauro

Sì, ma non è possibile fare due accessi a locazioni di memorie diverse: la logica di indirizzamento della memoria è condivisa per entrambi i canali.

Sicuro ? Quidni è possibile leggere 128 bit a partire da un dato indirizzo, ma non 64 bit da una aprte e 64 da un'altra ? Mi sembra strano...

[cionci]

Quindi il dual channel verrebbe utilizzato solo quando si spostano dati a 128 bit (SSE) o nelle letture in burst (solitamente da/verso le periferiche) ?

[cdimauro]

Sì, lo si usa per leggere il doppio dei dati, e quindi per riempire più velocemente la cache L2 (e quindi la L1). Non è necessario usare direttamente le SSE.

Purtroppo l'unica implementazione "parallela", che permetteva di avere accesso simultaneo a due diverse locazioni di memoria, mi sembra fosse quella dell'nForce (1 e/o 2?), se non ricordo male. Ed era anche la più costosa, ovviamente (richiedeva lo sdoppiamento di tutte le linee di controllo).

[cionci]

Originariamente inviato da cdimauro

Sì, lo si usa per leggere il doppio dei dati, e quindi per riempire più velocemente la cache L2 (e quindi la L1).

In effetti non avevo pensato al fatto che anche la cache trasferisce a blocchi...quindi il doppio canale viene praticamente usato sempre

Comunque di fatto è come avere due canali separati...perchè supponendo che entrambe le cache vogliano leggere + o - contemporaneamente un blocco la somma dei tempi dei trasferimenti di entrambi i blocchi è pari a quello che si avrebbe supponendo di assegnare un canale ad ogni cache.. Anzi...in questo modo una cache finisce prima... Quindi probabilmente l'implementazione più efficiente è questa...