Newsgroup: it.comp.os.dibattiti
Titolo: BeOS su dual?

Salve a tutti, ho visto che c'e' un folto thread di discussione su BeOS,
meno male...
Mi domandavo se qualcuno avesse verificato le possibilita' di questo
pervasive multi-thread (com'e' possibile utilizzare in multi-thread del
codice scritto per un thread solo??? E gli hazards???) su piu' processori
paralleli. Boh!
Vedo che piu' di qualcuno possiede il BeOS, per curiosita', a costo di
essere un po' OT, ma dove si puo' trovare in Italia, visto che un articolo
ne parlava come se costasse 90.000, ma l'unico rivenditore che ho trovato
sul sito di Be Europe lo vende al doppio (piu' o meno...).
Ciao ciao!
Rony Cesana
ces...@cli.di.unipi.it
http://www.cli.di.unipi.it/~cesana
---___---___---___---
misero su un'officina:
lui truccava le moto, 
lei le pettinava.
	Stefano Benni.

 processori paralleli. Boh!
L'esempio piu' semplice e' quello relativo alla gestione di una
finestra. Su BeOS per aprire una finestra bisogna instaziare un oggetto
della classe BWindow (tipicamente di una sua sottoclasse). Il
costruttore della classe BWindow crea automaticamente una thread per
gestire gli eventi e le attivita' legate alla finestra. Quindi una
applicazione con una sola finestra ha due thread: quella
dell'applicazione e quella della finestra. In piu', al momento in cui
viene creata la finestra viene anche aperta una connessione con
l'appServer, il processo responsabile della gestione dell'interfaccia.
L'appServer tra le varie operazioni che svolge nell'inizializzare la
connessione crea una nuova thread. Riassumendo, al termine dell'apertura
della finestra le thread allocate automaticamente sono due: una nel
processo della tua applicazione, una nell'appServer.
Se questo e' o meno utile, e' stato oggetto di discussione tempo
addietro proprio in questo gruppo. Posso solo osservare una cosa: il
tempo medio di latenza di un processso e' inferiore, soprattutto se hai
piu' di un processori a disposizione. In poche parole, il BeOS non ti fa
raggiungere velocita' di punta maggiori (e come potrebbe?) ma ti
permetterebbe uno sfruttamento migliore delle risorse di calcolo. Il
sistema dovrebbe reagire bene a carichi elevati sulle macchine con due
processori. Il condizionale l'ho dovuto mettere perche' e' solo quanto
ho letto in alcuni commenti. Io devo fare ancora delle prove. A breve
dovrei prendermi una macchina biprocessore appositamente per il BeOS. Vi
faro' sapere.
Scusa la domanda, ma non conosco il termine hazards. Cosa vuol dire?
--
Fabrizio Di Giuseppe
Real email address: fabrizio@_REMOVEME_iride.com
http://www.iride.com/fabrizio
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 sul sito di Be Europe lo vende al doppio (piu' o meno...).
Lo vendono al doppio perche' costa il doppio.
-- 
-=* Biffuz *=- alias Gabriele Biffi
bif...@mail.com
        |  "L'intelligenza e' una gran bella cosa.
http://come.to/biffuz
  |  Sarebbe bello se tutti ne avessero una."
ICQ 5169491 (Biffuz)   |
--
Posted from [212.75.198.2]
via Mailgate.ORG Server - 
http://www.mailgate.org

=-->> Mi domandavo se qualcuno avesse verificato le possibilita' di questo
=-->> pervasive multi-thread (com'e' possibile utilizzare in multi-thread
=-->> del codice scritto per un thread solo??? E gli hazards???) su piu'
=-->> processori paralleli. Boh!
=-->L'esempio piu' semplice e' quello relativo alla gestione di una
=-->finestra. Su BeOS per aprire una finestra bisogna instaziare un oggetto
=-->della classe BWindow (tipicamente di una sua sottoclasse). Il
=-->costruttore della classe BWindow crea automaticamente una thread per
=-->gestire gli eventi e le attivita' legate alla finestra. Quindi una
=-->applicazione con una sola finestra ha due thread: quella
=-->dell'applicazione e quella della finestra. In piu', al momento in cui
=-->viene creata la finestra viene anche aperta una connessione con
=-->l'appServer, il processo responsabile della gestione dell'interfaccia.
=-->L'appServer tra le varie operazioni che svolge nell'inizializzare la
=-->connessione crea una nuova thread. Riassumendo, al termine dell'apertura
=-->della finestra le thread allocate automaticamente sono due: una nel
=-->processo della tua applicazione, una nell'appServer.
=-->[...]
Rispondo brevemente sugli hazards: e' un termine che ho usato a
sproposito, giusto per capirci... e non ci siamo capiti, fa niente :-)   
In realta' si parla di hazards quando si considerano i rischi di eseguire 
un'istruzione macchina su registri che devono essere ancora aggiornati da
operazioni precedenti secondo la logica del codice in esecuzione nel
processore. Mi pare, ma ricordo vagamente, che se ne parli in funzione  
dell'opportunita' o meno di introdurre il delayed branching, o il   
loop-unrolling... (ottimizzazioni hardware o dell'assemblatore). Ribadisco
che non ricordo esattamente, quindi potrei, as usual, aver detto una
c*zz*ta.
Quello cui mi riferivo io, invece, ha a che fare con l'accesso condiviso 
alle risorse che possono fare thread diversi, e che, tipicamente, va
regolamentato dal programmatore che si organizza i suoi bei threads... se,
effettivamente, la macchina virtuale di BeOS spezzettasse in thread
diversi del codice che e' stato pensato per un thread unico si creerebbero
notevoli problemi, vista l'indeterminatezza dell'ordine di scheduling dei 
thread.
Quello che invece succede sotto BeOS, stando a quello che mi dici tu, e'
ottimo ma ben diverso: si tratta di come sono concepite le librerie
grafiche (per intenderci, come e' implementato il costruttore della classe
di cui parlavi, BWindow, suppongo...), ma non c'e' alcun preprocessamento
di codice.
In sintesi: cio' che e' single-threaded, resta single-threaded. 
Cio' di cui non si conosce l'implementazione (per la logica, che adoro,
dei linguaggi ad oggetti) e', in questo caso, realizzato in multithread.
Cordiali salumi a tutti.
	Rony Cesana
P.S.
1) fammi sapere di BeOS su due processori :-)
2) dove l'hai comperato BeOS?
3) ma i thread sono maschili o femminili?
4) perche' ho messo 4 punti sul post scriptum?

 ma non c'e' alcun preprocessamento di codice.
