Newsgroup: it.comp.hardware.cpu
Titolo: AMD64 lento per Calcolo Elementi Finiti

Salve a tutti,
sto svolgendo una tesi sugli elementi finiti e la mia universita' mi ha
messo a disposizione un Packard Bell AMD64 3200+ con 2GB di memoria e
disco fisso da 200 GB. Su tale desktop e' stata installata una Mandriva
2005LE a 32 bit (la 64 mi hanno detto che non era molto stabile) con
Abaqus/CAE 6.5, sempre per x86 e non x86_64. Il problema di questo
computer e' una disarmante lentezza nel calcolo dei sottomodelli: ho
confrontato i tempi con quelli ottenuti dal computer di un ricercatore
dell'universita', che ha a disposizione un Pentium 2.6 GHz con 2 GB di Ram
con Mandrake 10.0 ed il medesimo Abaqus/CAE, ed e' risultato che per uno
stesso sottomodello, nelle medesime condizioni, il Pentium impiega 1 ora
per il calcolo mentre l'AMD64 ben 3 ore. Ora ci stiamo chedendo se il
problema sta nel software a 32 bit oppure se l'AMD64 come processore non
e' in grado di tener testa al Pentium.
Grazie per ogni eventuale risposta
--
Enterprise-E
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Sicuramente sarà un problema software... non esiste che un A64 3200+
possa avere prestazioni del genere se confrontato con un P4 2.6GHz.

 possa avere prestazioni del genere se confrontato con un P4 2.6GHz.
Soprattutto in questo tipo di applicazioni neanche un P4 3.8GHz tiene testa 
a un A64 3200+.
-- 
Saluti
Alec
(27,72+,CT)
Powered by AMD
Athlon64-E3 4200+ 


Credo sia un problema software. Forse il programma č fortemente ottimizzato
per girare su architettura P4. O forse il sistema operativo influisce in
qualche modo, ma ne dubito: prova, se puoi, ad installare lo stesso sistema
operativo.

 a un A64 3200+.
Quindi consigliate di provare una distro a 64 bit su cui installare
Abaqus x86_64? Visto che CAE e' certificato per SUSE, pensavamo di
metterci la 9.3 eval. Ah, forse non aggiunge nulla, ma il PC e' un Athlon64.
Un'altra cosa: sto interessandomi all'acquisto di un desktop e sono
orientato sugli AMD64 perche' sembra che i pc con tale processore
costino meno. Ora, non per lamentarmi, ma non e' che gli Intel sono piu'
performanti?
Grazie ancora.
-- 
Enterprise-E
kirona75 [at] 
gmail.com

 performanti?
No. Sono più performanti gli Athlon64 e poi non costano tanto meno. In oltre 
gli Intel sono dei forni da evitare.
Ecco i consumi:
http://www.hwupgrade.it/articoli/cpu/1313/10.html
Ecco le prestazioni in calcolo scientifico:
http://www.hwupgrade.it/articoli/cpu/1100/10.html


 performanti?
Ciao, come ti hanno detto gli athlon ed in particolare gli athlon 64bit (se
opportunamente supportati)
sono notevolmente più performanti dei pentium4 per quanto riguarda i calcoli
in virgola mobile. Potrei postarti
centinaia di bench ma anche di prove real-life che provano questo. Si
tratterà di un problema software o di qualche incompatibilità. Se ti serve
un desktop per fare calcoli di questo tipo amd non è solo una scelta
economicamente vantaggiosa
ma è assolutamente necessaria anche in considerazione del supporto a 64bit
che è di grande aiuto.
Saluti

probabilmente il packard bell ha un bios penoso con setting terribilmente 
poco ottimali.. per il resto sara' il software che non sfrutta.
i packard bell sono tra i pc di marca piu' lenti che si trovano. 

 testa a un A64 3200+.
Ma tu le cose che dici le dici per fede o perché non sai contare???
Più sotto hai postato un link dove si vedono chiaramente le seguenti cose:
SuperPI:
P4 560 (quindi 3.6, non 3.8GHz): 174
A64 3200+: 218
- 20%
Seti@Home
P4 560 (quindi 3.6, non 3.8GHz): 106
A64 3200+: 200
- 47%
ScienceMark 2.0 Cipher
P4 560 (quindi 3.6, non 3.8GHz): 12,94
A64 3200+: 13,6
- 5%
ScienceMark 2.0 Molecular
P4 560 (quindi 3.6, non 3.8GHz): 89,4
A64 3200+: 93,3
- 4%
ScienceMark 2.0 Primordia
P4 560 (quindi 3.6, non 3.8GHz): 432
A64 3200+: 425
+1,7%
Su 4 test su 5, il 3.6 (NON IL 3.8), è davanti al 3200+ da un minimo del 4% 
ad un massimo del 50%. In un test l'A64 è davanti dell'1,7%, cioè di nulla.
E' proprio necessario continuare a fare della disinformazione così 
stupida???

 Grazie per ogni eventuale risposta
Intanto sarebbe necessario sapere se questo calcolo è processabile con 
l'ausilio dell'HT, ammesso che il P4 2.6Ghz in questione abbia l'HT (non 
tutti ce l'hanno).
Sotto Windows è abbastanza facile vedere entrambe le cose aprendo il task 
manager su Prestazioni, se ci sono due finestre per due CPU, la CPU ha l'HT, 
e se a questo punto si vedono costantemente i due indici al 100% (durante 
l'elaborazione del sottomodello) è facile ipotizzare che l'HT stia dando una 
grossa mano.
Sotto Linux non so, lascio la parola a chi lo usa.
Per esempio con Seti@Home ci sono differenze dell'ordine del doppio in 
prestazioni, grazie all'HT.
Poi bisognerebbe anche vedere cosa gira in background, se sull'A64 c'è 
qualcosa in background, anche di non particolarmente pesante, è possibile 
che ciò induca ulteriore rallentamento.
In generale una differenza simile di prestazioni, escluso il discorso HT, 
può solo essere dovuta ad un'errata impostazione del sw, ad un bios 
decisamente bacato, ad un'impostazione moooolto conservativa di tutti i 
timing a causa della scarsezza della mb e certamente il nome Packard Bell è 
una garanzia in questo senso.
Certo, prima di scegliere la nuova CPU, sarebbe importante capire se l'HT 
serve o meno.
Se l'applicazione in questione non si avvantaggia dalla presenza dell'HT 
allora non ci sono dubbi che c'è qualcosa che non va, l'A64 3200+ deve avere 
prestazioni sostanzialmente paragonabili a quelle del 2.6, anche migliori di 
un qualche percento, anche del 10-15% in taluni casi, quindi una prestazione 
3 volte peggiore non si può certo attribuire alla CPU. 


Ok, ma anche con le impostazioni piů conservative di questo mondo
non esiste che ci sia una differenza di ben 2 ore tra quelle cpu...;-D

 stupida???
Credo che senza tema di smentita si possa affermare che a parità di clock
(effettivo quello del p4, secondo la nomenclatura di amd per l'a64) l'a64 è
di parecchio più veloce nelle applicazioni scientifiche di un pentium4. Per
quanto riguarda il discorso del seti il risultato negativo per l'amd è dato
dalla mancanza di supporto per l'HT. Quindi in applicazioni che non sono
ottimizzate per l'HT il vantaggio c'è ed è quantificabile nel 10% a favore
di amd. Se poi teniamo conto che un 3200+ gira a 2.0Ghz allora si capisce
quanto sia ben poco ingegnerizzata l'architettura del p4. Già questo, al di
là della scalabilità in frequenza del precotto è un indice del fatto che non
siamo di fronte ad un *buon* processore (vedasi Centrino se non si vuol
andare in casa Amd).
Saluti

 stupida???
LOL... intanto il link l'ho postato a proposito di altro. Le applicazioni di
cui parlavo non sono questi benchmark. Sono applicazioni a carattere
scientifico di cui parlava Entrprise-E.
Per rispondere comunque al tuo commento ti faccio notare che un P4 560 costa
circa 450 euro, contro i circa 180 necessari per un A3200+ che č un po' piů
lento...
Allo stesso prezzo si trova un 530... controllati i benchmark.
Mentre allo stesso prezzo di un 560 si trova un A64 4000+, rivediti ancora i
benchmark.
Infine parlando di consumi... beh... non c'č molto da dire.
Ora all'amico che vuole prendere un desktop per uso scientifico cosa
consigli di spendere 450 euro per un processore che va come uno da 180
all'incirca, per non contare i consumi e il calore?
Quindi mi sa che i conti non te li sai fare tu.


 Quindi mi sa che i conti non te li sai fare tu.
Ma fammi il piacere, per piacere, cerca di imparare cosa significa essere 
seri, poi ne riparliamo.

 che è di grande aiuto.
Ma questo è un altro discorso, l'ho già detto anch'io più volte che per chi 
lancia le elaborazioni scientifiche e poi va a spasso, AMD è un'ottima 
scelta senza controindicazioni, ma c'è una bella differenza tra dire questo 
e dire che un 3200+ ha prestazioni migliori di un Prescott 3.8GHz.

 seri, poi ne riparliamo.
PS: Una persona seria dopo aver detto una sciocchezza simile avrebbe 
scritto: Sì, OK, a volte mi lascio trasportare dal mio entusiasmo per l'AMD 
e perdo di vista la realtà, scusate, cercherò di starci più attento.

 seri, poi ne riparliamo.
Certo non hai nulla da dire e sproloqui...



Mi sorge un dubbio: le impostazioni delle due analisi erano proprio 
esattamente le stesse?
Anche le due mesh erano uguali? Non nel senso che siano state generate con 
lo stesso criterio, ma che provenissero esattamente dallo stesso file. 

 Certo non hai nulla da dire e sproloqui...
Dai, cerca di essere serio. 


Nella fretta ho lasciato i riferimenti al 560, ma i numeri sono quelli del 
540. 

 Dai, cerca di essere serio.
PLONK!


 ha scritto nel messaggio
news:42dcf...@x-privat.org...

Questo dovremmo chiederlo direttamente all'interessato...:))
Ma presumo che abbia fatto le stesse operazioni, almeno spero.

ti racconto un breve fatto:
seguo da tempo uno studi associato di 3 dottori, ad uno feci anni fa' un pc 
(uno dei primissimi athlon xp), l'altro opto' per un notebook asus 
professionale (sempre da me fornito).
Il terzo che e' piu' furbo e sa' risparmiare ha preso un pakkoHell 
all'ipermercato.
Piu' ram, piu' cpu, piu' hd di quello che feci anni fa', eppure il 
proprietario del pc da me assemblato dice che il suo va' il doppio. Ed ho 
visto facilmente che e' vero... non sono stato capace di vedere un pakkoHell 
andare in modo prestante. 

 migliori di un qualche percento, anche del 10-15% in taluni casi,
ROTFL!!!
http://www.hwupgrade.it/articoli/cpu/852/11.html


 
Beh, datemi un po' di credito ^__^;;
Ho usato gli stessi file (modello e sottomodello), copiati sui due PC.


 ha scritto nel messaggio
news:dbissp$748$1...@newsreader.mailgate.org...

E che ci mettono in quei pc...il freno a  mano tirato?;DD
Comunque in soffitta ho un Paccobell 486 SX33MHz che per quei
tempi era in regola quanto a prestazioni con i pc di altre marche
cono componentistica analoga :)))

 
Anche io ne ho visti un paio da un cliente (Sempron 3100+, HD 160GB, 
512Mb RAM) e mi sembravano molto performanti.

 e' in grado di tener testa al Pentium.
