Newsgroup: it.comp.hardware.cpu
Titolo: treddone: amd lento elementi finiti ecc. ecc.

... visto che a nessuno e' venuto in mente ipotizzo: magari va piu' piano 
perche' e' proprio piu' lento. 

 perche' e' proprio piu' lento.
Buona questa :-)))
In realtà si cercava di capire PERCHE' è più lento e probabilmente lo si è 
capito benissimo, ma i fan di AMD non sanno rassegnarsi alla tragica realtà 
e le studiano tutte pur di non dover ammettere che in certi casi avere l'HT 
non fa differenze del 2% in più o in meno, ma anche del 300%...
Credo che tra un po' qualcuno ipotizzerà un problema di lentezza della 
tastiera collegata all'AMD... o di campo etereo avverso intorno all'AMD che 
rallenta sensibilmente la frequenza di lavoro della CPU... ;-)))) 

 ma anche del 300%...
No del 1000%.
--
Xelloss

 realtà
Figurati che, estremizzando, anche io ero amd oriented (tanto che in ditta 
ho comprato tutti amd) fino a quando non li ho provati.
L'a64 a 2ghz va esattamente il doppio del duron a 1ghz e cioe' va piano, 
pochi discorsi.
Al prossimo cambio macchine ripassero' a intel.
L'unica cosa buona che hanno e' che non scaldano; avessimo montato prescott 
saremmo incorsi in diversi problemi termici (su alcune macchine di test si 
arrivo' agli 80 gradi... con l'a64 a pieno carico e in estate si arriva a 
54), ma ormai questo penso sia risolto. 


ROTFL..

 
Pero' e' una tristezza, nel senso che allora la scelta e' sempre e
comunque obbligata, ovvero pigliarsi l'Intel.
Insomma, anche se di processori non e' che ci capisca molto, da un
processore come l'AMD64 3200+ mi aspettavo che riuscisse a tener testa a
un P4 di circa un anno e mezzo. Forse e' vero che Abaqus/CAE e'
ottimizzato per Intel, anche a 64 bit...
-- 
Enterprise-E
kirona75 [at] 
gmail.com

 comunque obbligata, ovvero pigliarsi l'Intel.
Ma no, dipende. Dicono che amd sia piu' veloce per i giochi (sara' vero?) e 
sicuramente e' piu' economico.
Per le macchine da ufficio ad esempio forniamo solo ed esclusivamente 
sempron, sono economicissimi, non scaldano per niente e fanno il loro porco 
lavoro.
Pero' per fare i calcoli penso sia da considerare molto bene intel. Dipende 
da cosa uno ci fa. 

 perche' e' proprio piu' lento.
In parte hai ragione: se in un determinato compito l'A64 è più lento non sta 
a noi acquirenti cercare di capire perché lo è.
In generale, però, gli A64 sono degli ottimi processori e il paragone con i 
P4 è al limite del blasfemo...
--
Xelloss 

 i P4 è al limite del blasfemo...
Ecco, queste sono le ca@@ate che fanno veramente cadere le braccia e pensare 
che non ci sia speranza per l'umanità... 

 pensare che non ci sia speranza per l'umanità...
Ha parlato quello che con l'aggiunta di un processore (virtuale, tra 
l'altro) ha incrementi di prestazioni del 300%..
--
Xelloss 

 ha scritto nel messaggio 
news:8jODe.9925$B6.2...@twister1.libero.it...

Se ti rileggi quello che ho scritto in tutti i post e se ragioni sulla 
situazione in questione, forse arriverai a capire che non ho detto nulla di 
assurdo.
Ma dubito che tu lo faccia, uno che sostiene quello che hai scritto sopra, è 
troppo talebano per cercare di valutare le cose con obiettività. 

 di assurdo.
Io ho citato una cosa che hai scritto poco fa, che è un'amena corbelleria 
(sia che tu abbia le conoscenze di base per comprenderlo, sia che tu non le 
abbia). Se non ritiri una scemenza del genere, assumo che la qualità di 
quello che scrivi sia inversamente proporzionale alla quantità...
--
Xelloss 


Guarda, se l'unica applicazione che ci vuoi far girar sopra é Abaqus é 
ovvio che devi orientarti su Intel... peró, con l'avvento dei double 
core economici di AMD, la cosa si volgerá di nuovo favorevole alla casa 
"verde". Infatti un programma ottimizzato per HT volerá letteralmente 
con un double core.
Se poi hai un uso piú variegato, i processori AMD sono sia per rapporto 
qualitá prezzo sia per velocitá pura superiori nell'80% dei casi. Non mi 
sembra che in questo particolare momento del mercato ci sia tanto da 
pensarselo se comprare un A64 o un P4.

 piu' piano perche' e' proprio piu' lento. 
Piu propenso a pensare che i PackerBell facciano PENA ..... come 
hanno sempre fatto del resto ^_^
-- 
Apocalysse
"Io sono l'Apocalysse e dopo di me il nulla"
Forum Samsung:
http://www.anvi.it/forum/index.php?showforum=42
Salsa Cubana:
http://www.encantolatino.it

 
Ok, nel caso fosse una questione di marca, c'e' qualcosa che si puo'
fare per velocizzare il PC a parte buttarlo nel cesso ^__-?


 fare per velocizzare il PC a parte buttarlo nel cesso ^__-?
Innanzitutto bisogna isolare il problema. Purtroppo non abbiamo dati 
sufficienti a capire se il software è intrisecamente più lento sugli A64 che 
sui P4 oppure è colpa della configurazione.
--
Xelloss 

 ha scritto nel messaggio
news:HgPDe.190067$75.82...@news4.tin.it...

Si, cambia la MB che PaccoBell avrà "personalizzato" in maniera
indecente, Bios compreso...;)

 ha scritto nel messaggio 
news:8jODe.9925$B6.2...@twister1.libero.it...

Io sul lavoro uso sia Ahtlon 64 sia P4 e devo dire che quando apro molte 
applicazioni contemporaneamente il P4 non mi fa' mai apettare passando da 
una all'altra,mentre l'Athlon si.
Tutto il resto sono discorsi inutili,il Super Pi ecc. ecc. ,cosa mi frega a 
me se fa' tanti secondi in meno del P4. Io so' solo che con l'Intel non 
attendo nemmeno un istante quando apro un
qualsiasi programma,mentre ne' ho altri 5 o 6 che lavorano in contemporanea. 

 anche del 300%...
scusa massimo ... ma sei patetico...
come già ti ho detto ti aggrappi all' HT come un naufrago
e come un perfetto fan-boy sproloqui un torrente di post
su un confronto fatti su due macchine *diverse*
io non so che lavoro tu faccia
ma anche un bimbo (non fanatico) sa che un test
va fatto su macchine *identiche*
cerca di trovare un po' di pace  :-)
fatti una nuotata...
maurizio 

 ha scritto nel messaggio 
news:dbokep$kef$1...@news.ngi.it...

E' una cosa evidente a chiunque abbia usato entrambi i tipi di processori e 
sia al di sopra delle parti, ma non c'è nulla da fare, è come picchiare la 
testa contro un muro. 

 una all'altra,mentre l'Athlon si.
Io non sto parlando né del P4 né dell'Athlon. Io ho risposto a Massimo come 
si risponde a uno che dice 2+2=8, perché ciò che sostiene lui ha lo stesso 
valore.
Vedi, la maggior parte degli interventi che leggi può essere giudicata sul 
piano del condivisibile/non condivisibile. Quello di Massimo, no: è 
semplicemente falso, come 2+2=8.
--
Xelloss 

 la testa contro un muro.
E' come picchiare la testa contro la logica, Massimo. Puoi apprezzare 
l'hyperthreading e ne hai tutto il diritto, ma se dici cose 
dimostrabilmente, evidentemente false ti metti in ridicolo.
--
Xelloss 

 ha scritto nel messaggio 
news:M%QDe.10951$a5.1...@twister2.libero.it...

