Newsgroup: it.comp.hardware.cpu
Titolo: Taylor vs Barton

Non è un incontro di pugilato. :-) Vorrei paragonare l'XP-3000+ con il TL-52 
contenuto nel nuovo specchio da 17'' che mi è arrivato qualche giorno fa 
(ASUS AT7C 7S010H).
Ho voluto fare il paragone usando un programma che passa la quasi totalità 
del tempo a fare operazioni elementari su numeri interi (per chi muore dalla 
voglia di vedere il programma, questo è il link:
http://www.webalice.it/cristiano.pi/rabigete/
).
Per verificare il vantaggio apportato dal dual-core, ho modificato la 
versione originale da singolo thread a dual-thread (in cui, per la maggior 
parte del tempo, sono attivi due thread contemporaneamente).
Questi sono i risultati dei tempi d'esecuzione (in secondi) in cui "single" 
è la versione del programma a thread singolo e "dual" è la versione con due 
thread contemporaneamente:
Barton / single: 44,78
Taylor / single: 58,55
Barton / dual  : 44,83
Taylor / dual  : 42,44
Il Barton è indifferente alla cosa, mentre è ben visibile il guadagno con il 
Taylor (28% più veloce). A tal proposito, vorrei chiedere alcuni 
chiarimenti.
La prima cosa che vorrei evidenziare è che uno vorrebbe aspettarsi quasi un 
raddoppio della velocità ("quasi" perché non sono due CPU distinte), mentre 
qui si vede poco più di 1/4.
Per la versione single-thread, facendo 44,78 / 58,55 si ha che il Barton è 
più veloce del 23,5%. Facendo il rapporto tra i due clock: 1605 / 2171 si ha 
che il Barton ha il clock superiore del 26%. Considerando i vari aspetti 
superiori nella struttura utilizzata dall'ASUS (RAM più veloce, set di 
istruzioni più ampio e altri aspetti che senz'altro mi sfuggono) non è poco 
un misero +2,5%?
Per concludere, ammetto che paragonare due sistemi usando un programma così 
specifico è restrittivo, ma non nascondo che sono rimasto un po' deluso dal 
paragone della velocità nuda e cruda.
Per tutto il resto, l'ASUS è senz'altro un buon portatile con tante 
potenzialità; non sono ancora riuscito a trovare un programma valido per 
usare il sintonizzatore TV, ma l'ho perfino utilizzato per specchiarmi 
mentre mi radevo! :-)
Cristiano 

 qui si vede poco più di 1/4.
Se vuoi vedere incrementi decenti devi usare il modo piu` adatto per
ottenerli. La programmazione multi-thread soffre di svariati problemi,
ottieni due data set differenti e falli processare da un processo in
modo seriale oppure da 2 processi sui 2 core. L'incremento sara`
indubbiamente superiore.
-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: 
http://vvolonghi.blogspot.com
New Pet: 
http://www.stiq.it

 indubbiamente superiore.
Cosa sono i due data set? Puoi spiegarti meglio (anche indicandomi un link)?
Cristiano 

 mentre mi radevo! :-)
finalmente un aspetto positivo dei diamond splendor magic glossy ultra 
glare.
Naturalmente col rasoio elettrico... purtroppo schiuma e lametta e' 
incompatibile con la keyboard. 

 incompatibile con la keyboard.
Sě, sě; con quello elettrico.
Cristiano 

 Cosa sono i due data set? Puoi spiegarti meglio (anche indicandomi un link)?