Guarda, anche con il Linux a 32 bit, una prova facile la fai veloce
veloce: a parita di distribuzione e versione del kernel, prova a
ricompilare quest'ultimo su entrambi e prendere i tempi. Se c'e'
qualcosa che non va in quello AMD64, lo vedi subito.
Tu mi chiederai che c'entra il calcolo puro con la compilazione del
kernel. E che ne so, io mica so matematico, io so solo che una macchina
(non una CPU, eh) che ha tappi da qualche parte cosi' si vede subito. :)
Poi magari controlla anche che il programma che usi te non sia stato
iperottimizzato per Intel, che in quel caso potrebbe anche essere che su
AMD non hai speranze.
	tentatamente,
	   Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 ha scritto nel messaggio 
news:2i7De.179737$75.78...@news4.tin.it...

Ok, scusa non è che volessi offenderti!
E' che di questi tempi ne sto sentendo di tutti i colori sugli elementi 
finiti.
Ciao, Beppe. 

 andare in modo prestante.
concordo..ho sottomano un packard bell con un xp2400-m ed è lentissimo
nell'aprire e usare applicazioni, ho dovuto mettere mano a rmclock e
aggiornare drivers perchè le impostazioni tra l'altro sono anche fatte a
cane. L'xp in questione può arrivare ad un minimo di 3X e 0.950V mentre
di default PB il processore girava a 800Mhz con un voltaggio di 1,1V

 Ok, scusa non è che volessi offenderti!
Tranquillo non sono affatto offeso! ^__^
Mi sono accorto della lentezza dell'AMD64 proprio lanciando lo stesso
sottomodello sui due PC.


"seoman" <ganda...@yahooSPAM.com> ha scritto nel messaggio
news:pan.2005.07.19....@yahooSPAM.com...

Beh, ma questo è "masochismo" da parte di Paccobell...:-\

 tempi era in regola
ehm sono 2 ere geologiche fa' pero'!

 ha scritto nel messaggio
news:dbjb6j$p6c$1...@newsreader.mailgate.org...

Mbè? Sempre PaccoBell era... inoltre guarda anche il post di
Kintaro a riguardo :))

 PLONK!
Di nuovo? Ma è la seconda volta che mi plonki nel giro di una settimana... 
dai cerca di essere serio... ROTFL! 

 
Per curiosita' esiste un programmino sotto linux che restituisca degli
indice di prestazione?
Grazie


 attento.
Scusami se te lo faccio notare, ma se, nella frase sopra riportata, 
sostituisci AMD con Intel, puoi usare questa frase come sign per i tuoi
messaggi.
Senza offesa, solo, un pò di coerenza. :)
-- 
Bye,
ReDeX

 ha scritto nel messaggio 
news:pan.2005.07.19....@rlocco.it...

Non mi pare proprio... mi dispiace... non sono io quello che spara 
sciocchezze addirittura smentite dai link che posta... dai, sii serio anche 
tu... 

 
http://www.hwupgrade.it/articoli/cpu/852/11.html
We ragazzo serio questo non lo commenti???
Forza dimmi che prestazioni ha un p4 2.6 in campo scientifico aspetto te... 
LOL


 te... LOL
Quei numeri te li ho già commentati prima, quando mi hai plonkato, cosa vuoi 
ancora???
Adesso vai a riesumare i test sulle vecchie CPU???
Mi sembri sempre più matto, scusa se te lo dico. 

 Mi sembri sempre più matto, scusa se te lo dico.
E tu mi sembri sempre più furbo.... quando non ti conviene non commenti no?


 no?
Io commento le cose che hanno senso, non ho nessuna voglia di seguirti nei 
tuoi giramenti di frittata.

 calcolo e se il 2.6 in questione ha o meno l'HT.
Un espertone come te, dovrebbe saperlo che i P4 2,6 con HT non sono mai 
stati in commercio

 stati in commercio
Ih, ih, ih, dai uno sguardo qui:
http://www.tomshw.it/guides/cpu/20041221/images/cpu_table_intel_big.gif
dove parla dei P4 "C" su socket 478 cosě imparerai qualcosa di nuovo.
Puoi anche leggere questa pagina:
http://www.rojakpot.com/default.aspx?location=3&var1=66&var2=0
che dice:
The Intel Pentium 4C series is based on the successful 0.13 micron Northwood 
core. The Northwood core, as you will recall, came with 512KB of L2 cache 
that helped Intel regain the performance crown. The Pentium 4C ups the ante 
by debuting with a fast 800 MHz FSB and Hyper-Threading enabled throughout 
the entire line (2.4GHz, 2.6GHz, 2.8GHz, 3.0GHz and 3.2GHz Pentium 4C), 
unlike the previous "B-class" Northwood which only had Hyper-Threading 
enabled in the top model - 3.06B.
(Come espertone avrei detto anch'io la stessa cosa che dici tu, ma siccome 
in questa babele di CPU non mi fido di nulla, sono andato a controllare, 
come faccio sempre quando dico qualcosa, anche questo č un modo per essere 
seri). 

 non ho nessuna voglia di seguirti nei tuoi giramenti di frittata.