Tu continui a dire sciocchezze, non so se lo fai perché sei ignorante o solo 
per flammare.
In condizioni di due processi pesanti su macchina senza HT e su macchina con 
HT, la differenza nelle prestazioni per uno dei due processi può essere 
dell'ordine delle volte (centinaia %), non del 20% in più o in meno, 
semplicemente perché, come sa chiunque abbia davvero usato un P4, ci sono 
casi in cui una CPU senza HT si blocca completamente e impedisce di usare il 
PC, persino di usare la tastiera, mentre con HT si notano rallentamenti 
quasi nulli e si può continuare a fare ciò che si vuole.
Un caso che ho simulato io con un altro personaggio del ng per esempio ha 
mostrato che con SuperPI in parallelo a CPU Burn, l'A64 rallentava le sue 
prestazioni in SuperPI del 58%, cioè ci metteva 2,375 volte tanto (137% in 
più), mentre su P4 ci metteva solo il 32% in più.
Quindi il P4 aveva in quelle condizioni di HT attivo una prestazione 
migliore dell'80% rispetto all'A64.
In condizioni ancora più pesanti, come potrebbe essere quella 
dell'elaborazione continua di una routine matematica iterativa, gli altri 
processi o thread su un A64 possono praticamente arrivare a fermarsi, mentre 
ciò non succede affatto su un P4.
Ad esempio io poso giocare (sempre e solo a scopo dimostrativo) ad un gioco 
di ultima generazione con CPU-burn attivo (e con la priorità normale) quasi 
come se non ci fosse. Prova a farlo su un A64, ti accorgerai che il tuo 
gioco va avanti talmente a scatti da essere ingiocabile. Anche in questo 
caso la differenza di prestazione è enorme.
Ma che te lo dico a fare...

 una all'altra,mentre l'Athlon si.
Macchine con stesso HDD, stessa quantita' di memoria, stesse impostazioni,
ecc. ecc.? Che tipo di applicazioni?
Mi sembra di leggere il post di un altro Ng, in cui si diceva che aprendo
molte applicazioni in Windows e usando "Mostra Desktop" si bloccava tutto
per 2 minuti!

 solo per flammare.
Non solo non sono ignorante: a differenza tua uso anche il cervello. _Non 
esistono, nel senso di "non possono esistere in nessun mondo logicamente 
possibile", un'applicazione, un ambiente operativo, una configurazione tali 
per cui l'attivazione dell'hyperthreading possa fornire un incremento di 
prestazioni superiore al 100%. Nella pratica, e forse anche in teoria, il 
limite è molto più stringente, ma 100% è un limite massimo teorico 
invalicabile; è come dire che non è possibile accelerare un corpo oltre la 
velocità della luce.
--
Xelloss 

 Ma che te lo dico a fare...
A me sembra che tu abbia le idee confuse pero`. 
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 che mandano in stallo tutto. 
Mi correggo qua perche` non sono stato per nulla chiaro.
Non e` che e` tanto questione di cache miss, quelli fanno male a
entrambi. E` proprio questione di avere operazioni in dipendenza di
altre che non fanno avanzare i calcoli al di la` delle grosse (ma
limitate) capacita` di OOE del processore.
I software scientifici pesanti poi sono quasi sempre single thread
perche` i context switch non sono un peso accettabile quando vuoi il
massimo assoluto da un processore, quindi non e` proprio il caso di
tirare in ballo calcoli matematici. 


 pochi discorsi.
Questa potrebbe essere messa fra "le ultime parole famose", tanto che è 
sciocca come affermazione...

 da cosa uno ci fa. 
Per fare i calcoli devi considerare se il software che fa i calcoli 
sfrutta o non sfrutta un ambiente multiprocessore.
Se lo sfrutta un p4 ht porta un certo incremento di prestazioni rispetto 
ad un p4 senza ht, ma di certo questo non raddoppia le prestazioni 
(limite teorico), ma al massimo ottieni un 30% in più (limite pratico).
D'altro canto ci sono applicazioni scientifiche in cui un atlhon64 (non 
dual core) può bastonare sonoramente un P4.

 ha scritto nel messaggio 
news:otRDe.10997$a5.1...@twister2.libero.it...

Bene, allora sei solo ignorante, molto meglio così. :-)))
Quindi posso cercare di illuminarti un po'.
Quello che secondo me sfugge a molti è che l'HT ottimizza l'uso della CPU
ben oltre il fatto di avere 2 CPU virtuali.
In realtà permette di usare cicli di CPU che su un'altra CPU, anche un A64,
semplicemente vanno persi e che andrebbero persi anche sul P4 se non ci
fossero due processi attivi in parallelo.
Quindi non è questione di raddoppio puro e semplice, teorico e virtualmente
irraggiungibile: il fattore moltiplicativo dipende dal carico dei processi e
da quanto l'HT riesce a "recuperare" di quei famosi cicli persi e questo
fattore è tanto più grande quanto più un processo monopolizza la CPU
sprecandone cicli.
E' una questione statistica, non è lineare. Volendo assomiglia un po' alla 
compressione di un file, non si può dire quanto sarà esattamente il fattore 
di compressione, dipende dal file, da come sono strutturati i dati.
Processo pesante e sprecone (molti azzeramenti della pipeline per salti non 
azzeccati) forniscono molti cicli utilizzabili per altri processi in 
parallelo.
Su una CPU senza HT il processo sprecone e monopolizzante semplicemente non 
permette che questi cicli vengano recuperati e quindi gli altri processi 
hanno a disposizione diciamo il 10% della potenza elaborativa della CPU.
Sulla CPU con HT questi cicli vengono recuperati e gli altri processi 
possono ritrovarsi in teoria col 50% della potenza elaborativa della CPU, 
ergo vanno non 2 volte più veloci, ma fno a 5.
E se invece del 10% pensiamo al 2%, allora è possibile anche, in teoria, che 
questi processi in parallelo, vadano 25 volte più rapidi su una CPU con HT 
rispetto ad una senza HT, sempre in condizioni di multitasking pesante.
Quello che secondo me sfugge a molti è che affinché tutto ciò funzioni alla 
grande basta che le dipendenze tra i processi interessati non siano troppo 
strette o non ci siano affatto, come succede quando lancio due applicativi 
che non hanno nulla a che fare uno con l'altro.
L'esempio di Seti@Home è illuminante in questo senso, una CPU con HT
abilitato ci mette molto meno a elaborare due work unit in parallelo di
quanto ci metta la stessa CPU senza HT ad elaborare le due work unit in
sequenza. Eppure la CPU è sempre la stessa ed il clock è lo stesso e non
dovrebbe fare alcuna differenza suddividere le due work unit sulle due CPU
virtuali o sequenzializzare le due work unit.
Qui il guadagno non è enorme (ma comunque si parla del doppio di una CPU 
A64) perché il processo spreca poco, ma il guadagno c'è comunque.

 A me sembra che tu abbia le idee confuse pero`.
Forse non mi hai capito, o non mi sono spiegato abbastanza chiaramente, ma 
secondo me la pensiamo allo stesso modo sull'HT.
Guarda cosa ho risposto a Xelloss poco sopra e fammi sapere. 

 ha scritto nel messaggio 
news:SoSDe.92800$h5.38...@news3.tin.it...

Non avrai difficolta' a smentire una sciocca affermazione con dei dati 
reali. Attendo. 

 poco importante).
E, aggiungo, il clock in questo caso diventa un fattore fondamentale che 
vede amd soccombere.

 hanno sempre fatto del resto ^_^
Eh, la scusa si trova sempre. Io di mio penso che in parecchi casi pratici, 
ivi incluse diverse situazioni di calcolo puro, a64 le prenda dal p4.
Computer alla mano, s'intende: coi benchmark ti posso dimostrare che la 
terra e' piatta. 

 Quindi posso cercare di illuminarti un po'.
Te l'accendo io la luce.
Ipotesi: è in uso un sistema operativo multitasking preemptive in condizioni 
fair, pertanto se i processi attivi sono n, ognuno di essi consuma tempo di 
cpu nell'ordine di 1/n.
Per semplificare supponiamo di avere un processo di test T e un processo 
sprecone S, quindi si avrà che ciascuno dei due processi usa all'incirca 
metà del tempo di CPU, il primo in modo proficuo mentre il secondo manda la 
pipeline continuamente in stallo.
Supporremo inoltre che T abbia bisogno di eseguire per k secondi
Tesi: sul sistema scalare, T termina dopo x secondi di escuzione
sul sistema HT, T termina dopo y secondi di esecuzione.
Vale y >= x/2
Dimostrazione:
Per assurdo. Supponiamo che y < x/2. Essendo in uso uno scheduler fair, nel 
sistema scalare vale che T avrà impiegato 2*k secondi a meno di costanti 
trascurabili. Quindi:
y < (2k)/2 ossia y < k
Ma y < k significa che y ha eseguito per k secondi prima che siano passati k 
secondi!!! Assurdo.
--
Xelloss 

 Eh, la scusa si trova sempre. 
Trollallero, Trollala ! ^_^
Simpatico ;)


 A64) perché il processo spreca poco, ma il guadagno c'è comunque.
