AMD Opteron 2419 EE: 6 core a bassissimo consumo

no attualmente ci sono gli attuali 4+4 e gli 8+8 per server.

voci dicono che dovrebbero arrivare verso fine anno "teoricamente"

pero non ho capito se solo come i9 per desktop o anche come Xeon

no contro l'esa-core AMD ci sono gia gli esa core XEON serie 7400

comunque dovrebbero uscire a breve e credo come serie 8000 ( credo )



e va bè dai 8 + 8 si capisce è piu cveloce da scrivere

ragazzi comunque HT rientra nella tecnica generale dell SMT, e questo lo sapete tutti.
l'HT degli intel di oggi, i nehalem, è diversisissimo da quello del P4/xeon/netburst, sia perchè le CPU sono totalmente differenti e perchè l'ht è è stato totalmente rifatto da zero, ovvero ht è il nome commerciale, ovvero l'SMT dei nehalem non deriva minimamente dall'implementazione dell'SMT/HT dei netburst.
E cmq come già detto sia IBM (con i power) che SUN, utilizzano già da tempo l'SMT, e ora o letto da un post che anche AMD sta implementando la sua versione nei futuri processori.
Quindi alla luce di tutto ciò credo che l'SMT diventerà una tecnologia sempre + importante in futuro, e sarà determinante in una CPU.
Cmq io non ci vedo un confronto tra CPU reali e virtuali, o tra core e thread come ne parlano molti. Una cpu avrà il numero di core indipendentemente dall'SMT. IMHO l'SMT è un valore aggiunto alla cpu, proprio perchè(come già in un post precedente da altri) l'SMT serve a sfruttare le latenze del processore, e quindi a sfruttarlo al massimo, è come se si cercasse di sfruttare le parti della CPU che sono inattive durante un computo(qusta cosa l'ho scritta male). Insomma l'SMT sfrutta quella parte di CPU che rimarrebbe inutilizzata se questa tecnologia non ci fosse su una data CPU(ovviamente non è perfetta e non sfrutta tutto).
Credo che il tuto si basa sulle latenze, imho diventerà una tecnologia fondamentale delle CPU

Il punto rimane sempre quello dei colli di bottiglia(latenze) e della non perfetta efficienza dei sistemi OOO che non sempre riescono ad estrarre un livello di parallelismo che sfrutti tutte le unità funzionali della CPU.

Un esempio tangibile sono i processori AMD che quasi mai riescono ad usare le 9 unità funzionali di cui dispongono. (senza considerare SIMD)

Intel ha ancora più unità e decoder di AMD nei suoi processori, quindi l'unico modo per aumentare l'efficienza, senza stravolgere l'architettura è quello di aumentare i thread.

Del resto molti benchmark in alcuni scenari hanno aumenti prestazionali dal 30 al 50%. Certo non tutti gli scenari sono parallelizzabili, ma questo si sapeva già del resto...

Basta passare alle nanotecnologie ed il problema è risolto...


-----------------------


Approcci diversi con architetture fortemente parallele sono già stati avviati, vedesi EPIC, ma comporta come al solito un totale abbandono del x86. Purtroppo un tale passo dubito sarà mai compiuto, quindi ci dovremo portare dietro estensioni su estensione di quello che abbiamo già.

bisognerebbe lavorare di più sull'ottimizzazione del codice e dell'architettura della cpu e sulle istruzioni.. ma penso che costi di più che mettere un'ht o progettarne uno nuovo...

ovviamente in uno scenario I/O bound in cui si hanno molte pause oppure in caso di forti colli di bottiglia dati da latenza varie, l'ht gioca un ruolo determinante, ma non è detto che l'ht è meglio sempre, tengo a precisarlo.

a parità di architettura freq etc, 6 fisici in molti scenari sono meglio di 4+4.

l'unico che ha detto qualcosa in materia sono stato io, e ho ESPRESSAMENTE scritto NEI RENDER, vediamo di non travisare

scusami, ho letto il tuo intervento sto mezzogiorno, e non ricordavo che avevi detto solo in ambito render.

correggo.

se non ho capito male TDP e ACP sono 2 cose diverse, uno misura il calore prodotto (TDP) l'altro il consumo medio (ACP)?

No aspetta, stai facendo un po' di confusione.
Si parla di processo I/O bound quando il processo è improntato prettamente alle operazioni di comunicazione con le periferiche, leggi il disco fisso principalmente.
Hyperthreading invece opera all'interno dell'architettura del processore: ai tempi di netburst gli stalli nelle pipeline, le attese e le latenze, invece di diventare tempo perso diventano tempo utile per un altro thread. Su netburst aveva senso perchè aveva una pipeline abnormemente lunga (21 stadi per i willamette/northwood, addirittura 30 stadi per i prescott e i presler).