Se c'è qualcuno che cambia continuamente le carte in tavole è evidente che 
sei tu...
Ma cerca di essere serio (cit.)


 seri). 
Tant'è che non sono mai arrivati sugli scaffali.. magari ci hanno 
pensato ma non sono mai stati commercializzati.

 ha scritto nel messaggio 
news:ZopDe.28296$b93....@tornado.fastwebnet.it...

Non mi pare, non so, i 2.8 sono sicuro che c'erano e avevano l'HT, avevo dei 
dubbi che la cosa fosse estesa anche ai 2.6 e per questo ho controllato: tu 
mi dici che proprio i 2.6 non sono mai arrivati? Boh, tutto può essere, per 
questo chiedevo a Enterprise-E di controllare. 

 ha scritto nel messaggio
news:ZopDe.28296$b93....@tornado.fastwebnet.it...

Qualcuno ne ho installato... anche se in effetti non moltissimi.

 ha scritto nel messaggio 
news:KYpDe.87596$h5.36...@news3.tin.it...

Secondo me ne hanno installati anche non pochi i soliti noti come Dell, 
Packard Bell, HP etc. etc., proprio perché erano CPU con tutte le features e 
a bassa frequenza e basso costo, ottime per poter scrivere "CPU CON HT" 
senza sborsare grosse cifre.
Adesso, per esempio, sui Dell per aziende vanno fortissime le CPU tipo 
340-341o 531 che invece chi si assembla la macchina da sè probabilmente non 
prende nemmeno in considerazione. 

 questo chiedevo a Enterprise-E di controllare.
Sul P4 in questione gira Linux: come faccio a controllare se ha l'HT?
C'e' anche una cosa strana: per quanto concerne l'analisi del _modello
globale_ i due PC hanno gli stessi tempi, con scarti di qualche minuto a
favore dell'AMD, mentre e' l'analisi del sottomodello che sfavorisce
l'AMD64. 
--
Enterprise-E
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Sul P4 in questione gira Linux: come faccio a controllare se ha l'HT?
cat /proc/cpuinfo
se vede due processori, sono quelli logici dell'HT

 cat /proc/cpuinfo

Ecco il responso (tra l'altro e' un 2.4, non 2.6 come avevo detto): 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 15
model           : 2
model name      : Intel(R) Pentium(R) 4 CPU 2.40GHz
stepping        : 7
cpu MHz         : 2430.407
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmovpat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips        : 4816.89
mi sa che ha l'HT.
Questo e' dell'AMD:
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 12
model name      : AMD Athlon(tm) 64 Processor 3200+
stepping        : 0
cpu MHz         : 2200.442
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext lm 3dnowext
3dnow
bogomips        : 4358.14



e noooo...  non posso crederci...   ma prima di spararle cosi' grosse hai
una vaga idea
di quello che dici?
Per tua informazione l'isa di un amd veneziano e di un intel biscotto
differiscono solo per 2 istruzioni...
quelle per l'ht. Che cosa vuoi ottimizzare su intel?
L'unico problema è che l'implementazione amd delle ss2 e ss3 e più lenta di
intel in quanto tali istruzioni sfruttano le lunghe pipe degli intel...
Infine secondo me l'ht attivato su intel non serve ad una mazza!!!
Perchè rallenta le prestazioni della cpu...
mi spiego ...  con ht + supporto os si vedono dal task man. 2 processori
logici... ebbene... ad occhio
se abbiamo una cpu a 3.0ghz non è che con ht avremmo 2 cpu a 1.5ghz
equivalenti... ma in realtà
2 cpu da 1ghz equivalenti .... ESATTO! ci sta una perdita di efficienza....
inoltre tutti i task che per natura sono single thread come
decodifica,codifica  divx, mp3, sha, base64, md5, des ecc. ecc..   con ht
attivato ci mettono una vita.... invece con ht disattivato vanno molto
meglio...
infine per rispondere al post iniziale... sul packard bell ci devono essere
dei driver o periferiche o processi demone che succhiano risorse al povero
amd!!!!  Bisognerebbe verificare il livello di carico della macchina prima
di far partire il calcolo degli elementi finiti!
Saluti
Gio

 mi sa che ha l'HT.
No, non ce l'ha

 No, non ce l'ha
C'e' scritto: cmovpat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe 
cid
quindi lo ha. In ogni caso tutti i Northwood-C avevano l'HT e partivano 
proprio dal 2400 MHz.
-- 
Ciao
Riccardo 

 stupida???
Mi sembra che molti abbiano il paraocchi :-)

 l'AMD64.
Probabilmente è proprio l'effetto HT, fin che si sta sul single-thread tutto 
ok, quando si va sul multi, l'Intel decolla e l'AMD si siede, come da 
copione.
Il fatto che a livello di single-thread l'AMD sia leggermente in vantaggio 
sembrerebbe testimoniare che non ci sono grossi problemi software sull'AMD, 
ma che l'effetto "turbo" è solo dovuto all'HT.
Sembrerebbe una dimostrazione lampante di ciò che vado ripetendo da mesi...
Aaaaaaaaaaaaaaaaaaaleeeeeeeeeeeeeeeeeeeecccccccccccccccccc!!! 

 il listato buttato fuori da Linux sembrerebbe di no.
Quoto Riccardo:






Non avevo visto questa riga in effetti... ;)
Resta il fatto che la differenza sia a mio avviso troppo netta, anche
se il software č programmato per sfruttare il multithreading...nemmeno
con un piů efficiente sistema biprocessore rispetto ad uno monoprocessore si
hanno tali incrementi.

 hanno tali incrementi.
Dipende dai casi, il problema è che senza HT e con due processi pesanti 
insieme, uno dei due praticamente si ferma, quindi l'allungamento dei tempi 
può diventare mastodontico.
C'era un bench non mi ricordo dove in cui c'era una differenza del 1600% tra 
le due CPU.
Quando avevo discusso qualche tempo fa con Nintolo (mi pare) e lui aveva 
finalmente fatto la prova che gli dicevo io con CPU-burn e SuperPI in 
parallelo, il mio SuperPI peggiorava da 43 secondi a 57 non avendo o avendo 
CPU-burn in parallelo, il suo passava da 40 secondi a oltre 1 minuto e 30.
D'altronde il fatto che nell'analisi del modello, l'AMD sia in leggero 
vantaggio sembra escludere problemi sw sulla macchina, che altrimenti 
penalizzerebbero anche quel tipo di elaborazione.
La differenza è grande e sembra esagerata, ma conoscendo DAVVERO cosa fa 
l'HT (come lo conosco io per averlo provato sulla mia pelle, ti ricordi i 30 
minuti a fissare lo schermo :-))), non mi stupisco poi così tanto. In quel 
mio caso personale le altre operazioni rallentavano come minimo di 10 volte, 
non di 3.
Probabilmente giocando colle priorità si potrebbe cercare di ottimizzare un 
po' la questione AMD in quel caso, ma non è detto. 

 hai una vaga idea di quello che dici?
Vaga si, per quello ho messo il "potrebbe".
http://www.coyotegulch.com/reviews/linux_compilers/index.html
Cito: 
    Why don't I use the Intel compiler on my Opteron system? The simple
    answer is that Intel's compiler does not produce code that takes
    advantage of the Opteron's features. Intel's compiler also produces
    executable code that disables some of its optimizations on non-Intel
    hardware. It's unrealistic to expect that Intel will create a
    compiler that works well on their competitor's hardware.
Quello che intendevo dire, quindi, e' che se, ad esempio, il programma
e' un binario ottenuto da un compilatore Intel per processore P4, tale
binario POTREBBE - ma non sono sufficentemente ferrato in materia per
poter dare certezze in merito - girare molto piu' lentamente su un
AMD64, sopratutto la dove si gioca tanto coi numeri in virgola mobile.
	ritentatamente,
	    Cthulhu
-- 
http://www.rlyeh.it/Rantolii/

 penalizzerebbero anche quel tipo di elaborazione.
Appunto...č questo che non mi convinve molto.

Riccardo & Dothan ha scritto:

Bene, e' ufficiale: l'amd64 e' scarso. Almeno nell'elaborazione dei
sottomodelli.
Provero' con una suse 64 bit e abaqus per x86_64, ma mi sa che non ci
schiodiamo da li'.
Peccato.
-- 
Enterprise-E
kirona75 [at] 
gmail.com

 ha scritto nel messaggio
news:G5yDe.186578$75.80...@news4.tin.it...