Il confronto non e` 'fair'. E` come fare una gara di velocita` sui 100
metri io, e tu sui 110 ostacoli.


 Guarda cosa ho risposto a Xelloss poco sopra e fammi sapere. 
Ora leggo.


 Bene, allora sei solo ignorante, molto meglio cosě. :-)))
Massimo, tu non hai la piu pallida idea con chi stai parlando ..... 
Ti consiglio di ricercare i post di Xelloss nello storico di google, 
prima di dargli dell'ignorante ;)


 vede amd soccombere.
Ma neanche per idea... In questo caso il fattore fondamentale e` il
parallelismo interno e la bassa latenza sulla RAM. I software
scientifici lavorano un casino di ram per le grosse moli di dati da
elaborare.
Prendiamo primordia ad esempio...
Si sta parlando di software scritti bene, come dio comanda, non di
robaccia, ovviamente.
L'unica cosa che puo` salvare il P4 sono le SSE2/3, ma anche con quelle
le prestazioni pure di un A64 sono superiori, c'e` poco da fare. Il
punto e` come e` scritto il software e come e` fatto il compilatore che
lo compila.


 k
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
che T ha eseguito per k secondi
--
Xelloss 

 Ma neanche per idea...
A pipeline piena il clock non e' fondamentale, dici? 

 complessita` aggiuntiva del progetto.
E questa affermazione è ancora più valida considerando che gli stadi
di pipeline per quanto riguarda l' Alu degli A64 sono pari a 12 se non
erro... ;-)
 Ciao


Concordo... anche Dialtone non scherza ;)

 A pipeline piena il clock non e' fondamentale, dici? 
Decisamente no. 
Un sospetto: hai mai studiato architetture a pipeline super scalari? Ma
giusto terra terra, appena qualche simulazione con carta e penna
Se hai il doppio degli stadi, ma non il doppio della frequenza?
Se hai meno unita` di calcolo?
eeeee... Ce ne sono di ragioni da tirare in ballo...
E` cosa abbastanza nota che l'IPC dell'Athlon64 sia superiore a quello
del P4.
http://www.anandtech.com/mac/showdoc.aspx?i=2436&p=3


 prima di dargli dell'ignorante ;)
Quoto...
Oltre a ciň ho notato che piů le risposte sono ben motivate tecnicamente
piů o non risponde o inizia a insultare...evidentemente quando si coglie
nel sengno non sa piů che pesci pigliare..:)

indecente, Bios compreso...;)
La prima cosa da fare è aprire il case, controllare il nome della
scheda madre e cercare subito un aggiornamento del bios.
O il sistema è inchiodato (controlla nel task manager che nessun
processo occupi cpu, il solo Ciclo Idle di sistema deve segnare quasi
sempre 99%) o il programma ha nel codice 3 righe tipo
if (CPUID=="AMD") then 
	for (i=0,i++,i<5000000) 
	sleep;
Non chiedetemi che linguaggio sia, me lo sono inventato!
-------------------------------------------------------------
-+- Dumah, Demone dell'Agonia -+-
"Muhahahahahahahahahah... ah... aaaah... aaaaaatchoooooo... 
snif... prrrrrrt... snif snif... ehm... Muhahahahahahahah..."
-------------------------------------------------------------

 reali. Attendo.
Guarda che sei tu quello che ha detto la baggianata, dimostra tu quello che 
hai detto, non lui, che se vuole puo' postarti 1000 Link a supporto delle 
sue tesi.
Che applicazioni usi?
Office? E che ti aspetti? che scriva prima che tu batti sulla tastiera?
Internet? Ah allora li' intel dice che vai piu' veloce con il P4, c'e' poco 
da fare...
Video-Editing? Gli aumenti non sono mai oltre il 15 max 20% a parita' di 
frequenza/mn.
Giochi? (non credo che li facciate in ufficio :-) ) non c'e' storia...
-- 
Ciao
Riccardo 

infradito ha scritto:

Eccoti servito:
http://www.tomshardware.com/cpu/20041221/cpu_charts-15.html
Ti risparmio i confronti:
UT2004
Athlon64 Winchester 3200+ (2GHz Socket 939) fa 141.6 fps
Athlon64 NewCastle 3000+ (2GHz Socket 754) fa 134.5 fps
Duron Morgan 1300 (1.3GHz Socket A) fa 42.8 fps, è un 1300 MHz e non fa 
  esattamente la metà.
Athlon Thunderbird 1000 (1GHz Socket A) fa 45.0 fps
Far Cry
Athlon64 Winchester 3200+ (2GHz Socket 939) fa 175.5 fps
Athlon64 NewCastle 3000+ (2GHz Socket 754) fa 165.2 fps
Duron Morgan 1300 (1.3GHz Socket A) fa 55.7 fps, è un 1300 MHz e non fa 
  esattamente la metà.
Athlon Thunderbird 1000 (1GHz Socket a) fa 55.0 fps
Ancora:
http://www.tomshardware.com/cpu/20041221/cpu_charts-18.html
Codifica da MPEG-1 a MPEG-2
Athlon64 Winchester 3200+ (2GHz Socket 939) impiega 2.48 minuti
Athlon64 NewCastle 3000+ (2GHz Socket 754) impiega 2.48 minuti
Duron Morgan 1300 (1.3GHz Socket A) impiega 5.45 minuti.
Athlon Thunderbird 1000 (1GHz Socket A) impiega 9:06 minuti.
E qui è significativo vedere come i MHz siano tutto e non conti 
nient'altro (ed infatti i P4 qui vincono ma di poco)
DIV-X 5.2 encoding
Athlon64 Winchester 3200+ (2GHz Socket 939) impiega 2.22 minuti
Athlon64 NewCastle 3000+ (2GHz Socket 754) impiega 2.27 minuti
Duron Morgan 1300 (1.3GHz Socket A) impiega 4.58 minuti.
Atlhon Thunderbird 1000 (1GHz Socket A) impiega 6.00 minuti
Ed anche qui contano solo i MHz.
Se facessi la proporzione con un Duron 1000 capiresti subito dove sta la 
fesseria che hai detto!
Spulciati pure tutte le altre pagine della chart.
Saluti.

infradito ha scritto:

E se io faccio dieci calcoli in un ciclo e tu ne fai uno, dici che il 
clock è proprio fondamentale?
Ahi ahi ahi...

 Non chiedetemi che linguaggio sia, me lo sono inventato!
Una mistura fra Basic e C con bug :)
Senza il then e i punti e virgola al posto delle virgole in C++ forse 
potrebbe anche girare :)




 
Prima di vedere i dati reali, bisogna vedere come 'e stato compilato 
quel programma.

 Dico...ce li ricordiamo queste cose?
E le dici a me queste cose? :) Non devi mica spiegarmele ehe 


 Concordo... anche Dialtone non scherza ;)
Vero, vero :)


 consuma tempo di cpu nell'ordine di 1/n.
Ecco dove sta l'errore.
In pratica non funziona così, ci sono processi che non si comportano in modo 
fair, che non si prendono la stessa parte di CPU che si prendono gli altri.
Possibile che tu, dall'alto della tua secolare esperienza, non abbia mai 
visto un PC praticamente bloccato da un singolo processo, al punto di non 
poter nemmeno usare la tastiera???
E' chiaro che se tu imponi quel vincolo (che non esiste) hai tutte le 
ragioni, dopo.
Ma il vincolo non c'è.
Inoltre, cosa ancora più importante, l'HT agisce a monte del s.o., è un 
"pezzo hardware" che gestisce le "bolle" e le risorse della CPU in modo da 
ottimizzare il funzionamento della CPU, A PRESCINDERE DA CIO' CHE FA IL 
S.O., quindi la tua considerazione è sbagliata in partenza, perché osserva 
le cose al livello sbagliato.
Comunque non voglio continuare a perdere tempo per spiegare cose ovvie, dato 
che anche su internet ci sono benchmark che dimostrano chiaramente che il 
guadagno prestazionale può essere maggiore di 2.
Continua pure a restare della tua opinione, qui mi sembra di essere Galileo 
che spiegava che la Terra era rotonda ed i soloni del tempo a prenderlo per 
il culo.
Fate vobis, che ne sapete tanto... rotfl.
Ciao

 prenderlo per il culo.
PS: Quel pezzo l'ho scritto apposta in modo che tutti possano dirmi che non 
capisco niente, non so nemmeno che Galileo parlava della Terra che gira 
intorno al Sole. 

 poter nemmeno usare la tastiera???
