Newsgroup: it.comp.hardware.cpu
Titolo: Sistemi bi-processore

Ciao al NG! Si sta male a casa eh :(?
Vengo al sodo: i sistemi bi-processore, so che vengono utilizzati da win2000
e schede bi-processo (ovviamente), ma quando?
Se si utilizza un software "generico" (cioè non scritto x bi-proc.) in
piattaforme bi-proc., le prestazioni sono identiche o no?
E se invece si utilizzano PIU' programmi contemporaneamente (anche non
scritti per bi-proc.) sempre su un sistema bi-processore le prestazioni
cambiano o no?
In poche parole Win2000 è in grado di dividere il compito di + applicazioni
tra i 2 processori?
Thanx, C-I-A-O

tra i 2 processori?
e' il suo lavoro, se a redmond non sono idioti lo fa :-) (*)
(*) il che fa venire qualche dubbio sui programmatori di w9x e
famiglia, ma questo e' un altro discorso... {evil grin}
--
    (iao!!oai)                                    (ICQ: 10860566)
    //.aurizio
[WARNING!: a breve _PURE_ 
mmug...@galactica.it
 verra' disabilitato (...), usate il nuovo indirizzo...+
[WARNING!: togliete _nessuno_ per rispondere]
    Time may change me
    But I can't trace time

 ovvio che il guadagno e' comunque molto limitato.
Non e' detto, in alcuni casi "patologici" (es: un task molto "pesante"
che viene passato da una cpu all'altra trashando completamente le cache
ogni volta) le prestazioni possono pure essere inferiori.
In generale comunque le prestazioni sono superiori "se lo si usa
davvero come un sistema multiprocessore" (piu classi di task in esecuzione
con piu task nella stessa classe in modo da "spremere" per bene le cpu
ed evitare i casi patologici).
Con un numero sufficiente di task in esecuzione le prestazioni
sono circa 1.8 volte quelle di un sistema monoprocessore e si nota
che il sistema "risponde meglio".
Se si "regola a mano" l'assegnazione delle cpu ai vari task
si possono ottenere prestazioni ancora piu vicine a 2 volte le prestazioni
di un sistema monoprocessore, o persino *superiori*.
Per esempio usando le estensioni RTAI per il kernel Linux
e' possibile assegnare in modo "fisso" i task alle cpu
in questo modo un task che fa solo filtraggio numerico e che sta
"tutto nelle cache" puo raggiungere prestazioni *stellari*
(visto che si puo ottimizzarlo per bene e con la certezza
 che la cache ed i TLB non vengono toccati da altri task).
L. Micheletto

 ed evitare i casi patologici).
Sotto che condizioni si possono verificare tali casi patologici scusa? e per
di più, su un periodo di funzionamento di un server ( oddio macchina
biprocessore.. non ci gioco a "lego racers"....) leggasi quasi sempre on...
che incidenza percentuale può avere questo caso patologico...?
la ritengo un osservazione del tutto irrilevante, anche se fondamentalmente
corretta...ma mi paiono tanto parole al vento.. no ?


E' sufficientemente rilevante.
Pensa ad esempio al caso di DUE task "pesanti" che si scambiano reciprocamente
le cpu di un biprocessore piu e piu volte a causa di interruzioni causate 
da task "leggeri", ti ritrovi con un costoso sistema multiprocessore che va 
anche piu lento  di un uniprocessore e non riesci ad identificare il problema
(raramente la gente "pensa in parallelo").
Quando ad esempio devi realizzare applicazioni soft-realtime
(quelle hard-realtime e' meglio lasciarle a S.O. specializzati
 in questo) un "crollo" del 50% delle prestazioni che avviene
casualmente una o due volte al mese potrebbe costarti molto caro
visto che il superamento dei margini di tempo potrebbe causare
malfunzionamenti a cascata difficili da diagnosticare
(non si tratta di guasti hardware e neppure di bug dovute all'applicazione
 ma si tratta invece di una interazione tra task e S.O. che di per se non
 produce errori).
Come ho scritto nel posting precedente, una soluzione "semplice" esiste
ma non tutti la applicano preventivamente (anche perche in media comporta
prestazioni inferiori alla soluzione con n task "pesanti" in un sistema 
ad n cpu "con un buon scheduler"), un altro metodo invece consiste
nel "legare" un certo task "pesante" ad una cpu del sistema multiprocessor
in modo da eliminare alla radice il problema, ma questo di solito si
fa con applicazioni hard-realtime.
Per un utilizzatore "medio" non e' un vero problema (al massimo avra' sprecato
soldi se gli capita troppo spesso la combinazione "patologica"), ma e' bene
saperlo, specialmente per non buttare soldi in sostituzioni di componenti
o in espansioni varie quando simili anomalie diventano evidenti.
L. Micheletto

 o in espansioni varie quando simili anomalie diventano evidenti.
Non credi che sarebbe sufficiente assegnare ai vari task priorità adeguate
in modo che i processi piccoli non rompano troppo le palle al grosso CPU
Bound?
e poi, seisicuro che gli scheduler moderni non tenganogia di loro contodi
queste cose, mi sembra facile da eliminare come problema.
basterebbe distribuire i carichi ai processori in modo che i task CPU bound
non vengano switchati su un altro processore no, oppure rendere questo
possibile solose nonci sono proprio altri processi pronti, insomma nonmi
sembra na cosa cosìassurda... non trovi ?

 queste cose, mi sembra facile da eliminare come problema.
Hai detto bene, sembra.
Il problema non sta tanto nei task in se, ma nella gerarchia di memoria
(e' il trashing delle cache e dei TLB che va evitato).
Per esempio, un task cpu bound che loopa tantissimo in un set di dati ridotto
e' molto diverso da un task cpu bound che "spazzola" la memoria
facendo affidamento sul prefetching e sui dati gia sulle cache.
Il primo si puo passare da una cpu all'altra senza problemi, l'altro
invece ha una grossa penalizzazione, ma sono entrambi cpu bound.
Non e' un caso se ci sono cosi tanti tool per misurare le prestazioni
e per bilanciare il carico e le priorita (sono cose che uno scheduler 
non deve fare, il suo lavoro non e' misurare le prestazioni).
Comunque, come ho detto piu volte, quello che avevo descritto era un caso
*patologico* "tra task", che di solito si risolve "a mano", non una cosa
cosi frequente da giustificare riscritture degli scheduler (non lo hanno
fatto neppure per il problema di priority inversion che per poco mandava
in malora la missione del Mars Rover, figurati per questo).
Semmai vengono fatti "ritocchi" per ridurre la frequenza di queste
situazioni, ma sono ritocchi ad hoc che cambiano al variare della
tecnologia (es: quando non c'erano cache cosi ampie il problema
dello "scambio" tra cpu era insignificante).
L. Micheletto

 dello "scambio" tra cpu era insignificante).
ok grazie della spiegazione