Tu prova lo stesso...:))

 Grazie per ogni eventuale risposta
Vista la differenza che c'e' e considerato
le cpu utilizzate, sono due le cose da analizzare per prime.
1)
Con cosa e' stato compilato Abaqus/CAE e quali opzioni
di compilazione sono state utilizzate sia per il compilatore
che per l'applicazione (intendo #define e simili) ?
Puo fare una differenza *mostruosa* specialmente
se ci sono parti che di codice che implementano
la block optimization (a.k.a. strip mining) in base
al target (sui K8, una block optimization "mirata alla cache L1"
in certe applicazioni produce incrementi notevoli).
2)
Quanto e' grosso il working set di quello che gli hai dato da elaborare ?
Se swappa troppo su disco la differenza la fa l'hard disk, non la cpu.
L. Micheletto

 Appunto...è questo che non mi convinve molto.
Perchè? Io credo che semplicemente l'elaborazione parta coll'analisi del 
modello globale e fin qui è mono e AMD è giustamente in vantaggio, non fosse 
altro per il fatto che è un 3200+ contro un 2.4, poi si aggiungono dei 
thread ulteriori e l'AMD crolla.
Direi che è una situazione da manuale su cosa significa avere l'HT (o non 
avercelo).
E direi che spiega molto bene ciò che io sostengo da mesi e cioè che l'HT è 
un plus ben più importante di quel 2-3% in più o in meno che i Prescott o 
gli AMD hanno rispettivamente in un campo applicativo o l'altro, perché qui 
le differenze possono essere del 300% o del 1600% molto facilmente. 

 modello globale e fin qui è mono...
E' proprio questa fase che dovrebbe essere la più indicata ad essere
scomposta in thread...
Comunque non sapendo esattamente come opera questo "benedetto"
software non si può dare una risposta definitiva e univoca... leggi
anche l'intervento in proposito di Lorenzo Micheletto in fondo al post.

 Se swappa troppo su disco la differenza la fa l'hard disk, non la cpu.
Sono due macchine con 2GB di RAM ciascuna che facevano lo stesso identico 
lavoro, non capisco come la dimensione del working set possa avere 
importanza, visto che è identica e ci sono 2GB di RAM.
D'altronde penso che anche un cretino si accorgerebbe se una delle due 
macchine fa swap su disco per qualche dozzina di ore di fila...

 proprio dal 2400 MHz.
ma infatti... pensavo, nella mia ingenuità, fosse un informazione scontata
per chi bazzica qua dentro...
rotfl fanno gli "espertoni" e non si ricordano le cose dell'altro ieri..

 proprio dal 2400 MHz.
Lo supporta ma non è abilitato stando a quel cpuinfo.

 anche l'intervento in proposito di Lorenzo Micheletto in fondo al post.
Sul fatto che siano tutte ipotesi non ci sono dubbi, io ho fatto delle 
deduzioni basate sulla testimonianza oculare di Enterprise-E, certo sarebbe 
bello saperne di piů sul sw.
Ho risposto all'intervento di Lorenzo Micheletto e devo dire che non mi ha 
convinto per nulla. Mi dispiace. 

 ha scritto nel messaggio 
news:dbmf5d$sa9$1...@news.ngi.it...

Perché? Vuoi dire che quelli sono i flag di ciò che non è abilitato, quindi 
non sono abilitate le SSE, le SSE2, le ACPI e tutto il resto? Insomma, una 
macchina che non si sa come faccia a funzionare... 


Il punto 1 può essere benissimo una cosa plausibile ed influirebbe
abbastanza sulle prestazioni... per il punto 2 bisognerebbe sapere
se il nostro amico eventualmente si sia accorto o meno se il sistema
swappasse, cosa non impossibile anche se ci sono 2GB di RAM :))

 ha scritto nel messaggio
news:dbmf5d$sa9$1...@news.ngi.it...

Interessante... da dove lo deduci questo fatto?

 swappasse, cosa non impossibile anche se ci sono 2GB di RAM :))
Sì, ma perché dovrebbe swappare solo su AMD, visto che le due CPU fanno la 
stessa cosa e hanno lo stesso quantitativo di RAM???
E poi mi sembra veramente dura non accorgersi che il tuo sistema è li che 
frulla come un macinino per dozzine di ore di fila...


Non si sa mai... magari mentre i sistemi elaborano lui sta da un altra parte
e torna solo quando hanno finito ;D

 bello saperne di più sul sw.
Eh, ma come si fa? Abaqus/CAE e' closed.


 Eh, ma come si fa? Abaqus/CAE e' closed.
A questo punto la curiosità nasce! Hai rivitalizzato le sfide verbali tra
amd-isti e intel-isti!
Puoi provare a fare girare lo stesso software su un computer con un amd64bit
che non sia quel packard bell?
Saluti

 
Non è attivo a livello di elettronica, oppur enon è attivo nel bios, 
oppure il kernel non ha il supporto SMP.
Ripeto: Se HT fosse attivo, il nostro amico dovrebbe vedere 2 cpu

 Tu prova lo stesso...:))
Ieri sera abbiamo installato la SUSE 64 bit con Abaqus/CAE 64 bit (non
vi dico le bestemmie per installarlo, visto che su un PC si installa,
sull'altro no...) e i risultati sono (l'analisi e' andata stanotte):
_ modello globale (10 step) 15 minuti in meno che con il software a 32 bit;
_ sottomodello (10 step anche lui) con macchina su runlevel 3 si passa
da 2h e 50' a 1h e 50'.
C'e' un lieve miglioramento, e mi sa che dobbiamo accontentarci.
Modello e sottomodello sono quelli che ho utilizzato quando ho scritto
il messaggio che ha dato il via al thread.



Siccome lo ho usato per un po' di tempo, cosa ti interessa sapere 
esattamente?
Potrei provare a fare una ricerca in modo da essere esauriente.
Ciao,
    Beppe. 

 
No, perche' l'altro AMD64 e' un 2800+ con solo 1 GB di memoria e senza
l'autorizzazione per installare Abaqus/CAE. Ha installato la MDK 64 bit,
Matlab e Patran (entrambi a 32 bit).


 da 2h e 50' a 1h e 50'.
Lieve miglioramento? nel sottomodello il lieve migliramento è il 30%...
Saluti

 Potrei provare a fare una ricerca in modo da essere esauriente.
Mah, fondamentalmente se è single-thread o multi-thread, se è single durante 
l'analisi del modello globale e multi quando passa ai sottomodelli, se c'è 
una qualche routine iterativa pesante che gira per tutto il tempo 
dell'elaborazione dei sottomodelli.
Insomma, tutto ciò che possa dare un'indicazione se l'HT possa o meno essere 
la causa del vantaggio Intel.

 ha scritto nel messaggio 
news:c8IDe.187531$75.81...@news4.tin.it...

Visto che ci sono ancora dei dubbi sulla presenza o meno dell'HT sul P4, 
puoi entrare nel bios e vedere se c'è la voce e come è settata, questo 
dovrebbe tagliare la testa al toro?
Dovrebbe esserci un menu "Advanced Bios Features" e una voce "CPU 
HyperThreading" con Enabled/Disabled. 

 HyperThreading" con Enabled/Disabled. 
Adesso e' occupato, e probabilmente lo sara' per tutto il giorno. Piu'
probabile che ci riesca domani.
Me lo segno.



Ah, naturalmente potrebbe anche trattarsi di piů processi separati che 
cooperano. 

Galois ha scritto:

Beh, non e' l'oretta che ci mette il P4 ^__^


 ha scritto nel messaggio 
news:BdIDe.9983$a5.1...@twister2.libero.it...

Sì, ma considerato che si parlava di una differenza del 300%... sul globale, 
compresa la parte in cui AMD non perdeva... capisci che siamo lontani da una 
qualunque possibilità di confronto...
Stando al messaggio iniziale mi sembra di capire che nella parte incriminata 
Intel ci metta 45 minuti e AMD 1h 50'.
Guarda caso sono numeri pazzescamente simili (moltiplicati per 60) a quelli 
che ho ricavato io col mio "bench" personale con Nintolo.
In quel caso io facevo il SuperPI con CPU-burn in parallelo in 57 secondi e 
lui lo faceva in 1 minuto e 35...
Qui è ancora peggio, ma a grandi linee l'idea è quella... 

 lui lo faceva in 1 minuto e 35...
Che Cpu hai?

 ha scritto nel messaggio 
news:xrIDe.9179$B6.2...@twister1.libero.it...

P4 630. Lui aveva un A6 3500+. 

 ha scritto nel messaggio 
news:dbnk2b$7s9$1...@news.ngi.it...

P4 630. Lui aveva un A64 3500+.

 P4 630. Lui aveva un A64 3500+.
Non ho ben capito....si tratta del test SuperPi a 1M?
Non capisco (non ho seguito la parte del 3ad in cui parlavi di questo) come
faccia ad ottenere 1min35 con un 3500+

 ha scritto nel messaggio 
news:YuIDe.10009$a5.1...@twister2.libero.it...

Si trattava di fare il test con CPU-burn attivo in parallelo e mettendo le 
priorità dei due processi allo stesso livello.
Quindi io col 630 peggioravo dai 43 secondi (senza CPU-burn in parallelo) ai 
57 (con CPU-burn), lui dai 40 al minuto e 35.
Era un modo per simulare e far capire ai testoni cosa implica avere l'HT.

 cooperano.
Sicuramente è un software multithreading.
Nella versione che usavo io, era la 6.4 era tutto impostabile: dalla 
priorità da dare ai processi al numero di cpu da utilizzare e al tipo di 
precisione a cui eseguire i calcoli.
L'applicazione in realtà agli inizi era stat sviluppata per unix, poi è 
stato fatto un porting in altri sistemi operativi. Fino alla versione 6.3 
era necessario in windows avere exceed per farlo girare. Non so cosa sia 
stato fatto per linux, bisognerebbe indagare anche in quella direzione.
Il motore di calcolo è ottimizzato per soluzioni non lineari ed utilizza un 
algoritmo di tipo iterativo: ciò rende molto onerose le richieste di sistema 
e proprio per questo motivo è stato disegnato per poter lavorare su grosse 
workstation/server con più processori.
Proverò a cercare se mi è rimasto ancora qualcosa dei manuali.
Ciao,
    Beppe. 


A questo punto sarebbe interessante fare questa prova... con i Paccobell
non si sa mai cosa possa accadere ;D

 AMD-Intel.
Ignora certa gente, per loro se qualcuno mette in dubbio che una CPU AMD 
possa, in alcune applicazioni, essere pesantemente penalizzata rispetto ad 
una CPU Intel non può essere altro che un agente provocatore nemico.
A livello di schemi mentali hanno molto in comune coi talebani, cogli 
integralisti islamici, cogli stalinisti e coi nazisti.
Naturalmente, per loro e nostra fortuna, la loro malattia ha conseguenze 
decisamente meno gravi. ;-) 

 secondo me questo é un palese tentativo di flame.