Scusa, due data set sono due insiemi di dati. Non ho letto il codice
sorgente del tuo applicativo perche` mi prenderebbe parecchio tempo
esplorarlo ma il modo migliore per ottenere prestazioni superiori da 2
CPU e` di usare 2 processi e non 2 thread (spiegare le motivazioni e`
parecchio complesso e lungo. Il problema chiaramente non sta nel
processore ma nel software sovrastante). Nel caso di continua
creazione/distruzione dei thread (o processi) allora invece dei thread
veri e propri sono da preferire i green threads (o micro threads o nano
threads o nomi analoghi) perche` utilizzano molto meno stack e non
necessitano di tutto il tempo necessario a un context switch (ad esempio
il linguaggio di programmazione erlang e` fortemente basato sui green
threads senza memoria condivisa [infatti in erlang i thread si chiamano
processi] ed e` il miglior esempio di programmazione concorrente
nell'informatica moderna, il linguaggio e` stato creato da Ericcsson per
testare le centraline di telecomunicazioni sotto carichi elevatissimi,
per dare un'idea erlang e` in grado di creare/distruggere processi al
ritmo di 150 mila al secondo laddove java, sullo stesso hardware, non fa
piu` di 11.000 thread al secondo.) L'argomento e` spinoso comunque e
molto complesso.



no! ^^ e' una mia personalissima summa delle tecnologie di punta .. o forse 
delle genialate di marketing di acer asus hp e company....
io preferirei sapere il numero di colori effettivo che tali lcd producono, e 
sapere di quanto sono percentualmente inferiori ad un LCD.
Cioe' scriverei " il nostro LCD diamond splendor magic glossy ultra glare 
wide offre un tempo di risposta che e' solo il triplo del peggior crt in 
commercio nel 2002 e ha una ricchezza cromatica pari al 78% di un crt14 del 
1994....
genio del marketing no? 

Valentino Volonghi aka Dialtone wrote:

E non so quanto sia applicabile a WinXP (ambiente nel quale, purtroppo, 
programmo).
Modificare il programma per usare i processi invece dei thread, così a 
mente, mi sembra che sia cosa semplice, ma non ho mai sentito parlare dei 
green threads e credo che in ambiente winzozz non esistano. Sono, però, in 
parte simulabili perché all'atto della creazione di un thread è possibile 
specificare la grandezza dello stack (non so, invece, cosa fare per il 
context switch), ma, sinceramente, non so quanto la creazione di uno stack 
più piccolo possa influire sul tempo totale d'esecuzione.
Cristiano 

 piů piccolo possa influire sul tempo totale d'esecuzione.
Chiaro che con 2 thread questo diventa un non problema :). Comunque i
green threads non sono semplicemente thread con lo stack piccolo, e`
proprio questione di poter sospendere l'esecuzione di uno di essi,
salvare il tutto nello heap e riprendere da un altro. Non e` immediato
implementarli ma ci sono librerie in giro che lo fanno per te.


 versione originale da singolo thread a dual-thread
Dove trovo sta versione ??
Volevo vedere le differenze tra il mio Desktop ed il nuovo portatile
DualCore...
CIAO

 più piccolo possa influire sul tempo totale d'esecuzione.
Infatti penso che non sia il tuo caso. Da quanto ho capito tu hai 
comunque due thread che viaggiano paralleli dall'inizio fino alla fine 
del calcolo, quindi non hai creazioni/distruzioni durante l'esecuzione 
del codice, quindi non trarresti giovamento dai green threads.
Piuttosto mi chedo se i due thread lavorano davvero separati oppure 
hanno accesso a locazioni di memoria comuni o ci sono comunque delle 
sincronizzazioni. Inoltre è molto importante sapere in che linguaggio è 
scritto il tuo applicativo.

 DualCore...
Allora posso inviarti per email la versione dual-thread con l'equivalente 
versione single-thread. Fammi sapere.
Cristiano 

 applicativo.
C++ (VC++ 2005 Express Edition).
Cristiano 

 genio del marketing no?
Come no! Ti licenzierebbero in tronco! :-)
Ma i numeri che riporti sono reali o sono una tua ipotesi?
Cristiano 

 C++ (VC++ 2005 Express Edition).
