Newsgroup: it.comp.hardware.cpu
Titolo: E6400 scala meglio del 4770

Facendo alcune prove con uno dei programmi multi-thread che ho scritto, 
ho notato una cosa che mi sembra strana.
 
Con il vecchio dual-core E6400, ho sempre notato l'esatto raddoppio 
delle velocità di calcolo passando da 1 thread a 2 thread.
Con il 4770 ciò non accade mai.
Per spiegarmi, riporto la velocità di calcolo di quest'ultimo programma 
che ho scritto (che esegue calcoli in virgola mobile) in funzione dei 
thread usati:
 
thd  vel  vel/thd
  1   34    34,0
  2   63,6  31,8
  3   92,6  30,9
  4  114    28,5
  5  127    25,4
  6  142    23,7
  7  155    22,1
  8  165    20,6
  9  170    18,9
10  172    17,2
11  184    16,7
12  174    14,5
 
si nota il 63,3 invece di 34*2= 68.
 
Come mai l'E6400 scala alla perfezione mentre il 4770 no?
 
Grazie
Cristiano


 
114/ 59 pt (1,93 x) - Athlon X2 5400+ 2,8GHz (2 core)
231/ 62 pt (3,72 x) - Core 2 Quad Q6600 2,4GHz (4 core)
435/118 pt (3,68 x) - Core i5-2400 3,1GHz (4 core Sandy Bridge)
634/166 pt (3,82 x) - Core i5-4670K 3,4GHz (4 core Haswell)
812/161 pt (5,04 x) - Core i7-4770K 3,5GHz (4 core/8 thread Haswell)
643/101 pt (6,36 x) - FX-8350 4GHz (4 moduli/8 thread Piledriver)
 
il Core i7 ottiene un punteggio 5 volte maggiore rispetto
al singolo thread, poco se si pensa al valore teorico 8x ,
in realta' l'Hyper Threading garantisce il 28% di prestazioni
in piu' rispetto all'i5 che non ha l'HT (812/634)
 
discorso diverso per l'architettura di AMD introdotta con
Bulldozer/Piledriver (CMP) che ottiene un incremento
pari a 6,36x (piu' vicino all'8x teorico)
 
 
anche lato software ci sarebbero da fare diverse considerazioni,
ad esempio dipende da come e' stata sviluppata e compilata
la tua applicazione, a me sembra strano che i punteggi salgano
oltre gli 8 thread, di solito con altri software non ci sono
miglioramenti se sfruttano in modo ottimale le risorse disponibili
 
sarebbe interessante conoscere i punteggi dell'E6400 ,
soprattutto se si ottiene un comportamento simile
oltre i 2 thread (cioe' aumento delle prestazioni)
 
 
ciao
luca
 
 
 

 oltre i 2 thread (cioe' aumento delle prestazioni)
 
Qualitativamente si nota lo stesso comportamento:
 
thd  vel   vel/thd
  1   46,8   46,8
  2   92,5   46,3
  3   93     31,0
  4   93,3   23,3
  5   92     18,4
 
da notare l'ottima scalatura tra 1 e 2 thread (vel/thd è praticamente 
costante); cosa che è sempre capitata in tutti i programmi che ho scritto.
 
Nota: le velocità non sono confrontabili con quelle del mio primo post 
(il programma fa sempre la stessa cosa, ma le velocità esprimono 
grandezze differenti).
 
Ciao
Cristiano

 perfezione, mentre una CPU all'ultima moda non ci riesce.
 
Aggiungo il risultato della prova fatta con LinX 0.6.4:
1 thread: 33 s, 2 thread: 19 s.
NCS: nun ci siamo. :-)
 
Cristiano
 

 scritto.
 
c'e' una considerazione di fondo da non sottovalutare,
che l'i7 e' un quad core con Hyper Threading e non un octa core,
quindi il calcolo del rapporto "vel/thd" ne deve tenere conto
 
riassumendo, con l'E6400 ottieni un raddoppio del punteggio massimo
passando da 1 thread a 2 thread (con 1 e 2 core fisici),
il che e' perfetto considerando che e' una CPU dual core
 
