Newsgroup: it.comp.hardware.cpu
Titolo: Domanda veloce veloce

Per il ripping video (non so se ho scritto giusto) č meglio un Pentium 4
540 3.2 GHz o un athlon 64 3400+ SK754?
Un'ultima domanda: come vi sembra la AsRock K8 Combo-Z x Athlon64?
grazie
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Un'ultima domanda: come vi sembra la AsRock K8 Combo-Z x Athlon64?
Ihmo č meglio che prendi una MB che abbia un singolo Socket... possibilmente
quello 939.

casomai ti serve una cpu per editing, encoding e streaming video! mah per 
questo sono leggermente avvantaggiati i p4! aspetta altri pareri 

qui principalmente conta maggiormente la "mera" frequenza di clock...
questa faccenda della "mera frequenza di clock" proprio non mi piace,
non e' questione di frequenza quanto di implementazione diversa del
processore che e' piu' adatta a questo scopo...
altrimenti qualcuno  potrebbe creare un processore a 9ghz con un ipc
di 0,001  e dire che e' il processore migliore al mondo per il
videoediting... :-P
-- 
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Coloro che sono disposti a farsi togliere alcune liberta' 
essenziali per ottenere un piccolo, temporaneo senso di sicurezza
non meritano ne liberta' ne sicurezza. [B. Franklin]


Beh, perchč no... ^__^

 la "solfa" non cambia.
Mmm.. credo che quello che avvantaggia maggiormente gli intel nei programmi 
di videoediting sono due cose, Hyperthreading & SSE1/2/3, IMHO il clock è 
relativo ora come sempre.

 relativo ora come sempre.
In questi ambiti applicativi invece conta anche quello...

 In questi ambiti applicativi invece conta anche quello...
Mi spiace ma non mi convinci ;-) La efficienza di alcune istruzioni macchina 
tipo quelle SIMD non può essere raggiunta da banali incrementi di clock, 
devi parlare di incrementi 2x, 3x, 4x, se ciò non avviene vuol dire che quel 
programma semplicemente non è stato ottimizzato per le SIMD e nel 
videoediting, e grafica in generale queste istruzioni vengono utilizzate 
abbastanza :-) 

 tipo quelle SIMD non può essere raggiunta da banali incrementi di clock,
Bastano anche 200MHz in più alle volte per notare miglioramenti...
Come ti spieghi allora che un A64 3000+ in questi applicativi vada meno
di un Athlon XP 3200+? Se non si tratta di frequenza di clock allora
qual'è il motivo?

se vuoi fare qualcosa di meraviglioso la cpu top per questi lavori secondo 
me è un bello xeon a 64bit se vuoi ( o se sfrutti linux) oppure a 32 bit! 
con cache bella grossa e  tutto quanto! 

 qual'è il motivo?
La risposta IMHO sta tra le righe in alto ;-)
Probabilmente le estenzioni multimediali degli Athlon 64 sono state 
riportate pari pari a quelle dell'Athlon XP, ricordo che le SIMD sono 
un'area a parte sul chip che può essere stata anche non necessariamente 
ritoccata nel passaggio ai 64bit, per cui mettendo a confronto le due cpu 
quella con il MN più alto la spunta :-P
Purtroppo finchè non verranno sfruttati i 64bit le differenze tra queste cpu 
non saranno mai così marcate e poi il Barton 3200@400 è sempre una signora 
cpu troppo competitiva anche per gli Ahtlon64 ;-) 


su -questo- potrebbe contare il clock puro... l'ipc degli amd per
quanto riguarda le alu e fpu e' immensamente superiore di quello
intel, mentre le unita' "multimediali" (chiamiamole cosi' per
semplicita') hanno un ipc piu' o meno pari.
quindi se clock per clock sono alla pari, nei programmi che usano
quasi esclusivamente queste il maggior clock dei p4 porta un vantaggio
non da poco.
pero' rimane il mio punto: di principio dire "in questi compiti conta
il clock puro" e' una semplificazione eccessiva... "il clock puro" non
significa assolutamente niente in informatica, se non come
moltiplicatore dell'unita' di misura dedicata a Hertz.... :)


 non da poco.