Hai mai fatto teoria dei sistemi operativi?
Esistono risorse preemptable e non-preemptable.
La situazione che citi si puň verificare solamente nel caso in cui vari 
processi concorrano all'utilizzo di risorse non-preemptable (specialmente 
oggetti del sistema operativo). Manco a dirlo, queste risorse non sono 
duplicate sui sistemi HT o multiprocessore, che pertanto possono "bloccarsi" 
allo stesso modo degli uniprocessore.
Ovviamente, il tempo di CPU č una risorsa preemptable.
--
Xelloss 

 Ovviamente, il tempo di CPU è una risorsa preemptable.
Tutto molto bello, solo che in pratica succede esattamente l'opposto di 
quello che dici.
Ci sono processi che su una macchina senza HT la bloccano totalmente per 
minuti o decine di minuti e su una macchina con HT è come se non 
esistessero.
In pratica su una macchina senza HT un processo addizionale ci mette MINUTI 
a fare cose che sulla macchina con HT, nelle stesse identiche condizioni, ci 
mette i soliti SECONDI.
Comunque, se davvero ti interessa sapere come funzionano le cose sul serio, 
rivediti la faccenda alla luce di quanto ti ho suggerito.
Il problema non sono le risorse preemptable, il problema è che certe risorse 
sono sprecate senza HT e vengono recuperate dall'HT. Sono i famosi cicli 
sprecati per le bolle della pipeline e anche FPU, ALU e altri pezzi hw che 
vengono gestiti in modo ottimizzato da questo strato hw aggiuntivo.
Tutto ciò non ha nulla a che fare col preemptable o non preemptable. Come ti 
ho già detto, il caso di Seti@Home è illuminante, si verifica un paradosso 
che con il tuo approccio non è spiegabile: una CPU, sempre la stessa, in 
esecuzione parallela, ha prestazioni superiori quasi del doppio rispetto 
alla stessa CPU in esecuzione sequenziale. In base al tuo approcio ciò è 
semplicemente impossibile, così come è impossibile che si verifichi quanto 
ti ho descritto sopra.
Se invece ti interessa solo avere ragione, hai ragione tu, io di sicuro non 
ho mai studiato Sistemi Operativi col Prof. La Face al Politecnico di 
Torino... rotfl. 

 quello che dici.
Va bene, grazie della chiacchierata, puň bastare.
--
Xelloss 

 ha scritto nel messaggio 
news:M23Ee.11067$B6.2...@twister1.libero.it...

Figurati, non avevo dubbi, grazie a te dell'ennesima conferma... 


Quoto
TheHitch 

 il progetto amd
Non sono d'accordo ,secondo me sono solo due filosofie diverse prese dalle 
rispettive case produttrici.
Mentre l'AMD punta sull'efficenza ,quindi piu' operazioni per ogni ciclo di 
clock,la Intel ha preferito
aumentare la frequenza . Infatti non ci sono A64 a 3Ghz  in commercio . 
Certo a parita' di frequenza
sicuramente un A64 le suonerebbe sonoramente a qualunque P4 .Ma se il P4 
fosse efficente come l'A64
le suonerebbe all'AMD. Sono solo due approcci diversi. E aggiungo meno male 
che esiste concorrenza
altrimenti sarebbe peggio per noi! 

 per 2 minuti!
Macchine con stesso HD e stessa quantita' di memoria Western Digital Raptor 
e 2Gb di Ram.
Le applicazioni sono  due o piu' finestre CAM di solito quattro  un Excel un 
Paint Shop Pro . 

 Figurati, non avevo dubbi, grazie a te dell'ennesima conferma...
Che non puoi competere sul piano tecnico con Xelloss ? non c'è n'era 
bisogno ^_^


 bisogno ^_^
Mi pare evidente che chi non ha saputo/voluto rispondere alle obiezioni non 
sono stato io.
Ma è tipico dei soloni arroccarsi dietro i loro Ipse Dixit, per questo non 
mi sono stupito più di tanto.
Mi stupisce un po' di più che non ci sia nessuno capace di far notare al 
solone che forse qualche ragione ce l'ho, ma tant'è, i soloni fanno paura 
persino in un ng... 

 fesseria che hai detto!
Tra l'a64 e il duron 1300 c'e' un fattore due. Il che significa che l'a64 va 
"poco piu' del doppio" del duron mille, e non "esattamente il doppio" come 
ho detto io, non la definirei proprio una fesseria.
E secondo me rimane poco. 

 Un sospetto: hai mai studiato architetture a pipeline super scalari?
Beh, sono rimasto a qualche anno fa e per questo presuppongo uno stesso 
numero di unita' di calcolo; supponendo alla pari il numero di unita' di 
esecuzione il massimo che si ottiene e' di una istruzione a colpo, per cui 
la frequenza diventa fondamentale.
Almeno a quanto ricordo, eh, ci sta che la frequenza non sia fondamentale 
tra le caratteristiche del processore. 

 le cose al livello sbagliato.
Cheeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee?
Non e` cosi`... Al processore arriva solo una sequenza di microop e
basta. Non arrivano informazioni riguardo al processo a cui appartiene
la microop. Come puo` HT fare quello che dici? Per lui l'istruzione i+1
va eseguita dopo l'istruzione i. Fine.
Se non e` il sistema operativo che manda le microop in coda al
processore logico, chi lo fa?
HT non puo` moltiplicare quello che fa un processore.
Se respiri forte, ti restano sempre 500ml di aria nei polmoni, non e`
che trovando il modo di fare uscire pure quelli poi fai sforzi aerobici
piu` lunghi. Tanto la superficie degli alveoli e` sempre quella e lo
scambio e` sempre uguale.


 tra le caratteristiche del processore. 
E direi che ci sta...


 persino in un ng... 
Perche` non hai ragione, semplice.
Avresti un raddoppio delle prestazioni, cioe` un aumento del 100%,
solo ed esclusivamente se avessi _due_ pipeline indipendenti.
P4 HT condivide il pipeline tra due thread, in modo da ottimizzarne e
massimizzarne l'uso, ma non potra` mai fare meglio di due pipeline,
quindi non potra` mai andare oltre il doppio.
Riguardo ai processi che bloccano il computer, quello e` un problema
di sistema operativo non di CPU.
Il mio K6, con cpuburn lanciato due volte, non batte ciglio, risponde
sempre e comunque in tempo reale, poiche` i due processi ad alto uso
di CPU vengono abbassati di priorita` automaticamente.
Certo che se mi metto a fare, lame non e` molto felice...
bye,
-- 
piergiorgio

 terra e' piatta. 
Ma anche con gli applicativi.
Se la SW house che fa il programma di calcolo, visto che P4 e`
molto piu` diffuso di A64, compila con -march=pentium4, invece
di -march=a64, ecco che il codice risulta ottimizzato per
sfruttare tutti e 31 gli stadi del pipeline e, conseguentemente,
girare male su A64.
E` finita l'era dei 386 o 486, ora le CPU sono si compatibili,
ma sono anche una diversa dall'altra, non e` un caso che i
compilatori offrano ottimizzazioni specifiche per i vari
modelli di CPU (sempre x86 compatibile).
bye,
-- 
piergiorgio


A me invece queste righe sembrano proprio quelle di un IntelBoy.....
Ciao
Andrea 

 ha scritto nel messaggio 
news:CLaEe.221$87.1...@news4.tin.it...
cut
Facevi più bella figura a non dir nulla, piuttosto che a tentare questa 
arrampicata sugli specchi.
Inoltre, se non sai come e perchè si usino i giochi per testare anche le 
CPU, dato che "fps ti sa di scheda video e non ti convince", informati prima 
di fare queste sparate.
Ciao
Andrea 

 tra le caratteristiche del processore. 