con l'i7 hai un punteggio massimo che e' cinque volte maggiore
passando da 1 thread ad 8 thread (da 1 a 4 core fisici),
che e' un ottimo risultato in quanto maggiore di 4
(numero core fisici), e soprattutto in linea con quanto
riscontrato con altri bench, e cioe' il 20-30% in piu'
grazie all'Hyper Threading
 
come controprova, disabilita l'Hyper Threading da BIOS/UEFI
e riesegui i test, probabilmente otterrai maggiore scalabilita'
passando da 1 thread a 4 thread (da 1 a 4 core) ed
un punteggio massimo inferiore del 20-30% (che e' l'aspetto
piu' importante)
 
ciao
luca
 
 
 

 piu' importante)
 
Non noto differenze significative tra HT abilitato e disabilitato.
 
Tutt'altra situazione, invece, con un altro programma molto più "snello" 
che fa principalmente uso degli interi a 64 bit.
Anche in questo caso, la scalabilità lascia a desiderare, ma l'andamento 
della velocità di calcolo <mi sembra talmente strana che ho voluto 
riportare le varie prove su un grafico:
http://cristianopi.altervista.org/Vel_Burthe_MT.pdf
 
Le prove le ho fatte su Win 7 64 bit e ho riportato le velocità con HT 
(sia per la versione a 32 bit del programma che per quella a 64 bit) e 
senza HT (solo versione a 64 bit).
 
Di positivo, si nota il notevolissimo incremento della velocità ottenuto 
grazie all'HT (più del doppio del "solito" 20-30% normalmente rilevabile).
 
Molto strano (mi sembra) l'andamento della versione a 32 bit rispetto a 
quella a 64 bit (entrambe con HT): 32 bit più veloce fino a 3 thread, 
per poi essere notevolmente penalizzata aumentando il numero di thread; boh!
 
Cristiano

 thread; boh!
 
forse dipende dall'OS a 64 bit che non "digerisce" bene
quel particolare sw a 32 bit ?
 
 
sarebbe interessante avere maggiori informazioni sul programma
e sul compilatore (versione, ottimizzazioni/flag)
 
e sarebbe ancora piu' interessante sapere se riesci a fare
test con le nuove istruzioni TSX e se possono aiutare
a migliorare le prestazioni con il tuo programma
(hai il 4770 "liscio", giusto ?)
 
ciao
luca
 
 

 (hai il 4770 "liscio", giusto ?)
 
Ho il 4770 liscio, ma io direttamente non posso controllare l'utilizzo 
del set TSX dal compilatore. Sarebbe bello se Win 7 lo usasse 
nativamente per gestire le istruzioni relative al multi-thread, ma forse 
sarebbe *troppo* bello. :-)
 
Comunque, da quello che ho capito, sembra che le istruzioni TSX aiutino 
quando i thread accedono in *scrittura* alla stessa zona di memoria 
protetta (in ambiente windows) con EnterCriticalSection(); un esplicito 
riferimento sembra venir fatto, ad esempio, qui:
http://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#Hardware_Lock_Elision
 
nell'ultimo capoverso.
Attualmente, nessuno dei miei programmi utilizza le "Critical Section" 
(proprio perché è un metodo di programmazione inefficiente), per cui è 
probabile che non trarrei beneficio dal set TSX, a meno che non ci siano 
altri vantaggi.
 
Ciao
Cristiano

 inoltre il 4770 dispone di una grande L3 di 8MiB
 
A proposito della cache, ho trovato un altro programma scritto anni fa 
che sembra metterla in crisi; guarda che roba:
http://cristianopi.altervista.org/Vel_Partition.pdf
 
Tese: tempo d'esecuzione del programma;
Tthd: sommatoria dei tempi di CPU occupati da tutti i thread;
CPU%: parla da solo. :-)
Preciso che quando la CPU gestisce i thread alla perfezione, Tthd rimane 
costante.
 
Con questo programma, il 4770 � in piena crisi mistica: oltre 2 thread 
gli s'intrecciano i circuiti. :-) Probabilmente non � solo un problema 
di cache.
 
Mi piacerebbe veramente tanto poter provare questo programma su un 
Vishera (l'FX-8350 era tra le possibili scelte per l'acquisto); sono 
convinto che andrebbe meglio.
 
