Newsgroup: it.media.video.produzione
Titolo: Intel vs AMD, ancora...

Mi sono un po' informato, mi pareva un po' troppo grossa la bomba di 
Intel che castra i software compilati col suo compilatore che girano su AMD.
E la verita', come al solito, sta nel mezzo.
Il compilatore Intel e', per fama e test, uno dei migliori esistenti, 
genera codice pulito e che corre, come si dice...
Quando il compilatore trova delle istruzioni che puo' ottimizzare, nello 
specifico delle operazioni eseguibili in parallelo grazie alle SSE3 
(presenti solo su Intel) allora genera del codice differente cehs 
ffrutta queste funzionalita'.
Ovviamente per poter supportare anche le CPU non Intel, all'inizio di 
quel pezzo di codice viene eseguito un test per controllare il tipo di 
CPU per cui si sta compilando.
Questa procedura viene effettuata in automatico dal compilatore, oppure 
puo' essere pilotata dal programmatore, che grazie ad uno swich nella 
riga di comando dice al compilatore cosa fare quando il codice puo' 
essere ottimizzato.
Per farla brutale e far capire anche ai non addetti ai lavori :
[PseudoCodice]
Istruzione 1 : Apri il fotogramma
Istruzione 2 : Leggi il primo pixel
Istruzione 3 : Leggi il secondo pixel
Istruzione 4 : Leggi il quarto pixel..
....
Istruzione 20 : Somma i valori dei pixel
Istruzione 21 : Calcola la media
Istruzione 22 : Riscrivi il risultato nel pixel 1
[Fine Pseudo Codice]
Questo a spanne e' il codice per fare un gaussian blur...
Su Intel con SSE32 il compilatore intel lo farebbe diventare qualcosa di 
simile :
[PesudoCodice]
Istruzione 1 : Apri il fotogramma
Istruzione 2 : Carica i 20 pixels nei registri SSE3 in un unico ciclo di 
clock
Istruzione 3 : Fai la media dei registri SSE3
Istruzione 4 : Riscrivi il risultato
[Fine Pseudo Codice]
Notate la potenza delle istruzioni in parallelo su SSE (tutte le 
versioni di SSE, non solo la 3)
Ora... il problema sorge qui, nel codice che viene generato per le CPU 
non Intel...
La versione 8 del compialtore di Intel aveva un baco enorme, ovvero in 
alcuni casi il codice AMD di questo esempio CRASHAVA, non solo era 
lento, ma crashava del tutto.
Segnalato ad Intel il problema sono uscite due patches, una per il 
compialtore nuovo (8.0) e una per i precedenti (7.1)
Il compilatore nuovo cosa fa ora ? Semplicemente controlla che la CPU 
sia "genuine intel" e in quel caso genera istruzioni SSE2 e 3, molto 
performanti.
Nel caso invece di una CPU AMD viene generato del codice x86 pulito.
Questa e' la cosa che "castra" i software compilati col compilatore 
Intel su macchine non Intel.
Non vengono usate le ottimizzazioni proprietarie di Intel che pero' sono 
"simulate" nelle CPU AMD.
AMD e' in grado di esegure codice SSE ed SSE2, molto piu' performante 
del codice x86 (non esageratamente date le ottimizzazioni interne delle 
CPU, pero'....)
Nella versione 7.1 del compilatore invece in caso di possibile 
ottimizzazione su CPU intel vengono generate (se presenti) istruzioni 
SSE3, mentre su CPU AMD vengono generate istruzioni SSE1.
LA questione e' la seguente :
Esiste un metodo per testare se una CPU e' in grado di supportare 
determinati set di istruzioni (tale metodo tra parentesi e' stato 
inventato proprio da Intel !!!)
Sarebbe bene che il codice generato dal compilatore intel utilizzasse 
questo metodo piuttosto che cercare la stringa "genuine intel", in 
questo modo se una CPU e' stata costruita da "Piripacchio Electronics" 
ma supporta le SSE3, le possa usare tranquillamente.
Ora come ora invece se una CPU non restituisce "genuine intel" come 
tipologia, non utilizzera' mai le ultime ottimizzazioni per il calcolo 
parallelo.
E' giusto e normale che il compilatore Intel "preferisca" le CPU Intel, 
ma non e' giusto che se un'altra CPU e' in grado di fare le stesse cose 
non venga sfruttata.
Todo qui....
Ultimissima nota che vorrei fare inoltre a chi fa test di prestazioni, 
fate ATTENZIONISSIMA, i due PC devono essere PIU' CHE IDENTICI per poter 
fare dei test sensati sulle CPU.
Gia' solo il test del thread precedente, dove una macchina aveva 512MB e 
l'altra 1.5Gb....beh... e' parecchio falsato dato che una macchina con 
512Mb swappera' molto di piu' su disco (cosa lentissimissima) dell'altra 
con piu' ram.
Per testare la CPU (altro discorso vale per HD, schede video etc..) le 
due macchine devono avere mobo di fascia simile, alimentazione simile, 
bus e HD simili, ram simile etc.etc...una minima differenza porterebbe a 
risultati parecchio diversi e falserebbe il test delle CPU.
-- 
rIO.sK

 con piu' ram.
già... il problema è che quella con 512 mb va molto, ma molto più veloce di 
quella con 1,5gb!!!!
Ci capisco sempre meno, ma ho notato, in rete, che altri hanno i miei stessi 
risultati, con Cleron vs Athlon. 

 E la verita', come al solito, sta nel mezzo.
Quindi, per riassumere, con la patch del mitico lucaMbat mi sembra di capire
che la situazione rimanga invariata? O sbaglio? E la soluzione quindo quale
potebbe essere?
Giuvą
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 
Esattamente....
-- 
rIO.sK

 
No, non rimane invariata.
La patch elimina il test per "genuine intel", un po' come si fa per i 
crack  ;D
Per cui la tua CPU AMD esegue il codice che in origine era destinato 
alle CPU Intel... tutto qui.
Questo non significa pero' che SICURAMENTE il software andra' piu'ģ 
veloce... sia chiaro, e' solo probabile.
-- 
rIO.sK

 fare dei test sensati sulle CPU.
A me sembravano dei test sul software, non sull'hardware. Infatti chi aveva 
un AMD doveva patchare il software, senza cambiare di una virgola 
l'hardware, per vedere se con la patch girava meglio. Non erano prove 
comparative sull'Hardware.
Cmq secondo le tue indicazioni (molto utili), mi pare evidente che la grossa 
differenza a livello di codice sia riscontrabile solo nelle SS3, che su AMD 
non verrebbero usate (e siccome le SS3 sono *molto* usate per i filtri 
video, e' chiaro che la differenza di prestazioni e' evidente). Siccome le 
SS3 esistono solo dai core Venice in poi (cioe' dai 3200+@939 in su) il test 
con la patch a questo punto bisogna provare a farlo con questa classe di 
processori qui. Io appena libero la macchina, mi installero' PPro e provero' 
(a casa sto' con un 3700+ Venice cloccato a 2.4 Mhz), quindi il test posso 
farlo.
-- 
BArrYZ
[_Sign?_] 

 Derrick wrote:
Sono solo io che non vedo i messaggi di Derrick?
-- 
BArrYZ
[_Sign?_] 

 Sono solo io che non vedo i messaggi di Derrick?
no Barry, neppure io vedo me stesso :(. Probabilmente non vedrò neppure 
questo... 

 questo...
Ora finalmente ti vedo! :-D
Cmq penso sia Powernews che come al solito ha un'affidabilita' prossima allo 
zero assoluto.
-- 
BArrYZ
[_Sign?_] 

 Ora finalmente ti vedo! :-D
sì, anch'io mi vedo, però ho perso il mio precedente post e quello di Giuvà. 
Server Libero adsl... mah, è da qualche settimana che fa così, che palle.
Ripartono le prove con Luca, sull'altro 3d; ora metto giù un progetto-test 
un po' più cattivo, chissà che gira gira non ne esca qualcosa di buono... 

 compialtore nuovo (8.0) e una per i precedenti (7.1)
Sia la versione 7 che la versione 8 hanno sempre avuto il controllo
"GenuineIntel". Il baco c'era se la CPU non supportava le SSE1 e le
CPU AMD apparivano appunto senza SSE1 per via della presenza del malefico
controllo "GenuineIntel". Intel ha corretto (per modo di dire...) l'errore
disabilitando completamente il supporto SSE1; rimane quindi solo
l'ottimizzazione per SSE2 (e CPU Intel) mentre viene eseguito codice
standard x86 negli altri casi, sia per la versione 7 che per la 8 del
compilatore.
Ciao,
  Luca

 per il 3D e l'audio).
Sei sicuro? Io sapevo il contrario, e cioe' che nell'implementazione del 
trattamento attuale dell'effettistica e del compositing per il video 
(specialmente il compositing con layer gestibili in uno spazio 3D, come 
praticamente ormai gestiscono tutti i principali programmi di 
editing/compositing), le istruzioni che pompano molto sono proprio le SS3.
-- 
BArrYZ
[_Sign?_]

 le istruzioni che pompano molto sono proprio le SS3.
No, le SSE3 servono quasi esclusivamente per la grafica 3D e la
trasformata di Fourier (DSP audio). C'e' anche una istruzione (LDDQU) che
ottimizza l'accesso alla cache durante la ricerca del moto (utile
nell'encoding video). Peccato che e' fatta "ad hoc" per sopperire ad una
carenza architetturale del Pentium 4: negli AMD64 questa istruzione non
porta vantaggi significativi.
Premiere Pro 1.5 NON utilizza il set di istruzioni SSE3.
Giusto per ricordarlo, sin dal K6-2 (1998) AMD aveva introdotto con il
3DNow! istruzioni che fanno le stesse cose delle SSE3 (2004)... 
Ciao,
  Luca

 3DNow! istruzioni che fanno le stesse cose delle SSE3 (2004)...
Chi ha il pallino dei videogiochi, se lo ricorda benissimo ;-)
-- 
BArrYZ
[_Sign?_] 

 Intel su macchine non Intel.
Il fatto di controllare semplicemente la stringa "GenuineIntel" del 
processore vale a poco da sola. Un "GenuineIntel" può essere tanto un 
Pentium MMX che un Pentium 4 Prescott.
Se però si unisce al controllo sulla stringa anche il controllo dei flag 
CPUID che specificano quale set di istruzioni è disponibile allora il 
tutto ha più senso.
Anzi, il fatto di controllare la stringa "GenuineIntel" indica malafede 
nel comportamento di Intel, che volutamente nega la possibilità di 
utilizzare le ottimizzazioni su macchine Non-Intel ma che comunque hanno 
a disposizione i set di istruzioni estese chiaramente evidenziati 
dall'istruzione CPUID.
Per farla breve, qualsiasi software non fazioso cerca la disponibilità 
delle SSx semplicemente con l'istruzione CPUID, mentre il compilatore 
Intel controlla anche che ci sia un processore Intel.