Ma P-M (Centrino) nonostante le (ormai non piu`) frequenze
relativamente basse, va che e` un gioiellino.
bye,
-- 
piergiorgio


Xelloss č diventato ignorante? E da quando?
Ah, questi fanboy...
Andrea 

 terra e' piatta.
Computer alla mano, il Pentium 4 è un processore che al pari dell'A64 va un 
pò meglio per alcune cose e un pò peggio per altre.
Sicuramente è un processore sostanzialmente inefficiente, continuamente 
soggetto a modifiche per ottenere prestazioni paragonabili alla concorrenza, 
spesso con risultati tutt'altro che lusinghieri. Ciò non toglie che non sia 
certo immondizia, ma semplicemente un prodotto con un rapporto prestazioni 
sfavorevole ed un'architettura inefficiente. Sul piano delle prestazioni 
pure sul campo, nella maggioranza dei casi mostra tutti i suoi limiti 
rispetto all'A64. Questo non significa che in determinati ambiti non possa 
andare meglio dell'A64, ma sono decisamente pochi.
Ciao
Andrea 

 CUT
Se vai a Zelig, dimmelo che farai sicuramente ridere ^_^


 E secondo me rimane poco. 
E peccato che se raddoppi la frequenza di un duron 1300 ottieni un duron 
2600...
Per farti un raffronto rispetto alla cazzata che hai detto ho messo 
anche un Athlon Thunderbird 1000, che come saprai è sicuramente più 
prestante di un duron 1000, ma con quello non hai fatto confronti anche 
se era più coerente con quanto hai affermato, come mai?
Ah. Ho capito... un altro con i paraocchi che non si rende conto delle 
sciocchezze che dice, e si ostina anche davanti ai numeri...

 Fate vobis, che ne sapete tanto... rotfl.
Non conosco Xelloss, ma da quanto ho letto nei suoi post lo ritengo 
perfettamente in grado di sostenere attivamente una discussione di 
questo tipo.

 piu` unita` di calcolo.
No, io credo anche da prima...
Pensa solo che il primo pentium già era in grado di fare due calcoli in 
un colpo solo...
Inoltre il k6/2 aveva pure le istruzioni simd (single instruction 
multiple data)...

 scambio e` sempre uguale.
No comment... rofl.
PS: Se dopo aver fatto l'esperimento con CPU-burn in real time sul tuo AMD 
hai occasione di ripetere l'esperimento su un P4 con HT capirai finalmente 
di cosa parlo e anche di quanto è bello non perdere il controllo del proprio 
PC. 

 altrimenti sarebbe peggio per noi! 
Sono d'accordo sul fatto della concorrenza, ma non sono d'accordo sul 
fatto che i P4 sono più avanzati tecnologicamente o che sono migliori 
perché hanno HT o altre cazzate immonde che si sono sentite dire in 
questo thread da un fan boy.

 
Quoto e sottoscrivo !!
-- 
http://distrowatch.com
 se sei curioso ..
Dottor Rossi .. l'italiano volante !

 tipo.
Non l'ha fatto. Altro non so.
E dalle mie parti gli assenti hanno sempre torto. 

 PC. 
Io so di cosa parlo visto che te l'ho insegnato io come funzioni HT.
Pero` l'hai imparato male... Inoltre sai pure leggere poco. Io ho un
iBook G4 1.3Ghz.


 Secondariamente, io non sono gentile come Xelloss.
;-)
--
Xelloss 

 cioè real time)
E' chiaro: voglio misurare le prestazioni di un'applicazione sul mio sistema 
e cosa faccio? dico allo scheduler che altre applicazioni consuma-risorse 
sono più importanti. Sei un genio.
Dell'umorismo involontario.
--
Xelloss 

 Sei un genio.
Siamo in 2 a pensarlo allora.
Dev'essere un incompreso, probabilmente non si capisce neanche da
solo... Magari il cervello non lo comprendeva e se n'e` andato.


 perche` tanto nessuno ti ascoltera`. Fermati ora per il tuo bene.
Mavaffanculo, va!!!

 ha scritto nel messaggio 
news:eseEe.12201$B6.3...@twister1.libero.it...

Mi fai un po' pena sai? 

 Siamo in 2 a pensarlo allora.
vi prego, continuate. Io nel frattempo vado a prendere pop-corn & 
coca-cola per gustarmi il crepuscolo di un nick in diretta.

 Mavaffanculo, va!!!
Bravo puffolino.


 Non l'ha fatto. Altro non so.
Ah si... continua pure ad essere convinto delle sciocchezze che dici.
Magari se mi dai il tuo indirizzo ti spedisco un buon libro di Sistemi 
Operativi... Prima che tu ne scriva uno tutto tuo! :)

azz..... che tread .... >:| >:| >:|
saluti
-- 
Mo3bius
http://forum.hwupgrade.it/index.php?s=
http://forum.hwupgrade.it/forumdisplay.php?s=&forumid=15

 Mi fai un po' pena sai? 
Trollallero Trollalà ! ^_^


 discussione di questo tipo.
E anche di piu, fidati ^_^


 CUT
Ma intel lo dichiarò che non voleva puntare alle prestazioni, ma ai 
Mhz ..... quindi ! :)


 thread da un fan boy.
Non diro' mai che i P4 sono piu' avanzati di A64,credo pero' che gli 
ingegneri di Intel
abbiano introdotto HT proprio perche' il processore P4 non brillava 
molto,cosi'
da poter sfruttare in modo piu' intelligente le 31 pipeline presenti nei 
Prescott.
Ricordo che nei precedenti P4 NorthWood le pipeline erano di meno 21?
Credo le abbiano aumentate a 31 proprio per favorire HT.
Qui a casa ho un P4 3Ghz overclockato a 3.25 e un Sempron a 2,256Ghz.
Ho provato a disabilitare L'HT dal Bios e con alcuni programmi aperti
in contemporanea il P4 si "siede" e non si muove piu' mentre il Sempron 
continua
a funzionare egregiamente. Mentre con l'HT attivo le cose si ribaltano

 Bravo puffolino.
Sì, ribuonanotte, ridicolo. 

 riconfermo.
E buona camicia a tutti.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
http://weever.berlios.de

 
ha scritto nel messaggio news:1h05f82.1px2opk1y5p02cN%dial%23%23%23%23%23
Non ho nemmeno letto quello che hai scritto, mi son bastate le prime righe, 
chiudiamola qua.
Sei un poveretto e non voglio infierire oltre.
PS: Chissà, forse mi illudo, ma mi piacerebbe che anche in questo ng così 
tremendamente di parte e con degli emeriti imbecilli della tua stazza, una 
persona seria provasse a spiegare perché quello che io sostengo è 
sostanzialmente corretto e spiega certi fenomeni che sono davanti agli occhi 
di chiunque usi un PC da più di 3 settimane.


Ho letto adesso che mi minacci di nuovo di farmi sparire dal ng.
A parte che già solo una cosa del genere (ripetuta due volte) ti qualifica 
per quel che sei senza che sia necessario aggiungere altro, resta il fatto 
che io non ci guadagno nulla a scrivere in questo ng, se l'ho fatto era solo 
per portare il mio contributo ed eventualmente correggere quelle che io 
ritenevo delle distorsioni della realtà presenti nell'approccio di alcuni 
postatori.
Questo naturalmente va a favore dei frequentatori del ng che possono 
decidere chi sta dicendo cose più sensate, ma a me non ne viene nulla in 
tasca, quindi posso smettere quando voglio e la tua minaccia mi fa veramente 
ridere.
Oltre a farmi capire perché ti comporti in questo modo assurdo: tu, in 
questo ruolo di guru del ng, ti ci identifichi, trai forse una delle poche 
ragioni di soddisfazione della tua triste vita e pensi che sia lo stesso per 
gli altri.
Non è così per me, grazie a dio c'è altro nella mia esistenza.
Ciao, mentecatto. 

 occhi di chiunque usi un PC da più di 3 settimane.