Cristiano

 convinto che andrebbe meglio.
 
beh, non ti resta che rendere pubblico l'eseguibile, magari
c'e' qualcuno interessato a condurre dei brevi test
 
pero' devi considerare che con gli interi avresti 8 core fisici
(ognuno va anche il 30-50% meno di un core Haswell)
mentre in floating ne avresti solo 4 e se non sfrutti le FMA4
le prestazioni saranno molto basse (con consumi in watt
quasi raddoppiati)
 
ciao
luca
 
 


 
dovrebbero essere state introdotte con il recente Win8.1
ma non ho trovato conferme, ad ogni modo quando non si usano
le API di Windows si possono includere le HLE direttamente
nel codice (rimanendo compatibile con le CPU senza TSX
e con impatto trascurabile)
 
ciao
luca
 
 
 

 quasi raddoppiati)
 
Ah ok, allora � probabile che abbia fatto la scelta giusta.
 
Ciao e grazie per tutte le info e le considerazioni fatte.
 
Cristiano
 

 
 
In alcuni casi (pochi purtroppo) un 8350 offre prestazioni
 superiori anche rispetto ad un Core i7 su Socket 1150 se si
 riescono a sfruttare per bene tutte le otto ALU...nonostante ogni
 core abbia un IPC inferiore rispetto alle CPU Intel.
 
 
-- 
 
 
 
 
----Android NewsGroup Reader----
http://www.piaohong.tk/newsgroup
 

 Visto l'interesse per questo thread... :-)
 
oltre al fatto che il gruppo e' poco movimentato, il motivo
potrebbe essere che e' un problema specifico,
magari aprendo un altro thread con una richiesta specifica
potresti ottenere piu' attenzione
 
tra i frequentatori abituali dovrebbero esserci Grizlod (FX-8350)
e 65C02 (FX-4100), a memoria..
 
basta che inserisci un hash per verificare i risultati (aheh)
 
ciao
luca
 
 

 Qui non si parla di programmazione in senso sretto comunque...:-)
 
in effetti c'e' anche questo rischio.. ma ce la siamo cavata bene (aheh)
 
ciao
luca
 
 
 

 (anche se a caro prezzo)
 
Non sono un esperto di CUDA (e quindi non so scrivere il codice per 
trarne il massimo vantaggio), ma la prova che ho fatto di recente con 
una 660 mi ha fatto apprezzare il 4770 e la sua (o le sue?) unità di 
predizione dei salti.
CUDA va in crisi quando un blocco di 32 thread (chiamato "warp") non può 
condividere lo stesso flusso di processo a causa di salti dipendenti dai 
dati. Il risultato è stato che centinaia di thread della 660 hanno 
raggiunto appena il 50% della velocità di 9 thread della 4770.
 
Questo per dire che condivido ciò che dici e aggiungo che il core i7 può 
essere valido anche in sostituzione di CUDA (se non altro per quanto è 
più facile scrivere il multi-thread per CPU rispetto a quello per CUDA).
 
Cristiano

 in effetti c'e' anche questo rischio.. ma ce la siamo cavata bene 
(aheh)
 
LOL
 
 

 Qui non si parla di programmazione in senso sretto comunque...:-)
 
In effetti può valere la pena postare anche in un gruppo di 
programmazione; vedo di cercare un ng più adatto...
 
Cristiano
 

 Non a caso nel bios c'e' sempre la possibilita' di disattivarlo ;)
 
Un appunto che (da profano) mi viene spontaneo fare a Intel � che 
avrebbe dovuto prevedere un'istruzione per abilitare/disabilitare l'HT.
 
Cristiano

 
 
Si ma se l'applicativo CUDA compliant (o comunque riesce ad appoggiarsi 
alla gpu per eseguire calcoli di tipo parallelo) sfrutta per bene i 
moduli SMX della GPU, allora si possono ottenere risultati nettamente 
superiori ad un 4770...non ci sono paragoni proprio, per non parlare 
dell'ambito HPC :)
 
 
 

  
 
Ce ne sono diversi...se digiti la parola "programmazione" ne saltano 
fuori piu' di 20:
 