E' anche il mio parere, per quello che conta ;-).
Effettivamente sarebbe il caso che AMD lavorasse alla decodifica delle 
istruzioni SSE (il collo di bottiglia non può che essere la decodifica, 
visto che le istruzioni vengono eseguite dalle stesse unità FPU). E' il 
colmo che certi vantaggi dell'architettura AMD (FPU) non possano essere 
sfruttati perché certe istruzioni vengono interpretate con un microcodice 
non ottimale.
--
Xelloss 


Beh, ad esempio nei giochi invece un A64 3000+ la spunta senza
problemi su un XP3200+...:))

 x86-64 invece dovrebbero in teoria essere + performanti sugli amd.
Il discorso qui è un po' diverso. Se le SSE rendono meglio sui P4 è perché
appunto i P4 sono cloccati a frequenze superiori. Le estensioni a 64 bit di
Intel, invece, sono semplicemente "buggate", nel senso che non sono ahimé
compatibili al 100% con AMD64.
MaxArt

compatibili al 100% con AMD64.
il problema principale e' che il supporto ai 64bit e' soltanto
"superficiale" termina all'unita' di decode, internamente il
processore mantiene i registri a 32bit.
ogni istruzione a 64bit viene spezzata in due da 32bit e distribuita
alle due alu che, visto che non possono lavorare in sincrono, eseguono
le due parti sfalsate di mezzo ciclo (perche' ovviamente le alu dei p4
lavorano con clock doppio rispetto al resto del processore).
di conseguenza in modalita' 64bit le prestazioni sugli interi sono
dimezzate.
probabilmente prima o poi intel riuscira' a far funzionare le alu dei
p4 a pieno clock, in quel caso potranno unire le due alu a 32bit in
una "superalu" da 64bit - per il momento pero' ne escono piuttosto
male...


 male...
Non e' solo quello il problema, "rimappando sul P4" le istruzioni
x86-64 hanno mantenuto tutto il resto riguardante la mappatura della
memoria fisica, il socket (pensato per cpu a 32bit con max. indirizzamento
a 36bit) e tutta la mappatura del meccanismo di gestione dell' I/O
e del DMA tra la cpu ed il resto del sistema.
E' per questo che le beta di Windows XP per x86-64 non funzionavano
sui Nocona, tutta la parte di mappatura della memoria e di gestione
del DMA era incompatibile (fortunatamente e' una cosa che si vede
solo a livello di S.O., le applicazioni non risentono direttamente
di questo).
Comunque la differenza tra K8 e Nocona e' tale che proprio quando
il sistema arriva al massimo carico in termini di I/O il K8
risultera' piu veloce (perche puo eseguire trasferimenti
in DMA su qualsiasi posizione di memoria, mentre il Nocona e'
limitato ai primi 4GB di memoria fisica, se il trasferimento
va fatto piu in alto, tocca alla cpu spostare il tutto a colpi
di MOV).
L. Micheletto


Che tristezza.... :(


Beh! In parte sarebbe possibile girare attorno alla cosa
allocando esplicitamente dei buffer per l'I/O nei primi
4Gbyte di memoria (ma deve essere una cosa supportata
direttamente dal S.O.), ma questo richiede modifiche
al S.O. ed alle applicazioni.
Personalmente spero che Intel (visto anche il tempo
che sta impiegando nel preparare le sua cpu x86-64
"per le masse") stia lavorando per risolvere la cosa
allineandosi con il metodo scelto da AMD per i K8.
Non dovrebbe essere necessario cambiare il socket, basterebbe
prevedere una estensione del protocollo di comunicazione
tra northbridge e cpu attivabile da bios, in modo tale
da garantire inalterato il supporto delle schede madri
esistenti con sino a 4Gb di ram.
Resterebbe il limite dei 64Gb di ram fisicamente accessibile
ma tanto Intel cambiera' socket ben prima che tale limite
venga raggiunto.
L. Micheletto


Questo è poco ma sicuro...;-))
Piuttosto secondo te AMD produrrà cpu Dual Core anche per
Socket 939? Infatti la soluzione di Intel dovrebbe essere sicuramente
compatibile con il Socket 775.
Ciao

 direttamente dal S.O.),