Se come no, perche' a me ne viene qualcosa se scateno una guerra AMD-Intel.
-- 
Enterprise-E
kirona75 [at] 
gmail.com

 Proverò a cercare se mi è rimasto ancora qualcosa dei manuali.
Grazie, direi che quello che hai detto conferma esattamente la mia prima 
impressione ricavata dalla testimonianza oculare di Enterprise-E.
Probabilmente è quell'algoritmo di tipo iterativo che *manda in rovina* 
l'AMD. 



 fisso: che dichi hanno le due macchine?
Scusa se interloquisco, ma stiamo parlando di un processo che dura 1 ora e 
50 minuti, cosa vuoi che influisca il salvataggio di una mole sia pure 
grande di dati sull'hard disk?
E poi come sarebbe possibile che si venisse a realizzare una differenza di 
un'ora su su una e 50 minuti solo per le diverse prestazioni degli HD 
durante il salvataggio di questi dati intermedi???
Quello che dici potrebbe avere senso quantitativo se si trattasse di salvare 
120GB di dati e uno li salvasse a 40MB/s su un disco ottimo e l'altro li 
salvasse a 15MB/s, ma non credo proprio che sia questo il caso. 

 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
Ripensando al funzionamento di Abaqus mu sono ricordato che ha un solutore 
di tipo iterativo, quindi obbligatoriamente non terrà mai tutti gli step 
della soluzione contemporaneamente in memoria.
Quando lo usavo mi sono accorto che arrivato ad un certo punto della 
soluzione, anche se il problema è di piccole dimensioni (per il singolo 
step) andava a swappare su disco per salvare parte dei risultati ottenuti.
Il prioblema secondo me risiede nella gestione degli I/O con il disco fisso: 
che dichi hanno le due macchine?
Ciao, Beppe. 

 non si sa mai cosa possa accadere ;D
Come detto, sull'altro AMD64 purtroppo tale prova non puo' essere fatta.
Posso solo dire che il P4 e' un Quality Data forte come una roccia,
mentre i PC Intel dell'aula tesi sono forniti da Teoresi
(
www.teoresi.com
) e l'AMD64 2800+ e' fornito da un tal Bianchi, ma non
dev'essere roba di prima qualita' dato che l'obiettivo e' risparmiare
(tanto per dire, ad un dottorando hanno dato un AMD Athlon 3000 fornito
da Bianchi, e subito, da nuovo, e' stata resa necessaria la sostituzione
del secondo HD, visto che causava difficolta' all'accensione.
Praticamente si fermava al boot del bios e quando il PC diventava caldo
si avviava anche XP).


 ha scritto nel messaggio 
news:dbnnln$907$1...@news.ngi.it...

Sicuramente quell'algoritmo potrebb solo avvantaggiarlo l'AMD se fosse 
contenuto in un thread unico.
A mio avviso è necessario controllare a livello di thread cosa combini 
Abaqus mentre risolve i sottomodelli.
Inoltre 2 GB di ram non è sicuro che siano sufficienti a non sicorrere allo 
swap su disco.
Mi è venuta in mente una cosa che ha grossa inerenza con Abaqus ma la posto 
in radice perchè interessa tutti.
Ciao,
    Beppe. 

 posto in radice perchè interessa tutti.
OK. 


Ma LOL


Bene...

 Ciao, Beppe. 
Il Packard Bell ha un Seagate Technology 200826A da 200GB (mi hanno
detto che dovrebbe essere un serial-ata, ma non sono sicuro).
Il P4 ha un disco fisso da 120 GB e uno da 10 GB (tirato fuori da un
vecchio PC) che usa come swap per Abaqus. A detta del ricercatore che
possiede il P4, il secondo disco fisso si e' reso necessario per rendere
piu' fluido il sistema mentre lo usa.


 ha scritto nel messaggio
news:lfLDe.188564$75.81...@news4.tin.it...

Interessante... il secondo HD, anche se vecchio in effetti può velocizzare
il lavoro di swapping rendendo indipendente le operazioni di I/O tra
OS/applicativo e lo stesso file di swap, anche se comunque non penso
che stia tutta qui la responsabilità del divario prestazionale tra le due
piattaforme.

  bla bla
perchè se non sai le cose (come tu stesso hai ammesso sopra riguardo a 
linux) taci: quelle sono le istruzioni supportate, ma se l'HT fosse 
attivo li ci sarebbero due sezioni: processor0 e processor1.
Come ha detto Kintaro o non è attivo dal bios o non sta usando un kernel 
smp.

 il messaggio che ha dato il via al thread.
Ciao
Non per fare polemica o altro ma e' possibile provare il programma su un so 
win32 e win64, sempre che esista la versione per win?
-- 
Ciao
Riccardo 

"Riccardo & Dothan" <toma...@NONlibero.it> ha scritto nel messaggio 
news:H%LDe.9646$B6.2...@twister1.libero.it...

Per esistere esiste, bisogna vedere però se la loro licenza è valida anche 
sotto win.
Ciao,
    Beppe. 

 ha scritto nel messaggio 
news:dbntrg$bns$1...@news.ngi.it...

