Newsgroup: it.comp.hardware.cpu
Titolo: Domande su Dual CPU con DURON !

Ho letto in rete della possibilità di "sbloccare" gli Athlon Xp e farli
diventare "MP"
www.hardwarezone.com/articles/articles.hwz?cid=2&aid=393&page=1
Ora mi chiedo però.....
1) poniamo che abbia "fortuna" e riesca a trovare due DURON che vanno
insieme... nel caso di applicazioni che non sfruttano la seconda CPU... il
sistema operativo come divide il carico di lavoro ??? (cioè ok.. non lo
divide ma.. ) mi interessa sapere se io avvio ad esempio un processo di
codifica in Divx con un programma che NON supporta la seconda CPU ok ? in
tal caso avrò CPU1 al 100% e CPU2 allo 0% ...
SE poi AVVIO un gioco o un programma che anch'esso non supporta la doppia
CPU ?
avrò sempre CPU1 al 100% e CPU2 allo 0% oppure
la codifica in divx sarà svolta dalla cpu1 e la cpu2 si occuperà dei calcoli
necessari per il gioco ???? ( quindi in tal caso avrò CPU1 al 100% e CPU2 al
100% )
Se così fosse... ci penserei davvero poco prima di fare una ricerca del
genere :-)
(P.S. ciò vale per qualsiasi programma che non supporta il biprocessore ?)
--
Saluti da MultiTaskinG
||| 
www.quattrotempi.net
 |||
AAAAAAAAAAA Ancient American Association Against Anonymous And Anachronistic
Acronym And Ambivalent Ambiguity

 100% )
Se hai usi un OS che supporta SMP (NT, 2000, XP Pro o Linux) penso che sia
la seconda che hai detto.
Max

 la seconda che hai detto.
 perfetto.. se qualcun'altro me lo conferma mi metto in caccia di duron...
magari di quelli a 0.13 :-)))



Prima di tutto per utilizzare due o più cpu è necessario avere un OS
che supporti le configurazioni biprocesore come ad esempio Win2000,
XP Professional o Linux.
Oltre a questo per beneficiare di un sistema del genere è necessario
anche utilizzare degli applicativi che siano programmati per sfruttare
il multithreading, altrimenti il carico elaborativo non verrebbe
bilanciato nelle due cpu.
Quindi almeno una delle applicazioni che utilizzi in modalità multitasking
deve supportare il multithreading se vuoi avere un beneficio data
da una soluzione del genere (certo l'ideale sarebbe utilizzare solamente
applicativi sfruttanti questa ultima soluzione se vuoi avere il max
beneficio teorico con un pc del genere).
Ciao.

  Ne esistono altri ? :-) non lo sapevo  ! :-))
si, per esempio OS/2, i vari BSD e penso anche BeOS.
Max

 beneficio teorico con un pc del genere).
Forse mi sbaglio, ma penso che un'applicazione che sia multithreading e'
necessaria se vuoi che entrambe le CPU vengano impegnate da una sola
applicazione, per esempio per un rendering. Se, come diceva lui, per esempio
lancia un programma di codifica e poi lancia un altro programma, l'OS
dovrebbe dividere il carico (1 applicazione per CPU) in modo trasparente.
Se sparo c@##ate fatemelo pure saper :) .
Max

 si, per esempio OS/2, i vari BSD e penso anche BeOS.
intendevo dire che non riconosco i vari win9X (e ME) come sistemi operativi
! :-)



Esatto. BeOS, tra l'altro, e' il piu' "multithreading oriented" tra gli
OS home.
-- 
Qui e' Jack Burton, del Pork-Chop Express,
che parla a chiunque sia in ascolto...


Sta tranquillo che se non utilizzi nessuna applicazione sfruttante il
multithreading adottare un sistema a due vie non ti porterà praticamente
alcun benefici rispetto ad una cpu singola di analoga potenza.
Ciao.