Uhm, da quello che hai scritto mi sembra tutto piuttosto in ordine, mi 
sembrano comunque strani i risultati che hai ottenuto troppo a vantaggio 
del barton (e dovrei esserne contento, visto che ho un 2500+ :D ), 
soprattutto nella versione dual-thread.
Da qualche parte dovrei avere un mio progetto che usavo in passato per 
stressare ram e cpu: calcolava di continuo filtri all-pass e comb e ti 
indicava la banda passante... sarebbe interessante provare a vedere cosa 
succede in ambito multithreaded... Mi hai messo la pulce nell'orecchio!

 nell'orecchio!
Bene! :-) Appena hai i risultati, facci sapere!
Io, nel frattempo, stavo scorrendo tutti i vari programmi e programmini che 
ho scritto per trovarne un altro da convertire per il dual-core, ma non ho 
trovato niente d'interessante.
Cristiano 

 Bene! :-) Appena hai i risultati, facci sapere!
Ehmm... ce l'avessi un dual core!
Cmq il programmino l'ho trovato, ma penso che avrebbe bisogno di una 
riscrittura di buona parte del codice per essere utilizzabile con due 
thread...

 Una soluzione alternativa e` far partire 2 volte il tuo programma :).
In effetti, nel caso specifico del programma che ho usato per la prova, è 
senz'altro meglio farlo partire 2 volte perché sto vedendo che la velocità 
di esecuzione è proprio raddoppiata o, per meglio dire, nello stesso tempo 
riesco a testare il doppio dei dati.
Non pensavo che l'utilizzo dei thread fosse tanto inefficiente da fare tutta 
questa differenza tra due thread e due istanze d'esecuzione separate.
Cristiano 

 questa differenza tra due thread e due istanze d'esecuzione separate.
Ebbene si :). Le magie della programmazione concorrente :P. A grandi
linee a meno di averne assoluta necessita` non bisogna usare piu` thread
ma preferire o un approcio asincrono (basato su un reactor pattern o
sulle callback o sulle continuations o sulle co-routine) oppure
preferire un approcio multi-processo (oppure combinati asincrono e
multi-processo).
L'approcio multi-thread punisce parecchio e per la programmazione
scientifica di puro calcolo non conosco nessuno che lo utilizzi (CERN,
Lawrence Livermore e organizzazioni simili).
Il multi-threading e` un po` uno schifo detto in soldoni, pero`
apparentemente e` il modo piu` facile per ottenere parallelismo (anche
se in realta` e` facile dimostrare che e` il modo peggiore e piu`
difficile per farlo, solo che l'apparenza inganna).
La sfortuna degli altri metodi per ottenerlo e` che essi non sono
semplici e non fanno nulla per sembrarlo, sono effettivamente un po`
piu` difficili da capire e da applicare ma portano ad incrementi di
prestazioni notevolissimi.
Tu che usi C++ potresti trarre giovamento dall'utilizzo di ACE che di
boost::asio che implementano per te la parte asincrona basata su reactor
pattern, il resto dovrai fartelo da te pero`. Comunque per il tuo
software in particolare conviene davvero eseguire tanti processi quanti
core hai (e` anche meglio per la localita` della cache e della RAM in
architetture NUMA come quella dei K8).
Se vuoi due o tre link da cui partire per studiare il problema:
http://www.computer.org/portal/site/computer/menuitem.5d61c1d591162e4b0e
f1bd108bcd45f3/index.jsp?&pName=computer_level1_article&TheCat=1005&path
=computer/homepage/0506&file=cover.xml&xsl=article.xsl
http://www.defmacro.org/ramblings/concurrency.html
E specialmente bello se hai 80$ da investire in un libro epocale:
Concepts, Techniques, and Models of Computer Programming
Peter Van Roy and Seif Haridi
The MIT Press
Ci sono poi anche altri testi ma sinceramente e` inutile leggerli se
prima non si e` letto questo (purtroppo Van Roy e` un po` sbrodolante
pero` il libro e` davvero fenomenale).