Hai presente la mole di dati generata da un FEM?!
Bisognerebbe sapere come è composto il modello: con un buon PC ho fatto 
girare modelli con 1000000 di nodi, il che significa 3x1e6 gradi di libertà 
(ovvero equazioni da risolvere all'interno del sistema) se siamo in presenza 
di solidi o 6x1e6 se stiamo parlando di superfici o beam.
Così facendo hai delle informazioni sugli spostamenti nodali che sono 
3x1e6x6 oppure 6x1e6.
Pii ci sono a seguire gli strain (calcolabili solo sugli elementi) 6 
componeneti e infine gli stress (6 componeneti).
Il tutto moltiplicalo per il numero di step che occorrono per giungere alla 
soluzione.
Inoltre viene quasi sempre salvata (dico quasi perchè dipende dal software 
che si sta utilizzando) la matrice di rigidezza: ha tante linee quante sono 
le equazioni del sistema, ovvero i gradi di libertà totali.
Così vedi come si fa presto a fare dei file di grosse dimensioni.
Ciao,
    Beppe. 

 Così vedi come si fa presto a fare dei file di grosse dimensioni.
Tutto molto bello, ma io ti ho parlato di 120GB affinché certe differenze 
prestazionali anche grandi tra i dischi possano fare una differenza di 60 
minuti in meno su 110, non so se mi spiego!
Mi sembra improbabile che un calcolo del genere alla fine dia come output 
120GB di dati... magari mi sbaglio ;-)))))

 ha scritto nel messaggio 
news:dbo4k2$ejr$1...@news.ngi.it...

A me è capitato di vedere soluzioni che avessero risultati nell'ordine dei 
GB come file finali:ovviamente durante il processo vengono generati una 
serie di file temporanei che ne portano il valore a lievitare molto. Inoltre 
il trasferimento dati non è continuativo ed effettuato in un unica soluzione 
ma può avvenire in maniera frammmnteria, cosa che come tu ben sai fa 
peggiorare e di molto i tempi di trasferimento.
Ciao, Beppe.
Ciao, Beppe. 

 ha scritto nel messaggio 
news:alLDe.91212$h5.38...@news3.tin.it...

Ma che dimensioni ha il problema? Ci sono anche problematiche di contatto? 

 sai fa peggiorare e di molto i tempi di trasferimento.
Intanto credo che stiamo parlando di pochi GB, quindi c'è un fattore 100 che 
balla, il che significa che con quello puoi spiegare differenze dell'ordine 
del paio di minuti, non dell'ora.
E poi resta il fatto che quello che conta è il differenziale di velocità tra 
le due macchine, perché è chiaro che rallenterebbero entrambe, se ci fosse 
questo tipo di problema.
A meno di ipotizzare che sulla macchina AMD il disco sia praticamente pieno 
e ciò costringa il processo a fare i salti mortali per swappare i dati dove 
può, ma, ripeto, anche un cretino si accorgerebbe che su una macchina tutto 
fila liscio e sull'altra per gran parte del tempo si swappa, e non mi pare 
che Enterprise-E si sia dimostrato un cretino fino ad ora. 

 
Il modello globale ha piu' di 122000 nodi e, tra le altre cose, una
decina di interaction di tipo contact.


 ha scritto nel messaggio
news:dbo1ud$dau$1...@news.ngi.it...

Allora questo cambierebbe e di molto le carte in tavola... ;D

Lorenz ha scritto:

Si', sarebbe ancora piu' disastroso nei cfr dell'AMD64 :((


 ha scritto nel messaggio 
news:nwNDe.189475$75.81...@news4.tin.it...

E' praticamente impossibile che non c'entri l'HT e che contemporaneamente 
non ci sia alcun gravissimo difetto hw/sw nella macchina AMD.
Quindi i casi sono 2:
O è merito dell'HT o qualcuno ha sbagliato qualcosa di enorme sulla macchina 
AMD.
Tertium non datur.
Non esiste che un A64 3200+ abbia prestazioni pari al 40% di quelle di un 
2.4Ghz, qualunque sia l'ambiente applicativo in questione, se non interviene 
la questione HT. 

 ha scritto nel messaggio
news:nwNDe.189475$75.81...@news4.tin.it...

No, al contrario... significa che avete fatto un "casino", senza offesa eh?
;)

 Si', sarebbe ancora piu' disastroso nei cfr dell'AMD64 :((
Come ha detto Lorenz significa che avete fatto un casotto con l'amd...

 ha scritto nel messaggio 
news:ijNDe.91624$h5.38...@news3.tin.it...

Beh, per i contatti non č che sia proprio piccolino!
Secondo me la chiave di tutto č nell'inserire un secondo HD e vedere se la 
situazione migliora.
O meglio, prova sul computer del ricercatore a non fargli usare il secondo 
HD ma di farlo lavorare solo sul primario. Cosě non ti costa nulla.
Ciao,
    Beppe. 

 Interessante... da dove lo deduci questo fatto?
E' quello che penso anch'io, pur non avendo mai visto un cpuinfo di un 
processore hyperthreaded: in quell'output non c'è alcuna traccia 
dell'esistenza di due processori (seppure "logici") e quindi la conclusione 
più sensata è che l'HT sia disabilitato, nonostante la CPU lo supporti.
--
Xelloss 

 ha scritto nel messaggio 
news:W4ODe.10664$a5.1...@twister2.libero.it...

L'HT sulle macchine che ce l'hanno è abilitato di default, quindi qualcuno 
sarebbe dovuto andare appositamente a fare la disabilitazione.
Stiamo parlando di una macchina in comune tra utenti a cui viene affidata 
per delle elaborazioni e dobbiamo aspettare domani mattina per entrare nel 
bios a verificare come stanno le cose.
La stessa persona che ha aperto il thread non sapeva nemmeno che esistesse 
questa feature, né tanto meno che si potesse abilitare/disabilitare, né 
ancora meno dove si dovesse andare per farlo.
Ergo, mi pare molto ma molto più probabile che se la CPU ha l'HT (e a quanto 
pare ce l'ha) esso sia abilitato.

 ha scritto nel messaggio
news:42dfa...@x-privat.org...

Sono d'accordo... sarebbe una prova da fare, tanto per avere una sicurezza
in piů, si fa per dire.

 L'HT sulle macchine che ce l'hanno è abilitato di default.
Per un lungo periodo è stato vero il contrario. Saluti.
--
Xelloss 

 ha scritto nel messaggio 
news:0lODe.10696$a5.1...@twister2.libero.it...

Non mi pare, forse all'inizio inizio, ma ho visto macchine di due anni fa 
che avevano l'HT abilitato di default ed il proprietario mi chiedeva come 
mai la CPU non andava quasi mai oltre il 50% del carico.

     Beppe. 
Posso fare un'altra cosa: il Packard Bell ha un secondo HD da 4.2 GB,
quindi vecchiotto, e posso usarlo per far lavorare abaqus con i suoi
file temporanei. L'avevano disabilitato perche' si riempiva alla svelta.
Il PC del ricercatore attualmente sta iper-lavorando ^__^


 pare ce l'ha) esso sia abilitato.
Ancora una volta ti ostini a voler parlare anche se non sai.
Dall'output che ha postato, è evidente che il tuo c**o di HT non c'è, 
non è attivato, oppure non c'è supporto del SO.
Stare zitti a volte e studiare, no eh ?

 ;)
Ahhh, io nulla c'entro, sono solo tesista ^___^;;


 ha scritto nel messaggio 
news:eDODe.189862$75.82...@news4.tin.it...

Potrebbe essere una buona prova. Ma ora mi sorge un dubbio.
Ma qui devo fare una domanda ai più esperti:
se ho un sistema con un HD primario nuovissimo, quindi a 7200giri SATA e uno 
molto più vecchio mettiamo a 5400 giri se non meno ogni HD andrà alla sua 
velocità massima o il controller risulterà rallenato?
In passato mi era stato sconsigliato di montare assieme al mio HD da 7200 
giri uno vecchio che mi sembrava essere a 4600 o giù di li oerchè altrimenti 
avrei rallentato tutto: è possibile come cosa?
Ciao,
    Beppe. 


E' possibilissimo se quello a 4200rpm funzionava con il protocollo
PioMode...

 ha scritto nel messaggio 
news:0rPDe.190132$75.82...@news4.tin.it...

Guarda funzionava così:
scheda madre Abit k7raid
la quale ha due canali UDMA e 2 Canali UATA 100 con possibilità di raid.
Il primario e disco di sistema era sul primario UATA ed era un seagate a 
7200 giri
L'altro era su uno dei canali dell'altro controlle assieme al lettore 
ottico, ed era un maxtor da 6 GB.


Allora non rallentavi nulla se l'HD da 6GB era messo assieme al
lettore cd nell'altro controller...

 stati in commercio
Questo non e' assolutamente vero,io ho avuto un P4 2.6 con HT ,erano i primi 
con il BUS a 800Mhz.

 
Chiedo venia.

 macchine fa swap su disco per qualche dozzina di ore di fila...