OpenBSD gira sui sistemi multiprocessore ma non è SMP
Ciao, Andrea
-- 
          (o_  |
(o_  (o_  //\  | Andrea Carosi, just another Linux user ( #210218 )
(/)_ (/)_ V_/_ | 
GnuPG PK fingerprint: 0857 1927 150B 3C8E 8274  F641 1388 AA6D 3FA0 5410

 alcun benefici rispetto ad una cpu singola di analoga potenza.
Guarda,  lo  scheduler  di  linux  e`  in  grado  di  piazzare  processi
indipendenti  su  CPU diverse  senza  alcun  problema. Un thread  e`  un
"lightweight process", un processo leggero. Non  ho la piu` pallida idea
di come funga lo scheduler di Win2K ma penso proprio che sia in grado di
farlo. In  particolare, con  l'uso di  processi pesanti  (come nel  caso
dell'OP) il miglioramento e` visibile.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Se il  destino di un uomo  e` annegare, anneghera` anche  in un bicchier
d'acqua.
Proverbio yddish


Non conoscendo bene il kernel di Linux senz'altro avrai ragione.
Ma conosco persone che hanno fatto dei test su sistemi sia a
singolo che biprocessore con applicazioni non progettate per
funzionare in multiprocessing, anche in multitasking in ambiente
Win2000, e mi hanno confermato che il miglioramento nel caso
del sistema a due vie era tale da non rendere vantaggioso  il passaggio
ad un sistema del genere (vedi elevato costo).
Ciao.

 ad un sistema del genere 
Il miglioramento nella singola applicazione non e` (ovviamente) visibile
se  questa  non   e`  progettata  per  funzionare   su  sistemi  SMP. Il
miglioramento globale (kernel threads + tutte le applicazioni) e` invece
apprezzabile. In ogni momento avrai  *simultaneamente* in esecuzione due
processi invece di uno.
ciao
Kronos
-- 
Home: 
http://kronoz.cjb.net
Runtime error 6D at f000:a12f : user incompetente


Ok, ma questo miglioramento derivato dall'esecuzione contemporanea
di più applcativi non scritti per sfruttare il multiprocessing è tale
da poter preferire un costoso sistema a due vie (MB apposita più due
cpu) oppure il gioco non vale la candela; no perchè se il beneficio
globale è nell'ordine dell' 8/9% contro un valore teorico del 60/70%
con applicativi scritti ad hoc allora è più vantaggioso magari acquistare
una cpu singola più potente e rimanere quindi su un sistema più economico ad
una via (considerando magari l'utilizzo in media di due
o tre applicativi di media complessità).
Ciao.

cpu) oppure il gioco non vale la candela;
dipende da quanto sia quantificabile questo costo... se si parla di
soluzioni stile dual duron (o dual celeron mendocino, tempo fa), direi
sia appetitoso  - se si parla di un dual xeon4 decisamente no... :-)
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

del sistema a due vie era tale da non rendere vantaggioso  il passaggio
certo, se usi *una* applicazione per volta...

 ha scritto nel messaggio
news:slrnab70rk.n...@localhost.localdomain...

No no, avevano utilizzato fino a quattro applicazioni in contemporanea,
naturalmente non programmate per sfruttare un ambiente multiprocessing.
Ciao.

Lorenz wrote:
 > No no, avevano utilizzato fino a quattro applicazioni in contemporanea,
 > naturalmente non programmate per sfruttare un ambiente multiprocessing.
Se le applicazioni sono cpu bound (sono "limitate" dalla capacita
di calcolo della cpu) passando ad un multiprocessore si hanno
benefici visibili, ma se sono I/O bound ("limitate" dall'accesso
a periferiche) oppure memory bound ("limitate" dalla velocita
di accesso alla memoria), l'incremento di prestazioni e' ridotto.
Inoltre, per alzare le prestazioni, oltre ad "aggiungere cpu" bisogna
anche pensare al resto (es: aumentando la potenza di calcolo
dove prima a strozzare le prestazione era la cpu potrebbe succedere
che il limite diventi l'accesso alla memoria, ecc. ecc.).
L. Micheletto

naturalmente non programmate per sfruttare un ambiente multiprocessing.
chissa' che schifo che fa win2000 allora.... esperienza personale
sotto linux: dual xeon, un particolare programma ci metteva diciamo 6
ore. ne ho fatti andare due insieme (con dati diversi e ovviamente
indipendenti dai risultati della prima elaborazione) e ci ha messo piu' o
meno lo stesso tempo.
boh, magari le applicazioni di win2000 dipendevano pesantemente dal disco
(o da qualsiasi altra cosa non raddoppiata) ...