No, infatti. E' il cuore del sistema che e' stato concepito per
sfruttare meglio le architetture multiprocessore. Il BeOS, al
contrario di altri sistemi operativi, e' stato pensato fin dall'inizio
per funzionare su piu' processori. Ma come ti ho detto l'incremento di
prestazioni e' generale e non riguarda l'esecuzione di un singolo
processo. Le prestazioni di punta rimangono le stesse. L'alternativa
sarebbe parallelizzare il codice, ma anche cosi' non e' detto che i
risultati siano sensibilmente migliori rispetto ad una macchina
monoprocessore. Un esempio sono alcuni test comparativi tra una G4 ed un
dual PIII. Il G4, anche se legermente meno prestante, teneva testa al
PIII ed in alcuni casi dava dei risultati migliori.
Mi chiedo solo se sia piu' valido considerare un media OS un sistema
pensato per sfruttare piu' processori od uno piu' prestante nello
sfruttare le ottimizzazioni del processore, come ad esempio le
estenzioni MMX e SIMD.


 estenzioni MMX e SIMD.
 
Io credo che un buon MediaOS dovrebbe cercare di ottenere tutte e due
queste cose sacrificando l'implementazione di altri aspetti. Tipo, magari
vivere di "rendita" per quanto riguardi l'NFS ed implementare solo gli
aspetti piu' importanti della sicurezza e dei protocolli di rete.
Non so se hai mai visto girare lo ZSnes. 
E' un emulatore di Super Nintendo scritto in Assembly per Ms.Dos.
con alcune parti "di struttura" scritte in C. Gira tra l'altro anche sotto
Windows95, e bene, senza dare problemi.
Il bello di questo emulatore e' che per alcune cose cerca di sfruttare al
meglio l'architettura sottostante del processore. Quindi se hai una CPU
che ha le estensioni MMX, esso puo' usare le istruzioni MMX (con una
notevole velocizzazione) per il sonoro. Non solo, gia' su di un P133
riesce ad emulare completamente un SuperNintendo liscio (ovvero senza
giochi che sfruttano processori aggiuntivi che si trovano in alcune
cartuccie speciali) senza calo di velocita' (anche se la qualita' del
sonoro deve essere portata a 8khz) ed attivando la maggioranza degli
effetti grafici (scanlines ed interpolazione).
Ora, un programma come lo ZSnes e' l'esempio di come un sistema operativo,
secondo me, dovrebbe cercare di sfruttare il sistema sottostante. Se il
sistema si creasse in modo sufficentemente modulare imho non ci sarebbe
alcun problema per la portabilita'. Crei la struttura collante in C o C++,
mentre i driver li puoi quindi implementare o in C, per portarli su
diverse architetture immediatamente, oppure anche in ASM per poter
sfruttare efficacemente l'architettura sottostante come fa lo ZSnes.
Ci pensate a vedere un sistema Alpha sul quale gira un sistema di questo
tipo? 
Cmq ripeto che un sistema cosi' sarebbe buono per il multimedia e per i
videogiochi...
Ciao.
--
 |\   /|  Davide "Gatto Feroce" Inglima
 | --- |  Scrittore, Studente, Traduttore.
_- | | -_ "Mana is rapidly disappearing from the world, even the"
_-  *  -_ "mana tree has begun to wither..." Seiken Densetsu 3.
 -_ - _-  Fan dei GDR alla giapponese? Fan di Chrono Trigger?
   ---    vieni su 
http://web.tiscalinet.it/chronoita