Newsgroup: it.comp.hardware
Titolo: Tempi di elaborazione tra AMD e INTEL

Salve,
    non sapendo dove postare mi affido al vostro giudizio.
Stiamo testando in ufficio un programma scritto in C++ e compilato su un
portatile AMD 2800+ 512 MB ram. Poi facendolo girare sullo stesso portatile
il primo step di operazioni viene eseguito in 5 minuti. Poi abbiamo testato
lo stesso programma su una workstation Intel con 2 processori 3,2 Mhz e 3 GB
di ram e ha impiegato 11 minuti per elaborare il 1° step. Data la grande
differenza di tempi, non contenti, abbiamo testato su un fisso AMD 2000+ e
il tempo per il 1° step è di 1 minuto sopra il primo AMD quindi 6 minuti (è
anche meno potente). Altri Intel sono tutti mediamente sugli 11 minuti.
Ma com'è possibile? Abbiamo ricompilato il prog anche su un Intel ma i
processori AMD mantengono sempre un enorme vantaggio! Ma sul serio è così
evidente?
Sistemi Win XP SP2 32 bit
Grazie!

"aaa" <a...@aaa.aa> ha scritto nel messaggio
news:1706g.17800$TK.1...@tornado.fastwebnet.it...

Avete usato anche i compilatori Intel?
Comunque bisogna vedere se il programma sfrutta in maniera pesante l'unità
fp e se è multithread...
Ti consiglio di postare anche su it.comp.hardware.cpu


	ciao, rz.

aaa ha scritto:

Non ha alcuna importanza su quale macchina compili il programma, l'unica 
cosa che conta e' come sono impostate le opzioni di ottimizzazione del 
compilatore C++.
Se il programma non usa il multithreading, non potra' trarre alcun 
vantaggio dall'esecuzione su una macchina multiprocessore (usera' una 
sola CPU).

"acc" <sp...@here.thanks> ha scritto nel messaggio
news:4459d460$0$29724$4faf...@reader2.news.tin.it...

E comunque si evidenzia che in ambito float classico le cpu Intel son
veramente scarse... -_-

veramente scarse... -_-
Per non parlare del fatto che che CPU Intel sono dei "tritacarne" per
grosse masse di dati, ma non sono molto "agili".
Avendo pipelines molto profonde, ed essendo fortemente ottimizzate per
istruzioni SIMD, forniscono prestazioni molto scarse con software i cui
"salti" sono difficilmente prevedibili. :-(
Ciao! :-)
-- 
-----
  | NFINITY is so far as you want to see.
-----
Se vuoi rispondermi in E-Mail, ripassa le divisioni. ;-)


I quali tranne che in pochi casi è la regola...per fortuna Intel l'ha capita
e con Conroe la situazione, almeno in ambito desktop dovrebbe migliorare
radicalmente :))

 veramente scarse... -_-
Concordo in parte, "scarse" e' una parola grossa e qualche tempo fa era 
rivolta a AMD...  Ora le FPU di AMD sono senz'altro migliori di quelle 
di Intel, pero' se mi supera una Ferrari non significa che la mia 
utilitaria sia da buttare via!
PS: non sono neppure sicuro che si parlasse di float, almeno non lo vedo 
specificato nel post iniziale :-?

 specificato nel post iniziale :-?
Altrimenti non si spiegherebbe tutta questa differenza...

>Altrimenti non si spiegherebbe tutta questa differenza...
La domanda sorge spontanea: perchè un compilator c++ dovrebbe usare
l'FPU?


E perchč no?
Vatti a leggere in proposito le risposte su it.comp.hardware.cpu..........

radicalmente :))
I casi sono due: o realizzano davvero il "Core" come si deve, o Intel
cedera' definitivamente ad AMD lo scettro storico di leader nella
produzione di CPU.
Le premesse ci sono: dalle prime indiscrezioni si parla di riduzione della
profondita' delle pipelines da 41 stadi a circa 13, e dell'incremento in
dimensioni ed in prestazioni della cache di secondo livello (4Mb condivisi
fra i due core dei primi modelli), il tutto condito -finalmente- da una
decisa RIDUZIONE dell'assorbimento energetico.
Staremo a vedere. :-)


 Staremo a vedere. :-)
Dai primi test Conroe sembra promettere moolto bene...:)

Dai primi test Conroe sembra promettere moolto bene...:)
Incrociamo le dita. :-)
Soprattutto perche' stavolta, pare abbiano deciso di realizzare il nuovo
Conroe compatibile elettricamentente e meccanicamente con il socket i975X
attuale. Anche il "Merom", la versione portatile, dovrebbe essere
retrocompatibile con il Pentium M, e la cosa risulterebbe moooooolto
interessante per i portatili, che non dovrebbero nemmeno cambiare
dissipatore di calore.
Sempre che, ovviamente, vengano rilasciati appositi aggiornamenti del
BIOS. :-)



Già...;-)

Ovviamente il Socket rimane sempre quello, ovvero il 775 LGA.
Ho letto, ma il bello -in teoria- dovrebbe essere proprio qui.
Diminuendo la profondita' delle pipes e, soprattutto, abbassando il clock
effettivo di un 20% circa, Intel calcola di poter ridurre l'assorbimento
energetico del 50/60%. Integrando due core nella CPU, a fronte di una di
una diminuzione del clock, l'assorbimento totale rimarra' lo stesso -o
leggermente inferiore- dei vecchi Prescott (50% x 2), si avra' un netto
incremento di prestazioni globali ed addirittura una diminuzione del
thermal design, quindi addio ai vecchi dissipatori titanici da 700gr da
inchiodare al case con 4 viti e con la retro-mascherina.
Ora, se l'assorbimento energetico di Conroe sara' lo stesso -o minore- dei
P4, anche i VRM dovrebbero reggere le nuove CPU, no?
Il tutto, sperando che a Santa Clara facciano sul serio. ;-)


 ha scritto nel messaggio
news:052p529kmfn92mt52...@4ax.com...

La questione è un pò complessa...infatti anche se il consumo delle nuove cpu
sarà inferiore si deve comunque riprogettare il circuito di alimentazione
sulla MB per rispettare le nuove tolleranze; che siano verso il basso o
verso l'alto poco importa.
Comunque vedremo quando saranno realmente disposnibili per avere un
riscontro su questo fatto...al momento rimane il dato che secondo Intel il
chipset ufficialmente destinato ad accogliere i Conroe sarà il chipset 965 e
seguenti.

 Altrimenti non si spiegherebbe tutta questa differenza...
Un software scritto male influenza parecchio le prestazioni, molto di 
piu' di un hardware progettato bene.

 La FPU dei K6 non era inferiore a quella dei Pentium,
Erano abbastanza inferiori purtroppo... ad esempio non erano manco
pipelined.
Si sono risollevati parzialmente (specie ai giochi) con le istruzioni
3DNow!, anche se purtroppo ben pochi sono stati programmati per sfruttarle.