Quando uno elenca ram installata (2GB) e dimensione dell' hd utilizzato
(200GB) viene da pensare che lo abbia fatto per una buona ragione.
Quindi ho pensato che fosse il caso di prendere in considerazione
pure la possibilita di swapping su HD.
Tieni presente che non ci sono solo i mega-swap tipici di applicazioni
"in crisi d'astinenza di ram", ci sono pure quei flicker rapidi
e leggeri ma continui che magari uno pensa non influiscano piu di tanto
(specialmente se il computer a livello di UI sembra avere una reattivita
nella norma).
Oltre a questo, le domande si fanno anche per avere piu dettagli
visto che io non pretendo di leggere nella mente di Enterprise-E
e vista la differenza di tempi ho pensato fosse il caso di
avere maggiori chiarimenti sui due principali indiziati della differenza
di prestazioni.
Ricordati che il confronto e' fatto tra un K8 a 2.2Ghz effettivi
ed un P4 con 2.4Ghz effettivi; non so se ti rendi conto di cosa
questo comporti.
Il K8 a parita di clock ha un IPC piu elevato dei P4.
*Non esiste* che su un programma *ben ottimizzato* per entrambe le cpu
un P4 HT con solo 200Mhz di vantaggio possa essere 3 volte piu rapido
per puro e semplice merito dell'HT.
L. Micheletto

 per puro e semplice merito dell'HT.
Vedi sopra.
Ci sono test in cui un Prescott ha avuto prestazioni del 1600% migliori di 
un A64 in condizioni di multitasking pesante, capirai che il 300% fa ridere, 
anche se parliamo di un 2.4 contro un 3200+. 

 anche sotto win.
Era per avere anche un parametro di riferimento con windows. In ogni caso 
sono convintissimo che sia un problema di software, qualche problema di non 
ottimizzazione per la cpu amd (come il seti, superottimizzato per intel 
anche senza ht). Gia' il passaggio da 2h e 50' a 1h e 50' lo dimostra, 
secondo me anche l'ultima ora e' una questione di qualche incompatibilita' 
del software, una differenza cosi' sono convinto non possa esistere, 
nonostante non conosca personalmente il programma.
-- 
Ciao
Riccardo 

Massimo, te lo dico io cosa c'e' che non furnziona.
Molto probabilmente quel programma li e' stato compilato con il compilatore
dell' intel che privilegia i processori intel e penalizza i processori della
concorrenza ( solo che questa volta avra' esagerato ) .
Che cosa vuoi aspettarti da chi si e' costruito una fama a furia di spot
pubblicitari, invece che sulla bonta' dei prodotti.
Chi si ricorda "con il pentium si naviga piu' veloci in internet" oppure
"con il pentium gli mp3 vengono meglio".
Come dimenticarsi quando amd  tiro' fuori un processore che la surclassava
completamente  l'intel, quest'ultima invece di affidarsi agli ingegneri per
trovare qualcosa di meglio, si affidarono ai pubblicitari.
Quest'ultimi risposero: " la gente conosce i megahertz, diamogli i
megahertz" .
 E cosi' l'intel tiro' fuori il pentium4, un processore largamente
innefficiente, che girava stupidamente a vuoto prima di riuscire a tirare
fuori uno straccio d'istruzione.
Anche adesso. Tra un po' ha il doppio della frequenza degli athlon, ed
ancora rimane indietro.
Ma ha tanti megahertz. E all'intel pensavano che gli ignoranti avrebbero
abboccato. Ma per fortuna esiste internet e le persone si possono informare.
Ed il fatto che l'intel ha minacciato , ricattato o pagato i costruttori di
computer per impedire che utilizzassero processori amd.
Poi la stranezza del fatto che La microsoft ha aspettato che l'intel
rilasciasse i processori a 64 bit prima rilasciare windows a 64bit, a me
puzza parecchio, visti i precedenti.
E poi le le cpu intel dualcore che si appoggiano sul chipset sinceramente e'
troppo, tanto ormai non si danno neanche piu' la pena di studiarcisi sopra.
Senti Massimo, tu puoi tirare fuori tutte le cose piu' fantasiose sull' HT.
Puoi anche confrontare le prestazioni di cpu intel che costano 550 euro con
cpu amd che costano 130 euro.
MA PER ME L'INTEL HA GIA' PISCIATO FUORI DAL VASO TROPPE VOLTE !!!!

 win32 e win64, sempre che esista la versione per win?
Purtroppo non si puo': nell'aula tesi e' categoricamente vietato
Windows, per evitare di sborsare soldi in licenze e antivirus.
C'e' solo linux, e infatti nessun tesista usa tali PC, tutti si portano
il portatile ^___^


"Riccardo & Dothan" <toma...@NONlibero.it> ha scritto nel messaggio 
news:KEVDe.10680$B6.2...@twister1.libero.it...

Si potrebbe vedere sul sito per che tipo di processori è certificato.
Il software che uso io è certificato sia per amd che per intel, ma è 
chiaramente specificato.
Ciao,
    Beppe. 

 HyperThreading" con Enabled/Disabled.
Abbiamo controllato: non c'e'.
--
Enterprise-E
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Abbiamo controllato: non c'e'.
Non c'è quella voce lì, non c'è alcuna voce di quel tipo da nessuna parte, 
avete un accesso abbastanza completo al bios o è uno di quei bios *protetti* 
che non ti lasciano fare/vedere nulla?
Comunque se davvero non ha l'HT a questo punto ci deve essere qualcosa di 
decisamente sbagliato sull'altra macchina, non credo ci siano altre 
spiegazioni.
Anche se continuo a restare molto perplesso quando mi dici che il calcolo 
del modello globale avviene sull'A64 più rapidamente che sul P4 e solo dopo, 
nei sottomodelli, avviene il peggioramento.
Boh!?! 

 nei sottomodelli, avviene il peggioramento.
Boh, non so che dire nemmeno io:come scritto c'e' un certo miglioramento
con software a 64 bit, anche se ci mette 50 minuti in piu'.
Forse Abaqus anche a 64 bit non e' perfettamente ottimizzato per AMD64


 Forse Abaqus anche a 64 bit non e' perfettamente ottimizzato per AMD64
Sì, ma perché per un po' va e poi cala? 


Evidentemente quel programma č stato "tradotto" da un compilatore
fortemente ottimizzato per le cpu P4 e utilizza per quanto possibile
istruzioni che procedono sequenzialmente, sfruttando con profitto
tutti o quantomeno la maggiorparte degli stadi di pipeline, anche se la
differenza a mio avviso rimane sempre esageratamente elevata... oppure
(probabile) esiste un serio "scazzo" hardware/software nel PaccoBell dove ci
sta dentro il "povero" A64 ;DD


Beh questo è ovvio poi... i pc di PaccoBell (e anche la maggiorparte di
quelli di marca) hanno una configurabilità del Bios prossima allo zero :-\

 120GB di dati... magari mi sbaglio ;-)))))