http://www.mynewsgate.net/frameset.php?w=1440&ng=
 
 
 
 

 l'HT.
 
considerando che i vantaggi sono molti di piu' degli svantaggi
e che l'HT e' legato all'hardware (cioe' puo' migliorare
in efficienza ad ogni microarchitettura), direi che non
c'e' nessun motivo per disabilitarlo via software
 
tranne che per condurre test o per applicazioni
su cui si ha il controllo totale (codice e compilatore),
ma in questi casi si puo' disabilitare via BIOS/UEFI
o con gli strumenti del sistema operativo
 
 
curiosita' hardware, stavolta, sui test che hai eseguito:
cioe' indicazione di frequenza di lavoro, tensione vcore,
temperatura massima raggiunta e potenza dissipata
(indica anche s.madre, dissipatore, alimentarore,
impostazioni risparmio energetico OS e BIOS/UEFI, ecc..)
 
tra i diversi programmi puoi usare CoreTemp 1.0rc6 ,
hwmonitor 1.22, AIDA64 3.20, CPU-Z 1.67 (o piu' recenti)
 
 
non e' una curiosita' fine a se stessa, mi serve per capire
quanto la tua applicazione carica/stressa la CPU,
non inteso come % del carico di lavoro, ma come potenza (watt)
 
questo varia in base all'applicazione e da come utilizza le
risorse: unita' integer e float, SSE/AVX, cache, ecc..
 
ad esempio, in base a test condotti con i5-2500K (leggermente OC)
e diversi sw, ho potuto stimare le seguenti % di carico/stress :
 
 55% - WinRAR, x264 1st pass, AIDA CPU stress
 65% - Fritz Chess, CineBench, x264 2nd pass, AIDA cache stress
 80% - Prime95 blend
100% - Prime95 small/large FFT, AIDA FPU stress
 
il 100% equivale ad una potenza dissipata della CPU
di circa 120W (circa 80W senza overclock)
 
ciao
luca
 
 

 risorse: unita' integer e float, SSE/AVX, cache, ecc..
 
3 dei 4 programmi che ho usato come test credo che usino tutto ciò che 
c'è dentro alla CPU. :-)
 
Ciao
Cristiano

 HWiNFO64 dice 64 W, ma non so come li calcola.
 
viene letto un registro interno alla CPU, usato dalla stessa
per il risparmio energetico e per il turbo, c'e' anche
una complicata formula (l'avevo trovata su un documento Intel)
 
potrebbe essere utile per analizzare il comportamento
delle tue applicazioni in base al numero di thread
(anche quella "ostica")
 
 
ho letto gli allegati inviati per email (a proposito, grazie)
e credo anch'io che l'applicazione sfrutti a dovere la CPU,
forse 64W non e' il massimo raggiungibile per un i7,
prova con Prime95 2.81 smallFFT (usa le FMA3) e leggi
il sensore power (W), e' per avere un tetto massimo
da usare come riferimento (con i5-4570 si arriva a 59W)
 
ho notato che le temperature sono relativamente basse,
trattandosi di Core i7 Haswell, che dissipatore hai installato ?
 
se hai un alimentatore compatibile, controlla se e' abilitato
lo stato C7 nel BIOS/UEFI , il sensore power indica 4-5W
e dovrebbe scendere ad 1-2W in idle
 
ultima osservazione, sembra che la CPU lavori alla massima
frequenza del turbo (3,8-3,9GHz) anche quando sono
attivi 4 core, credevo che funzionasse solo con le versioni "K"
 
 
ciao
luca
 
 
 

 attivi 4 core, credevo che funzionasse solo con le versioni "K"
 
Prime95 con 4 thread fa stare il clock intorno a 3,6 GHz.
 
A pieno carico il moltiplicatore si ferma a 37 anzich� a arrivare a 39 
perch� ho la versione non K?
 
Cristiano

 perch� ho la versione non K?
 
credo possa dipendere sempre dal "power limit", siccome
Prime95 sfrutta piu' rirorse, si raggiunge prima il limite di W
(anche a frequenza piu' bassa)
 
prova ad aumentarlo nel BIOS/UEFI (sezione OC Tweaker),
ma non e' detto che salga oltre 3,6GHz (che in teoria e'
la massima frequenza con 4 core attivi)
 
potresti anche provare ad "undervoltare" di 50mV
e rendere meno aggressivo il Load Line Calibration
(riducendo il vcore, si abbassano anche i watt),
ma non ho esperienza diretta con gli i7
 
ciao
luca
 
 
 
 

 ma non ho esperienza diretta con gli i7
 
Nemmeno io, meglio non rischiare... :-)
 
Cristiano

 Infatti Prime95 v28.1 arriva a 86 W e 3,4 GHz.
 
sempre con il power limit in automatico ?
 
ciao
luca
 
 
 

 sempre con il power limit in automatico ?
 
Non saprei, io non so come mettere il power limit in automatico, eseguo 
il programma senza impostare niente di particolare.
 
Cristiano
 

 eseguo il programma senza impostare niente di particolare.
 
tramite BIOS/UEFI (sezione OC Tweaker) , di default e' impostato
in automatico, prova con 125 o 150 , tanto non li raggiungerai mai
senza overclock e non viene pregiudicata l'affidabilita' del sistema
 
 
ciao
luca
 
 
 

 senza overclock e non viene pregiudicata l'affidabilita' del sistema
 
Ci sono moltissime voci; ne vedo 2 che potrebbero fare al caso nostro: 
"Long duration power limit" e "Short duration power limit", nelle quali 
posso scrivere valori a piacere (non c'è un elenco tra cui scegliere). 
Non essendo uno smanettone, prima di fare casini vorrei avere la 
certezza di armeggiare con il parametro giusto.
 
Cristiano

 avere la certezza di armeggiare con il parametro giusto.
 
ti basta impostare 125W , 150W o anche 200W sia su Short
che su Long Power Limit, puoi anche aumentare il
"Primary Plane Current Limit" a 200A o piu'
 
per leggere i valori attuali puoi usare HWinfo (sezione CPU)
 
ripeto: sono dei limiti che non pregiudicano il funzionamento
della CPU
 
e' solo un tentativo, sperando che con un limite piu' alto
Prime95 con le FMA3 salga di qualche MHz, in ogni caso
con le altre applicazioni non dovresti notare nessuna
differenza
 
 
 
ciao
luca
 
 
 
 

 per leggere i valori attuali puoi usare HWinfo (sezione CPU)
 
Adesso si superano i 115 W! E anche la tensione è parecchio aumentata. 
Ti mando il log... Da paura! :-)
Fa impressione vedere un programma che sfrutta così a fondo ogni 
circuito della cpu.
 
Cristiano

 circuito della cpu.
 
complimenti per i 114W (!), la temperatura si avvicina ai 90°C
(solo sul core0, gli altri sono intorno agli 80°C),
per fortuna hai l'Arctic altrimenti avresti dovuto usare
il ghiaccio secco (aheh)
 
 
se ti va di sperimentare, potresti ridurre la tensione vcore
della CPU di 50mV (-0,050V), meglio se mediante offset,
sempre nella sezione OC Tweaker, se il sistema resta
stabile con Prime95 o con le tue applicazioni, puoi
aumentare a 75mV, altrimenti scendi a 25mV (o default)
 
con questo undervolt, si abbasseranno sia i W dissipati
che le temperature, il passaggio successivo prevede la
riduzione della tensione della cache (piu' sensibile)
oltre ad ottimizzazioni varie
 
 
solo per curiosita', tutto questo senza stressare la GPU integrata,
altrimenti saliresti di altri 20-25W (limite permettendo),
ad esempio con FurMark o con il test di AIDA
(da lanciare simultaneamente a Prime95)
 
 
ciao
luca
 
 

 della CPU di 50mV (-0,050V), [...]
 
Sě, mi va di sperimentare, ma solo a livello software. :-)
 
Cristiano

 a migliorare le prestazioni con il tuo programma
 
In un programma che sto scrivendo, è saltata fuori la necessità di 
regolamentare l'accesso ad una funzione (scritta da altri) che non 
supporta il multi-thread. Allora ho trovato questo link che riporta il 
risultato deludente del nuovo set TSX:
http://software.intel.com/en-us/forums/topic/456300
 
 
Mio personalissimo pensiero: la delusione sul 4770 monta. :-<
 
Cristiano

Aggiungo questo link sulle TSX in modo d'avere una sorta di raccolta di 
riferimenti sulle prestazioni di un set di istruzioni di cui poco si sa:
 
http://natsys-lab.blogspot.ru/2013/11/studying-intel-tsx-performance.html
 
 
Rispetto al link che ho postato in precedenza, si vede che almeno per 
piccoli quantitativi di memoria, il set TSX ha una qualche utilit�.
 
Cristiano

 piccoli quantitativi di memoria, il set TSX ha una qualche utilità.
 
premesso che i due articoli affrontano il problema
lato programmazione (esula un po' dal gruppo)
 
ma se non ho capito male con quel test le prestazioni
migliorano di circa 3 volte nei casi favorevoli (piccoli data set),
mentre peggiorano del 10-20% nei casi sfavorevoli,
principalmente dipende dall'applicazione, ma avendo
pieno controllo sul codice lo si puo' ottimizzare in modo
da trarre il massimo beneficio o almeno nell'evitare
penalizzazioni (sempre dietro l'angolo)
 
 
alcuni giorni fa ho provato il test di SiSoft Sandra,
le operazioni tipiche di un DB (in questo caso un B-Tree)
migliorano di un fattore simile usando le HLE , si va
da un minimo di 1,5x (bassa probabilita' di modifica dei record)
fino ad un massimo di 4,5x (alta probabilita')
 
quasi sicuramente il sw e' ottimizzato per enfatizzare
le nuove istruzioni, ma almeno e' riproducibile
 
 
ho provato sia su Sandy Bridge che su Haswell,
se interessa riporto i risultati
 
 
ciao
luca
 
 
 

 se interessa riporto i risultati
 
Interessa. :-)
 
Come ti dicevo, io personalmente non scrivo mai programmi multi-thread 
che scrivono sulla stessa zona di memoria, ma postare i risultati può 
essere utile per capire qualcosa su queste TSX.
 
Ciao
Cristiano
 


 
il vantaggio di Haswell con le TSX hardware e' palese:
c'e' un picco di prestazioni concentrato entro il 10%
(35Mtps con poche modifiche ai record),
mentre con alta probabilita' di modifiche (oltre il 50%)
si stabilizzano a circa 25Mtps
 
nelle stesse condizioni Sandy Bridge ha un picco
di 8Mtps e si stabilizza a circa 6Mtps (un quarto)
 
osservazione sui due metodi software: il metodo
classico si comporta meglio con alta probabilita'
di modifica anche perche' nel codice ci sono poche
istruzioni aggiuntive che si occupano delle collisioni,
mentre il metodo piu' granulare read/write
da' il meglio di se' quando la probabilita' e' bassa
(poche modifiche, poche collisioni, meno codice aggiuntivo
eseguito)
 
con poche modifiche si sale da 7-9Mtps (classico)
a 15-20Mtps (r/w), mentre con molte modifiche
si scende da 6-7Mtps (classico) a 5-6Mtps (r/w),
come sempre ci sono pro e contro
 
 
per il momento mi fermo, ci sarebbe il secondo test
che prevede solo ricerca ed aggiornamento dei record,
con risultati simili, si passa da un minimo di
5,7Mtps di Sandy Bridge (metodo sw classico)
ad un massimo di 21,7Mtps con Haswell (TSX HLE)
 
 
non so quanto tutto questo possa aiutarti, dipende molto
dal tipo di elaborazione, dal numero di collisioni previste,
dal codice implementato, ed infine dai limiti hardware
della CPU come riscontrato nei due articoli che hai citato
(sempre che non si tratti di bug del kernel Linux)
 
ciao
luca
 
 
 

 (sempre che non si tratti di bug del kernel Linux)
 
Diciamo che non mi aiuta nel senso che scrivo sempre i programmi in modo 
che non ci siano collisioni in scrittura, ma mi aiuta a capire che 
faccio bene a fare come faccio. :-)
 
Come dicevo, chiudo qui; per essere OT, ho portato avanti la faccenda 
fin troppo.
 
Ciao e grazie
Cristiano