Se dici stronzate...
Dopo aver cambiato la tua posizione da "HT aumenta le prestazioni anche di 
quattro, venticinque volte" in "HT aumenta le prestazioni all'infinito a 
patto che io stia facendo di tutto per rallentare il sistema senza HT" 
(rumore di unghie su vetri) pretendi ancora di aver ragione.
Provo a spiegartelo un'ultima volta, vediamo se ci arrivi.
La valutazione delle prestazioni va fatta in condizioni eque, eliminando 
colli di bottiglia.
Se io ho un processo a priorità RealTime, bisogna che siano le prestazioni 
di QUEL processo ad essere misurate.
Ti seguo per un attimo nel tuo scenario allucinato. Come al solito 
individuiamo un modello: T e S sono i soliti processi Test e Sprecone.
Ipotesi:
S: RealTime
T: Normale
S passa quasi il 100% del tempo con la pipeline vuota
Sul sistema scalare, S eseguirà per quasi il 100% del tempo di CPU, 
stallando la pipe praticamente ad ogni istruzione. T è in starvation ed 
esegue per lo 0% o poco più.
Sul sistema HT, S allo stesso modo esegue per quasi il 100% del tempo e 
stalla la pipe di continuo; solo che in questo modo lascia libero 
praticamente il 100% di CPUtime per la seconda CPU logica e quindi per T, 
che così eseguirà anch'esso per poco meno del 100% del tempo.
WOW, sei contento? L'incremento di prestazioni per T è praticamente 
infinito! Che bello!
Ma d'altra parte, ci chiediamo: chi terrebbe il processo S con priorità 
RealTime se non fosse per nulla importante? E' evidente che una qualche 
importanza ce l'ha, e andiamo dunque a misurare il suo incremento di 
prestazioni. Nullo. Eh sì: non ha beneficiato neanche un po' di HT, perché 
il sistema scalare stava già eseguendo soltanto lui.
Strano eh? Il processo a cui abbiamo assegnato priorità più alta, cioè 
teoricamente quello più importante, ci dà l'impressione che HT non serva a 
una cippa, testimoniando che il tuo scenario, oltre che patologico e (come 
vedremo fra poco) male interpretato, ha anche risultati contrari a quelli 
che vorresti tu...
Ma qual è la giusta interpretazione per questo scenario? Molto semplice: in 
queste condizioni (che nella realtà sono impossibili, dato che per farti un 
favore ho ipotizzato una frequenza infinita per gli stalli di pipeline, 
nonostante un'istruzione ogni tanto debba essere eseguita per forza) i due 
processi S e T, collettivamente, utilizzeranno la CPU hyperthreaded per un 
tempo doppio rispetto alla CPU scalare. Doppio, incremento del 100%, non del 
300% o del 2400%. Capisci? Non c'è modo per incrementare l'efficienza di 
oltre il 100%.
COME TI HO GIA' DETTO IL 100% E' UN LIMITE INVALICABILE, IN REALTA' 
IRRAGGIUNGIBILE E IMPOSSIBILE ANCHE DA AVVICINARE!!!
Ma se ancora non fossi convinto, ti faccio notare un'ultima cosa.
Tu hai creato un collo di bottiglia sul sistema scalare, che impedisce a 
un'applicazione di sfruttare la CPU; perché mai questo collo di bottiglia 
non influenza il sistem hyperthreaded?
Semplicemente il sistema HT dal punto di vista software è costituito da due 
CPU separate su cui non si può schedulare contemporaneamente lo stesso 
processo. Ne segue che su HT non puoi costruire un collo di bottiglia con un 
solo thread: ce ne vogliono almeno due. E infatti se sul sistema HT metti 
DUE processi realtime mangiarisorse, il tuo processo di test rimarrà 
piantato esattamente come sul sistema scalare.
Morale della favola: le prestazioni vanno misurate in confronti fair, 
altrimenti puoi dire tutto e il contrario di tutto, come in quei benchmark 
limitati dalla scheda video che non mostrano differenze di prestazioni tra 
vari processori...
Saluti.
--
Xelloss 

 coca-cola per gustarmi il crepuscolo di un nick in diretta.
ROTFL :D
Ciao!
Simone.
-- 
*Chandler* : "Se fossi un supereroe che può volare ed è invisibile. sarebbe 
il massimo"
(M.Perry - Friends) 

 vari processori...
No, le prestazioni vanno verificate a seconda di ciō che sto cercando di 
verificare. Se voglio sapere la velocitā massima di una Ferrari 430 non mi 
metto a prendere il tempo mentre č ferma in coda al semaforo, la misuro in 
fondo ad un rettilineo abbastanza lungo da permetterle di raggiungere la sua 
massima velocitā.
Comunque ti ringrazio, forse tu non l'hai ancora capito ma con questo post 
hai finalmente ammesso che ciō che dicevo io era del tutto corretto. 

 verificare.
E insomma, che cosa credi di aver verificato? Che se impedisco 
artificialmente a un processo di eseguire su un processore, per ottenere lo 
stesso risultato su HT devo impedirgli artificialmente di eseguire su 
entrambi i  processori logici. Wow, complimenti :-)
P.S: ma lo sai cosa si intende per "scenario patologico"?
--
Xelloss 

 (rumore di unghie su vetri) pretendi ancora di aver ragione.
del resto e' il massimo tifoso di intel... 
curiosamente e' venuto fuori a luglio, col caldo. si vede che e' una 
condizione in cui da parte intel ci si sente a casa...

> storie?
come no? il mio scheduler la mattina mi fa anche il caffe'. e non ti dico 
quando mi fa le fusa...
 

 P.S: ma lo sai cosa si intende per "scenario patologico"?
Incomincio a rendermi conto di trovarmi di fronte a un bell'esempio... 

 Incomincio a rendermi conto di trovarmi di fronte a un bell'esempio...
Non lo sai.
--
Xelloss 

 a funzionare egregiamente. Mentre con l'HT attivo le cose si ribaltano
Se il p4 si siede nel senso che si blocca completamente hai un problema 
di qualche tipo, mentre se intendi che va piano allora è semplicemente 
poca potenza di calcolo (o poche risorse, tipo memoria).

 Non lo sai.
Incomincio a saperlo, se insisti ancora un po' a negare l'evidenza, lo saprò 
definitivamente. 

 saprò definitivamente.
Aiutino: 
http://www.google.it/search?hl=it&q=%22pathological+case%22+math&btnG=Cerca+con+Google&meta=
--
Xelloss 

 condizione in cui da parte intel ci si sente a casa...
Ma la tifoseria non è un fatto nuovo da queste parti, ci si fa il callo. E 
poi in condizioni di predominio non nettissimo si può accettare che 
l'acquisto di una CPU sia guidato anche dalla simpatia. Quello che è 
inaccettabile è che una persona decida che le sue opinioni sono la verità 
anche quando si tratta di sciocchezze conclamate.
Normalmente questo tipo di persone non dovrebbero essere degnate di 
risposta; purtroppo qualche frequentatore inesperto potrebbe essere confuso, 
e allora siamo costretti a puntualizzare.
--
Xelloss 

 risultati pratici e gratificanti dal suo utilizzo.
Te lo dico scandendo le parole:
Tutti - gli - scheduler - del - mondo - aprono - i - processi - con -
priorita` - normale. - Se - vuoi - cambiarla - lo - fai - tu. - I -
processi - non - cambiano - priorita` - da - soli. - L'utente - normale
- non - sa - neanche - cosa - cazzo - e` - la - priorita` (esattamente
come te che farnetichi di processi che si prendono il processore, o
diventano real time, sa dio cosa hai in testa...).


 e allora siamo costretti a puntualizzare.
Esattamente. Come ai bei vecchi tempi :)


 diventano real time, sa dio cosa hai in testa...).
E tu saresti un esperto di computer?
ROTFL!
Quindi secondo il tuo illuminato parere, uno scheduler sono 5 righe di 
codice, non deve far altro che dare la CPU a qualunque processo la chieda, 
senza occuparsi di nulla, di quali I/O faccia, di quali lock abbia, di quali 
concorrenze abbia con altri thread o processi, senza occuparsi della 
competition per le risorse, nulla, il tuo fantastico scheduler continua a 
dare una timeslice per ciascun processo su una base strettamente round-robin 
senza alcuna variazione, senza alcuna dinamicità, senza mai deviare dalla 
sua fenomenale e astutissima strategia?
O forse stavi parlando di come usate il pallottoliere in famiglia?
RI-ROTFL! 

 e allora siamo costretti a puntualizzare.
dai in fondo e' estate ed e' pure divertente :p

 sua fenomenale e astutissima strategia?