In base a quel che ha scritto in precedenza Beppe, l'Abaqus genera
un sacco di soluzioni intermedie (traduzione: dati temporanei)
"le mette da parte" e poi le riprende in considerazione piu avanti
per ricavarne altre piu dettagliate, ecc. ecc.
Quindi il  volume di traffico associato all'elaborazione delle
soluzioni temporanee e' *parecchio* superiore (in ordini di grandezza)
a quello associato ai dati iniziali e finali del modello, questo e'
sufficiente a produrre swap a iosa non appena si supera una certa soglia.
La cosa da ricordare bene e' che sebbene per la maggior parte
degli utilizzatori "il computer swappa" solo quando e' praticamente
congelato mentre la lucetta dell'accesso al disco e costantemente
accesa, per chi ragiona in termini di prestazioni lo swap "dannoso"
inizia quando la cpu passa piu tempo ad aspettare dati da disco che
ad elaborarli.
Tieni presente che tra i tempi di accesso alla ram e quelli al disco
c'e' di mezzo un fattore 1000.
Questo significa che un processo che nel 10% dei casi
deve recuperare da disco dei dati in modo non facilmente predicibile
si ritrova a venir rallentato di un fattore circa 100, ovvero
se impieghi 100 nel caso "ideale" con tutto in ram
ti ritrovi a dover impiegare 90+10*1000 = 10090 con 90% in ram ed un 10%
su disco in una  situazione in cui non si conosce con sufficiente
anticipo quali dati verranno utilizzati (e "sufficiente anticipo"
nel caso di accesso al disco riporta in gioco un altro fattore 1000)
in pratica l'accesso al disco diventa dominante.
Se i dati "mal recuperati" sono solo il 5%, il rallentamento e' solo
di circa 50 volte  (95 + 5*1000 = 5095).
Con "solo" un 1% di dati "mal predetti" da disco il rallentamento
e' "solo" di quasi 11 volte (99 + 1* 1000 = 1099), ma anche
a tale livello e' l'accesso al disco ad essere dominante
sulle prestazioni.
Notare che ho sempre parlato di dati "mal predetti", non di tutti
i casi in cui si accede al disco mentre l'applicazione e' in
esecuzione (gli accessi piu o meno predicibili possono essere
velocizzati con una accurata preallocazione dei dati su disco
oppure usando un thread che fa prefetching attivo, ma il "peso"
del prefetcher o dei thread "che spartiscono tra loro i dati"
dipende solo dalla potenza di calcolo della cpu, non da quanti
thread riesce a gestire (questo ovviamente con un applicazione
scritta bene che usa thread pools ecc. ecc.).
Notare inoltre che se l'applicazione usa piu thread, visto
che gli "accessi al disco mal predetti" sono gia pesantissimi
anche quando sono solo l'1% dei casi, l'unico vantaggio
che si puo avere e' che se i thread lavorano su dati
comuni si "precaricano parzialmente" i dati a vicenda
ma il peso schiacciante degli accessi mal predetti rimane.
Anche nel caso dell' 1%, mentre un thread "aspetta dati dal disco"
ci sarebbe "tempo cpu libero" per elaborare in ram a pieno regime
10 volte quello che sta elaborando il thread che attende solo
nell'1% dei casi (in soldoni "ci sarebbe spazio" per altri 10 thread
che hanno i dati gia in ram, e questo senza scomodare l'Hyperthreading
perche il thread "dell' 1%" nel frattempo se ne sta a nanna per tutto
quel tempo.
L. Micheletto


Ti rispondo sinteticamente:
Quello che dici è giusto, ma non hai tenuto conto del fattore differenziale.
Perché sull'AMD dovrebbero esserci queste male predizioni e sull'Intel no?
Altra cosa: è possibile che con 2GB di RAM ci sia comunque un 1% di male 
predizioni??? A regime secondo me dovrebbero essere molte meno, specialmente 
se durante l'elaborazione non viene usata tutta la RAM a disposizione (o 
insomma gran parte di essa, senza arrivare allo swap).
Inoltre considera che una Hit ratio del 90-95% è una cosa normale per una 
cache da 512KB su una memoria da 2GB (il che ci dice che nel 90% dei casi la 
CPU non va nemmeno in RAM), figurati quale Hit Ratio ha la "cache RAM" di 
2GB rispetto alla "RAM HD" da 120GB, saremo intorno al 99,999%.
Quindi un numero realistico potrebbe essere l'1 per qualche milione. Anche 
se l'AMD fosse 10 volte peggio dell'Intel da quel punto di vista il peso di 
questi accessi a disco sarebbe ancora solo del 1 su 100.000, non 1 su 100.
Mah, considerato che l'HT sembra non c'entrare col problema in questione non 
si butta via niente però sono dubbioso...

 Era un modo per simulare e far capire ai testoni cosa implica avere l'HT.
per questo.

 AMD.
il caso e' uno: qualcuno ha sbagliato qualcosa di enorme sulla macchina AMD.

 Sono 2GB su entrambe le macchine.
sul p4 hanno aggiunto un secondo disco "per rendere piu' fluido il 
sistema". evidentemente l'eventuale HT non era sufficiente...

 differiscono solo per 2 istruzioni...
piu' o meno la differenza tra un pentium liscio e un pentium pro. chissa' 
perche' alcuni programmi avevano prestazioni molto diverse...

 no.
a) uno dei pc ha due dischi.
b) in generale hanno hardware diverso.

 perň sono dubbioso...
io userei un'altra parola...

 il caso e' uno: qualcuno ha sbagliato qualcosa di enorme sulla macchina AMD.
la butto la... non è che magari lo scheduler di Linux gioca una sua 
parte, in questa cosa?

 in questa cosa?
Nah, non credo.
--
Xelloss 

 anche se parliamo di un 2.4 contro un 3200+. 
Fornire maggiori dettagli e magari link pare brutto ?
Perche in caso contrario potrei ribattere che ci sono test in cui
la mia vecchia calcolatrice tascabile risultava avere prestazioni
superiori ad un Pentium (con indice relativo tendente ad infinito)
mica un misero 1600%, ma questo non mi ha impedito di usare tale cpu
per il 99.9999% degli altri casi. :-)
L. Micheletto


pur non conoscendo i dettagli del kernel mi sembra difficile...
vero e' che se usa una distribuzione a 64bit allora e' ben probabile che 
usi un kernel 2.6 con il suo scheduler nuovo e con tanto di kernel 
threads...
tuttavia se da quanto ho capito (*) il sottoproblema e' indipendente dal 
resto dei sottoproblemi, sembra piuttosto il tipico caso in cui un processo 
(quello del sottoproblema) e' bloccato in attesa di I/O. se c'e' solo quel 
processo che lavora non puo' fare altro che aspettare, mentre se ce ne 
sono altri (il problema nel suo complesso) possono usare il tempo di cpu 
buttato per fare dei calcoli. questo spiegherebbe perche' nel modello 
totale l'AMD ci mette meno tempo, ma ci mette molto piu' tempo nel modello 
parziale. anzi, sarebbe da provare il tempo di esecuzione su tutti i 
sottomodelli parziali: se la somma dei loro tempi e' molto maggiore del 
tempo che ci mette il programma ad elaborare il modello totale...
(*) come quasi tutti qui non ho mai visto quel programma e non ho la 
minima idea di cosa faccia.

 2GB rispetto alla "RAM HD" da 120GB, saremo intorno al 99,999%.
ROTFL!
L'hit rate *non dipende dal rapporto dimensionale* tra cache e ram*
dipende invece dal rapporto dimensionale tra la cache ed il working set
di  quello che e' in esecuzione *E* da come vengono strutturati
gli accessi ai dati.
ALTRIMENTI la block optimization non avrebbe ragione di esistere
e di dare gli incrementi di prestazioni che produce!!!
Inoltre io parlavo di accessi al disco mal predetti, non si tratta
di cache miss sebbene si possano rappresentare con modelli analoghi
(oltre alla differenza di "peso" pure le cause scatenanti
  sono diverse visto che mentre i cache miss sono un affare privato
  tra applicazione e cpu, negli accessi al disco entrano in gioco
  pure gli algoritmi di caching e prediction del S.O. e del
  disk controller integrato nei drive).
L. Micheletto

 pensato ma non sono mai stati commercializzati.
Non credo proprio scrivo proprio da un P4 2,6@3,2 con HT enable....
Ho anche un P4 2,8@3,5 con HT enable...
ed entrambi li ho presi su tecnocomputer....
se volete le schermate x me nn c'è problema 

 Per caso non sai mica che chipset usa il pc? Così tagliamo la testa al toro?
Va bene il risultato di lspci?
00:00.0 Host bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset Host
Bridge (rev 02)
00:01.0 PCI bridge: Intel Corp. 82845G/GL [Brookdale-G] Chipset AGP Bridge
(rev 02)
00:1d.0 USB Controller: Intel Corp. 82801DB USB (Hub #1) (rev 02)
00:1d.1 USB Controller: Intel Corp. 82801DB USB (Hub #2) (rev 02)
00:1d.2 USB Controller: Intel Corp. 82801DB USB (Hub #3) (rev 02)
00:1d.7 USB Controller: Intel Corp. 82801DB USB2 (rev 02)
00:1e.0 PCI bridge: Intel Corp. 82801BA/CA/DB/EB PCI Bridge (rev 82)
00:1f.0 ISA bridge: Intel Corp. 82801DB LPC Interface Controller (rev 02)
00:1f.1 IDE interface: Intel Corp. 82801DB Ultra ATA Storage Controller
(rev 02)
00:1f.3 SMBus: Intel Corp. 82801DB/DBM SMBus Controller (rev 02)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev
01)
02:03.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone]
(rev 30)
02:07.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev
10)
02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)


oltretutto hd da 6gb che non vanno in udma sono rari rari eh!