Mi pare di aver letto che linux fa così.
--
Xelloss 

 compatibile con il Socket 775.
Per il socket 940 il dual core ci sara' di sicuro, quindi
non dovrebbero avere problemi ad uscire con Athlon FX dual core
su socket 939 (questo ovviamente se per loro risultera' conveniente).
L. Micheletto


Infatti, ma la cosa regge sino a quando non arrivi al punto
in cui i 64bit di indirizzamento servono *davvero*, poi ti ritrovi
a dover copiare i dati da un buffer all' altro, idem per la memoria
che viene paginata.
Per ora puo bastare, ma in futuro e' sperabile che pure Intel
ponga rimedio alla cosa.
L. Micheletto

 ponga rimedio alla cosa.
Alla fine questa limitazione lascia il tempo che trova, per un sistema 
desktop il decadimento delle prestazioni oltre il limite dei 4GB di ram non 
è affatto un problema ;-)
Quello che conta IMHO è tutto il resto, ossia avere a disposizione nuovi 
registri dati a 64bit general purpose che uniti alle unità SIMD e all'NX bit 
possono finalmente davvero svecchiare l'ISA x86.
Un ulteriore mazzata verrà dalle soluzioni dual core 64bit.. 

registri dati a 64bit general purpose
che le attuali implementazioni di em64 non hanno afaik...


 che le attuali implementazioni di em64 non hanno afaik...
Azz.. ma allora come saranno implementati i 64bit? Non dirmi che 
richiederanno uno stato prticolare della cpu per essere visibili magari 
utilizzando 2 registri a 32.. 



appunto, usano due registri a 32bit.
l'unita di decode spezza una istruzione x86-64 in due risc86-32.
in pratica le uniche modifiche sono sull'unita' di decode,
internamente il p4 non e' cambiato minimamente - cosi' sono riusciti a
mettere l'etichetta "64bit" con investimenti microscopici.
dei risultati pratici ovviamente importa poco ad intel.


 dei risultati pratici ovviamente importa poco ad intel.
Mmm.. dove hai reperito queste info?
A naso direi che l'implementazione dei 64bit possa essere come dici tu solo 
per i registri indirizzi ma NON per quelli dati..
Del resto il link di seguito 
http://www.anandtech.com/linux/showdoc.aspx?i=2158
 non si spiegherebbe 
alrimenti, oppure gli Xeonō@EMT64 hanno core diversi dai futuri P4@64bit?? 


http://www.anandtech.com/linux/showdoc.aspx?i=2158
 non si spiegherebbe 
non e' che ci sia molto da spiegare li, hai un processore ultra-top
confrontato con uno di fascia medio-bassa...
btw, hai notato che crollo di prestazioni viene con l'ht in modalita'
64bit?


 64bit?
Parli del MySQL?? Già.. :-( credo che il risultato sia giustificabile su due 
fronti, ossia il memory controller integrato sugli Athlon64 e probabilmente 
il notevole overhead causato dal dispatch delle istruzioni a 64bit sui 
P4EMT64 unito alla gestione di più thread, quasi quasi collassa :-)) 

 che le attuali implementazioni di em64 non hanno afaik...
Porca vacca questa mi era sfuggita!
Insomma, da come sono descritte 'ste EM64T non solo non sono 100%
compatibili con le AMD64, ma proprio sono una mezza cagata!!! o__O
MaxArt

Porca vacca questa mi era sfuggita!
contrordine, qui mi sono sbagliato io, gli emt64t hanno 16 registri
gpr a 64bit e 16 registri simd a 128bit.


 gpr a 64bit e 16 registri simd a 128bit.
Ah, ok, allora diciamo un quarto di cagata ;-)
MaxArt

 Parli del MySQL?? Già.. :-(
Io direi con Ubench... ma non ho capito se lavora a 64 bit.
MaxArt


Beh, allora non è proprio un cesso... ;D