saro' buono e conciso: dove l'avrebbe scritta sta roba?
nb: non ti sto chiedendo cosa hai capito, ti sto proprio chiedendo dove 
*lui* ha scritto quel che gli attribuisci.
comunque, tanto per chiarirti le idee: in generale uno scheduler assegna 
la cpu ai processi R2R, non a quelli bloccati (e quindi 3/4 delle tue 
putt... ehm interessanti obiezioni perdono significato). cosa poi ci 
faccia con quel tempo di cpu un processo non e' affare dello scheduler 
(almeno finche' non compie operazioni che lo fanno bloccare o che gli fanno
modificare priorita'). poi esiste una miriade di algoritmi per decidere quale
tra i processi nella coda R2R andra' in esecuzione dopo il corrente. 
tra questi si possono citare  il round robin senza priorita',  piu' code 
di round robin con priorita' diverse, algoritmi con priorita' (calcolate 
nei modi piu' disparati)... nota che il round robin puro e' una delle 
possibilita' e non e' nemmeno la piu' stupida. anzi, se i processi hanno 
tutti uguale importanza, e' la scelta *migliore*, perche' evita il tempo 
perso a calcolare le priorita'.


A momenti rischia di entrare nel guinness dei primati in fatto di lunghezza
e di
divertimento oserei dire...;-D

 divertimento oserei dire...;-D
Nhaaa, quelli piu lunghi sono su IFD :D
-- 
Apocalysse
"Io sono l'Apocalysse e dopo di me il nulla"
Forum Samsung:
http://www.anvi.it/forum/index.php?showforum=42
Salsa Cubana:
http://www.encantolatino.it

 perso a calcolare le priorita'.
Sì, sono tutti dettagli molto belli, sono perfettamente d'accordo con te, il 
risultato finale è che su una CPU in qualunque momento si trovano processi 
che hanno priorità e tempi di CPU diversi (e questo di solito è ben 
difficilmente controllabile dall'utente, nel modello di uso normale dei PC 
odierni).
Se ciò succede su una CPU mono e senza HT, il processo con meno tempo di CPU 
ha prestazioni ridotte, su una CPU mono con HT, generalmente ha le stesse 
identiche prestazioni perché non deve aspettare il suo turno (ridotto) ma 
può girare in parallelo al processo *favorito*, utilizzandone le risorse da 
lui sprecate.
Questo è dovuto, come ho già detto miliardi di volte, al fatto che HT 
permette di recuperare una parte o gran parte delle risorse sprecate (per 
forza sprecate) dai processi e quindi dà la possibilità di gestire due 
processi in parallelo.
Su una CPU mono questo semplicemente non succede, perché la CPU è mono e 
basta.
Quindi, riassumendo, una volta capito come funziona il parallelismo di 
utilizzo della pipeline e capito che i tempi di CPU non sono uguali per 
tutti i processi, si capisce perfettamente il fatto che certi processi su 
una macchina HT in condizioni di multi-tasking possono avere prestazioni 
nettamente superiori a quelle che avrebbero su una macchina senza HT.
Per concludere, si capisce anche che è abbastanza ozioso valutare la 
differenza tra Intel e AMD su differenze di qualche percento in più o in 
meno in questo o quell'ambiente, quando in realtà l'unica differenza seria a 
favore di Intel è l'HT che ti dà un uso del PC qualitativamente diverso, ti 
permette cose che con AMD semplicemente non esistono e ti permette in certe 
condizioni di carico e per certi processi in parallelo ad altri, differenze 
prestazionali dell'ordine del 70%-80%-100% in più e anche oltre e a favore 
di AMD è la straordinaria efficienza energetica, che permette di avere 
prestazioni analoghe (senza HT) con metà del consumo.
Quindi è su queste due variabili che si deve basare la scelta tra una CPU e 
l'altra, magari tenendo presente che in ambiente giochi 3D AMD ha un 
vantaggio prestazionale e inoltre non si perde nulla (almeno per ora, coi 
giochi fondamentalmente monothread) per il fatto di non avere l'HT. 

 anche oltre e a favore 
io con la mia macchina, in certe condizioni (*), riesco a fare 100km con 
un litro. 
(*) in piano, in folle, a motore spento, spingendo, in 4 mesi.
PS
mi viene il dubbio che tu confonda la priorita' di un processo con il 
suo stato. sono due cose completamente diverse: un processo che attende la 
pressione di un tasto non ha priorita' minima, e' semplicemente nello 
stato "attesa di I/O", cioe' bloccato.

 hai affermato, come mai?
Perche' parlavo di duron.
E con i tuoi dati alla mano il duron 1300 impiega 5.45 minuti, il doppio 
dell'a64. Il resto sono sciocchezze.
(*) ti risparmio di cercare altri benchmark e ti anticipo: va un po' piu' 
veloce della meta' del duron 1300. 

 girare male su A64.
Per inciso, sarebbe anche ora di sfruttare le caratteristiche dei vari 
processori. Ad esempio non trovo un compilatore che sfrutti non dico i 64 
bit, ma almeno i registri in piu' dell'a64 (supposto che siano accessibili 
in modalita' 32bit), sarebbe un passo notevolissimo. Sempre sotto windows 
intendo, non credo che gcc si integri con visual studio purtroppo.
Ottima l'idea del compilatore intel che crea codice condizionale a seconda 
del processore trovato. Peccato che, se non erro, non preveda 
l'ottimizzazione per a64.

 E direi che ci sta...
Mah. Sara' come dici tu ma rimango del mio parere. A maggiori frequenze 
corrispondono maggiori velocita'. 

 in modalita' 32bit)
non lo sono.

 potenza di calcolo (o poche risorse, tipo memoria).
Intendevo dire che senza HT rallenta paurosamente.Non ci sono problemi di 
memoria. 

 corrispondono maggiori velocita'. 
La realta` dei fatti ti da torto, senza neanche tirare in ballo intel e
amd. Basta solo Pentium 4 e Pentium M.
Non capisco il significato di questa affermazione che sa di falsita` da
tutti i pori.


 giochi fondamentalmente monothread) per il fatto di non avere l'HT. 
No, le variabili non sono HT e consumo, sarebbe abbastanza stupido 
ridurre la questione a due sole variabili, quando in mezzo ci sono i 64 
bit, le possibilità di upgrade, l'inquinamento acustico, l'ambito di 
utilizzo di preferenza, il rapporto prezzo/prestazioni (!) e altro ancora...

 veloce della meta' del duron 1300. 
Di altri benchmark non ne ho bisogno. Chiunque con un po' di sale in 
zucca e una discreta conoscenza dell'ambito in questione capirebbe come 
hai detto una panzanadi di ordine totale, infatti i post di diverse 
altre persone lo hanno confermato.
Poi fai come ti pare.

 falsita` da tutti i pori.
Eh, ma vuoi mettere ?
TreGiggaErtzzz contro UnoSetteGiggaErtz 
Non c'è storie dai ! :)


 potrebbe anche girare :)
Amd ha fatto causa ad intel per questo no? Intel immette un compilatore
che rallenta di fatto se girato su macchine AMD

Dopo dura riflessione, Lorenz ha scritto :

Ciao Boss :) , beh era da un pezzo che non leggevo cose cosi' :):):)
Toto e Peppino non avrebbero saputo fare di meglio ...lol ....
Cmq non vedo onestamente il motivo di scannarsi in questo modo ......
Ognuno  sceglie la cpu e la piattaforma in funzione di quello che deve 
fare in maniera
che risulti il piu' possibile aderente alle proprie aspettative ....
Tutto il resto e' aria fritta .
ciao :)
-- 
Mo3bius
http://forum.hwupgrade.it/index.php?s=
http://forum.hwupgrade.it/forumdisplay.php?s=&forumid=15


Saluti :-)

seoman ha scritto:

Amd ha fatto causa ad Intel perché quest'ultima ha pagato tangenti ai 
propri clienti per non avere a che fare con AMD.
E il compilatore generava un compilato più lento se compilato su un 
processore amd.

 processore amd.
Piu' che altro il compilato e' piu' lento se gira su macchine amd, 
altrimenti basterebbe che venisse compilato su intel e poi venga fatto 
girare su amd.
-- 
Ciao
Riccardo 

 Ti ho dimostrato matematicamente il contrario.
Quello che sostiene quel malato e' l'incremento di prestazioni non di
tutto il sistema, ma del processo che si "infila" nei cicli sprecati:
richiamando il tuo modello, il processo T che si pappava lo 0,1% delle
risorse, con HT si pappa il ~100%, con un incremento relativo di 1000
volte.
Quindi, la prossima volta, tenetelo in mente e calategli la testa, per 
il bene del gruppo :)
-- 
Dont         |            _             _ 
understimate |   __ _ _ _| |_ __ _ _ _ (_)
the power    |  / _` | ' \  _/ _` | ' \| |
of...        |  \__,_|_||_\__\__,_|_||_|_|

 prossima ad un duron 1000 nelle tabelle che ho riportato è un Athlon
E' il duron 1300, che va alla meta', da cui si evince che il duron mille va 
a poco meno della meta'.
Ora francamente non mi interessa di convincerti di questo fatto per me 
completamente irrilevante e questa discussione sta diventando noiosa.
In svarati mesi di uso, nell'uso che viene fatto nella mia ditta, l'a64 si 
e' dimostrato al di sotto delle attese (in alcuni casi - addestramento di 
reti neurali nel caso specifico - e' piu' lento del p4 2.4ghz del portatile 
da cui sto scrivendo) e al prossimo cambio macchine ripasso a intel.
Se questo ti provoca dei problemi pazienza, spero che eviterai di rendermene 
partecipe con un ulteriore post. 

 tutti i pori.
A pipeline piena (e ipc uguale, aggiungo ora) la frequenza e' un fattore 
fondamentale. Se non ci fosse questo spettro del confronto intel-amd 
potresti leggere la frase per quello che e', ossia una quasi banalita'. 

 potresti leggere la frase per quello che e', ossia una quasi banalita'.
Beh certo. Se blocchiamo anche le possibilita` di progettazione diverse
(quanto tempo si impiega per fare un'operazione in virgola mobile ad
esempio) allora resta solo la frequenza e ovviamente e` fondamentale...


 corrispondono maggiori velocita'. 
enorme sciocchezza. perfino Intel si sta sbracciando per dire il 
contrario, adesso che non riesce più a salire in frequenza.

 va a poco meno della meta'.
Allora non hai capito niente: hai presente cosa significhi core diversi?!
Ciao,
    Beppe. 

 girare su amd.
Invece io avevo letto in giro proprio che il compilato su una macchina 
amd era diverso da quello fatto su una macchina intel, il che mi aveva 
fatto pensare a quanto fosse imbecille una cosa del genere...
Cmq meglio gcc per tutti...

BlueD ha scritto:

Già, esatto. il model number gli dovrebbe ricordare qualche cosa...

 partecipe con un ulteriore post. 
Non è il fatto che l'uso nella tua azienda di a64 sia stato meno 
fruttuoso di quanto sperato che mi fa perdere la pazienza, quanto 
piuttosto la chiusura mentale che ostenti a tutto il ng.
Il mio scopo era quello di farti capire che hai detto una sciocchezza 
basata su una sola esperienza, e che i benchmark di più fonti dicono 
esattamente il contrario di quello che hai affermato, quindi ti invito a 
documentarti prima di aprire bocca, altrimenti per quelli come te c'è 
it.free.test

 enorme sciocchezza.
Rotfl. 


sei un mentecatto. sappilo.

 Beh certo.
Visto? Non era difficile.
Ora prova col passo successivo: la frequenza e' importante, tanto da rendere 
un progetto cesso come quello del p4 comunque performante. 

 No.
Secondo te quindi la frequenza non e' importante. Se vuoi puoi sostenere 
questa posizione elaborando ulteriormente, ho l'impressione che sara' 
interessante. Ad esempio spiega cosa, se non e' la frequenza, rende un 
progetto come il p4 comunque performante. 

 un progetto cesso come quello del p4 comunque performante. 
No. perche` ci sono troppe variabili in gioco. Ma se tu, per voler avere
ragione, le blocchi tutte (anche se non sono bloccate) e le porti tutte
alla pari (anche se non sono tutte alla pari), allora hai ragione.
In pratica hai ragione in una realta` parallela. COMPLIMENTONI!!
Anche la X5 della mia ragazza va piu` della Ferrari F1-2005. Infatti se
metti lo stesso numeri di cavalli alla X5, se metti il telaio della
Ferrrari, se metti le gomme e le sospensioni della ferrari, se copi
tutto il resto dalla ferrari tranne la cilindrata (4000 per l'X5, 3000
aspirato per la F1). E` cosa nota che un 4000cc va piu` di un 3000cc no?


 progetto come il p4 comunque performante. 
"""
Hai tirato in ballo un processore reale. Quindi da ora in avanti si
parla di casi reali, niente stronzate come il tuo amico cretino, o
pipeline sempre piene.
Ti chiederei di definire "comunque performante". In base a che criterio?
Spannometro? E` banale:
Lo spannometro e` tanto sofisticato quanto sbagliato.
Lo spannometro e` talmente stupendo come strumento che misura la
distanza tra il click sull'applicazione e il tempo in cui questa si
disegna a video.
Ma... Che succede quando clicchi sull'applicazione?
La CPU manda una richiesta al disco fisso (via DMA), il disco fisso
carica tutto l'eseguibile cliccato in ram e quindi risponde al DMA dando
l'indirizzo del primo byte copiato nella ram. Il processore legge quanto
puo` dalla ram e infila in cache (se la cache e` grossa ci sta tutto
l'eseguibile, altrimenti no e gli tocca prenderne un pezzo e poi
sostituirlo, e poi sostituire il pezzo sostituito ecc ecc) dalla cache
inizia poi la vera e propria esecuzione.
Che infine porta alla comparsa della finestrella.
Che c'e` in mezzo a tutto questo?
1) La velocita` dei dischi
2) La posizione sul disco dell'eseguibile (magari non lo sai, ma i
dischi hanno prestazioni piu` scadenti agli estremi del piatto).
3) La banda passante libera tra Disco-Ram e  tra CPU-Ram.
4) Il numero di unita` di calcolo
5) Set di istruzioni addizionali ed eventuale supporto dell'eseguibile
6) latenze nell'accesso alla ram (chiedo al chipset esterno o al
northbridge integrato?)
7) latenze di accesso alla cache L1, L2
8) ampiezza dei bus dati interni del processore.
9) qualita` delle unita` di calcolo
10) velocita` della ram
11) Come cacchio e` scritto l'eseguibile?
e tanto altro se ci sto ancora a pensare.
Il magnifico spannometro non e` in grado di capire che:
A) Il P4 ha il DOPPIO della cache degli altri processori.
B) Se l'applicativo App e` scritto per supportare al meglio SSE2/3 e
altre estensioni, tipo HT, anche se e` piu` lento in tutto il resto
sara` piu` veloce a fare l'operazione X visto che l'ho ottimizzato io
per fare cosi`.
v. sopra, se ci sto ancora a pensare ne vengono fuori altri.
Detto questo, al tuo solito, immaginiamo una situazione proveniente da
una realta` parallela:
1) I dischi sono tutti veloci uguali
2) La posizione sul disco degli eseguibili e` sempre uguale perche` i
miei fs indicizzano per numero di caratteri contenuti nel file.
3) Banda passante non e` un problema perche` e` infinita.
4) Le unita` di calcolo sono pari (anche se non e` vero)
5) Le istruzioni addizionali non esistono.
6) la ram non ha latenze di accesso
7) cosi` come L1, L2 e L3...
8) il bus dati del processore ha ampiezza infinito
9) unita` di calcolo certificate dal creatore in persona
10) le ram sono cosi` veloci che ho installato un freno a mano nei casi
di necessita`.
11) Gli eseguibili sono uguali.
Facendo finta che tutte le possibili variabili (che comprende pure,
qualita` del chipset e altre che non ho riportato) siano inesistenti
(chi mai andrebbe a considerare la velocita` della ram per decidere di
cose simili... o le sue latenze...) allora magari hai ragione tu.
Facciamo che invece dello spannometro usiamo software adatto:
Il software adatto e` fatto per girare in cache. 
La cache del P4 e` piu` grossa e ci sta tutto. La cache e` enormemente
piu` lenta di un ciclo di clock. Diventa quindi lei il collo di
bottiglia. 
Questo rende comunque il processore performante anche se piu` lento (non
mi fotte se di 1usec o di 10 secondi, e` piu` lento. punto.)
Innumerevoli test dimostrano come gli Athlon 64 siano i piu` potenti
processori esistenti, ovviamente sono test fasulli.
Se rispondi ancora quotando una sola parola presa dal contesto ti sbatto
nel killfile e ti segnalo all'abuse. Sia chiaro fin da subito. 
Se devi quotare una parola tagliandola dal suo contesto (cambiandole di
significato a tuo piacimento) evita di farlo e risparmia caratteri.


 progetto come il p4 comunque performante. 
La frequenza, come già detto più volte qui, altrove, sul web, dalle 
riviste specializzate, dai chi i processori li fa e da tutti gli altri 
che ne sanno qualcosa, non conta. Oppure, se vogliamo essere più 
elastici, conta in maniera relativa.
Ti invito a pensare: sei a conoscenza della questione fra i sostenitori 
dei CISC e quelli dei RISC di qualche tempo fa?
Ebbene, i secondi vantavano che i processori RISC (architetture con 
poche istruzioni ad alto parallelismo) rispetto ai CISC (architetture 
con molte istruzioni a basso parallelismo) avevano la capacità di 
eseguire un numero di istruzioni di un ordine di grandezza superiore 
alla stessa frequenza di clock!
Quindi se un cisc mi faceva 100 istruzioni al secondo, un risc me ne 
faceva 1000 !
E la cosa bella era che questo era vero!
Tant'è che oggi i processori x86 accettano istruzioni macchina cisc, ma 
scompongono il codice cisc in microistruzioni risc per elaborarlo in 
maniera parallela e, quindi, più veloce!
Tutto ciò accade dai tempi del Pentium Pro.

 nel killfile e ti segnalo all'abuse.
Rotfl.