Newsgroup: it.comp.os.dibattiti
Titolo: Domande su BeOS

Dunque, avrei da porre qualche domande su BeOS ai felici utilizzatori che
sembrano popolare il NG.
1.Esistono emulatori sotto BeOS, tipo Dosemu o Wine?
2.I programmi che servono a sfruttarlo proficuamente, tipo mail e
newsreader, suite applicative (StarOffice, M$ Office,...) e altri, si
trovano gia' sul CD di installazione del OS oppure devo raccattare i pezzi
qua e la'?
3.Esistono software per Internet di un certo livello: un mail composer tipo
Eudora(con filtri, mailbox e possibilita' di gestione di account diversi) o
un newsreader tipo Agent?
4.Come vengono gestite le installazioni dei programmi? in modo intelligente
tipo RPM o in modo idiota tipo il Winsozzo?
5.Qual'e' lo spazio su disco occupato da un'installazione tipica?
6.A che frequenza escono le release e che differenze ci sono una
dall'altra? tali da giustificare la spesa per un upgrade?
7.Com'e' il meccanismo dei driver per le periferiche, tipo Linux o tipo W95?
8.Come viene effettuata la gestione dei processi? multitasking spero, di
che tipo?
Ringrazio chiunque avra' la pazienza di rispondermi.
							Garba
--
Posted from 
mbox.ULIsse.it
 [194.91.24.2]
via Mailgate.ORG Server - 
http://www.mailgate.org


nada
"...libera e felice come una farfalla..."

Flag (
fl...@lo.itline.it
) wrote:
[ snip ]
: multitasking,multithreading,MP,RT,etcetc
MP = MultiProcessor ?
RT = Real Time ?
: alla Be per descrivere il kernel hanno coniato l'espressione
: "pervasive multithreading"....da l'idea....=)
Coniata dal Marketing, visto che non significa nulla ;)
: pensa ad una cosa che puo' essere caricato quanto vuoi ma rimane
: sempre pronta a rispondere all'utente e non scattare mai(piuttosto si
: rallenta ma mai uno switch da un workspace all'altro con la sorpresa
: che tutti i gadget sono ancora da ridisegnare!!!!)
Mi ricorda il QNX-scheduler-patch: era (e' ?) una patch per lo
scheduler di linux che lo modificava secondo questo algoritmo:
1) l'applicazione in primo piano aveva tutta la CPU che gli serviva;
2) se rimaneva qualcosa, veniva distribuito tra le applicazioni in 
   background.
Il risultato (non lo ho mai provato, purtroppo) dovrebbe essere simile
a quello da te descritto, piu' o meno...
Ciao ciao
Andrea
-- 
"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and 
 the Ugly)."
(by Matt Welsh)

 No, BeOS non e' real time.
Ciao,
          Antonio

...
: >: alla Be per descrivere il kernel hanno coniato l'espressione
: >: "pervasive multithreading"....da l'idea....=)
: >
: >Coniata dal Marketing, visto che non significa nulla ;)
: Beh, il fatto che tu non capisca che significa non vuol dire che non
: significhi niente...
No no...e' proprio che non ha alcun significato ;)
: >Mi ricorda il QNX-scheduler-patch: era (e' ?) una patch per lo
: >scheduler di linux che lo modificava secondo questo algoritmo:
: >1) l'applicazione in primo piano aveva tutta la CPU che gli serviva;
: >2) se rimaneva qualcosa, veniva distribuito tra le applicazioni in
: >   background.
: >Il risultato (non lo ho mai provato, purtroppo) dovrebbe essere simile
: >a quello da te descritto, piu' o meno...
: No, ti sbagli.
: Il BeOS ha questa capacità poichè non esiste applicazione costituita da un
: solo processo. Ogni applicazione è un thread, in cui esiste sempre un
: processo dedicato alla gestione dell'input. Tipicamente ogni applicazione è
: un thread costituito da minimo una decina di processi "leggeri". Questo
: significa che anche nel caso il sistema sia sovraccarico, in un tempo
: ragionevolissimo anche il processo di gestione dell'input o del ridisegno
: dell'interfaccia acquista il controllo e quindi tutto il sistema ha
: un'altissima responsività.
In che modo ? A me sembra che tu stia dicendo che alcuni thread 
(specificatamente quelli dedicati all'I/O) sono privilegiati rispetto
agli altri...questo da' l'impressione di responsivita'.
Buon Anno


 agli altri...questo da' l'impressione di responsivita'.
Non è un'inpressione, è così.
Il processo che gestisce l'input di un'applicazione (l'applicazione è un
thread, detto Team sotto BeOS), ha tipicamente una priorità più elevata
rispetto all'applicazione.
Questo inplica che se l'utente interagisce con il computer il processo
di input reagisce immediatamente.
E' un po' come con AmigaOS, solo che con AmigaOS esiste un unico
processo che gestisce l'input (di default almeno). Questo processo ha
priorità 20 (da -127 a 128, il default è 0), una elevata priorità
quindi: se l'utente interagisce con la macchina il processo che gesisce
l'input reagisce immediatamente e manda degli specifici messaggi agli
altri processi, oppure si occupa direttamente dell'evento, ad esempio
ridisegnando un gadget che è stato premuto.
Ciao,
Fabio Alemagna
Ciao,
Fabio Alemagna

 No, BeOS non e' real time.
Beh, BeOS dispone di uno scheduler real-time (cioè se la priorità di
un processo è più alta di un certo limite, gli altri processi prendono
il controllo della CPU solo quando questo va in attesa di una
risorsa), quindi credo lo si possa definire un SO real-time.
Uso il condizionale solo perché un po' di tempo fa ho letto un thread
bello corposo che parlava della giusta definizione di SO real-time, ma
purtroppo non mi ricordo quali erano state le conclusioni (sempre che
ce ne siano state ;)
Ciao,
-- 
d i e g o
--
Per le repliche elimina dal mio indirizzo le cifre e le croci

 risorsa), quindi credo lo si possa definire un SO real-time.
Mah, secondo questo principio, anche Linux lo dovrebbe essere, per cui dubito
fortemente che sia tutto qui.
man 2 sched_setscheduler
-- 
  Da visitare: uno dei piu` grandi archivi di software free
http://www.metalab.unc.edu/pub/Linux/!INDEX.html

 risorsa), quindi credo lo si possa definire un SO real-time.
Non esistono Dead-line, non esistono vincoli espressi in termini
temporali, non lo si puo' quindi definire un S.O. real-time.
Le priorita' nello scheduler sono una delle cose piu' comuni che tu possa
trovare (persino in Win95)
Ciao,
           Antonio

un'altissima responsività.
Ti stai confondendo ancora. Quello che tu dici non centra nulla con l'essere
multithreading. Quello dipende dalla gestione dello scheduler (tema
ampiamente trattato sia qui, che nelle fonti formali n.d.p.). All'inizio i
thread *non esistevano*, e i sistemi Unix erano *reattivi* e permettevano
addirttura di applicare tariffe a consumo CPU (cosa impossibile se un
applicazione user poteva piantere il sistema).
Un PLC Siemens di alta gamma, con quella specie di S.O. che ha, gestisce
tranquillamente macchine da 5,000 sigarette al minuto. Un controllo assi
della General Elettric ha le capacita' computazionali per potere gestire lo
stesso sistema. Il primo e' un S.O. vecchia scuola, nemmeno multitask
(niente memoria virtuale n.d.p.), il secondo e' RTOS multitask e multithread
con tutte le carte in regola. Qualcosa di piu' reattivo di un RTOS non credo
ci sia.
Multitask =/= reattivo (anche se molte relazioni ci sono).
NetWare 3.1x e' un ottimo e veloce file server proprio perche' non ha
complicazioni belle architetturalmente, ma che costano tempo CPU.
+++
--- (Elimina il papero per le repliche) ---

 complicazioni belle architetturalmente, ma che costano tempo CPU.
Non costano tempo CPU... Questo con il BeOS non lo puoi proprio dire...
;)
Ciao,
Fabio Alemagna

man 2 sched_setscheduler
Purtroppo non ho questa man page sulla mia distribuzione, ma da quel
che ho visto lo scheduler di Linux non ha questa caratteristica. 
Ad esempio, lancia un player mp3 o midi, e prova a dargli la massima
priorità: se ora carichi la macchina oltre ad un certo limite,
sentirai la musica a "scatti"; questo significa che il processo con la
priorità più alta deve comunque cedere la CPU agli altri processi ogni
tanto.



Se parli solo di priorità sono d'accordo, ma le priorità real-time
non si trovano in tutti i SO; ad esempio in Linux non ci sono.


 non si trovano in tutti i SO; ad esempio in Linux non ci sono.
Leva il termine real-time quando parli di BeOS o di Linux (a meno che tu non
usi RTLinux, ma a quel punto il kernel e' un altro ed il kernel Linux gira
come un task periodico a priorita' minima).
 Quelle che tu consideri "priorita' real-time", almeno a giudicare da un
altro tuo post in questo thread, nella multiprogrammazione sono considerate
un errore e di quelli gravi.
Nessuno scheduler a code di priorita' (come ad esempio quello di Linux o
quello di BeOS) permette una cosa del genere.
Neppure BeOS, ma da come e' fatto il sistema non te ne accorgi
 Ciao,
           Antonio

Neppure BeOS, ma da come e' fatto il sistema non te ne accorgi
Su questo però sono portato a chiederti un'ulteriore spiegazione: il
termine "priorità real-time" non me lo sono inventato, ma è la maniera
in cui viene chiamata la classe di priorità maggiore in molti SO
moderni (come ad esempio Solaris, WinNT, e BeOS appunto).
Il comportamento dei processi che hanno questo tipo di priorità è
proprio quello che ho indicato nell'altro post (almeno nel BeOS).  Ad
esempio io ho fatto questa prova: ho lanciato prima un gioco con la
massima priorità e poi uno script con priorità normale: in Linux il
gioco ha cominciato a scattare ma lo script veniva eseguito quasi alla
stessa velocità di sempre, mentre in BeOS il gioco andava normalmente
ma lo script era praticamente sempre fermo.


Sostanzialmente per usare un S.O. real-time bisogna usare le sue API.
Esiste uno standard POSIX.4 che ha cercato di standardizzarle senza riuscirvi.
In ogni caso per i S.O. hard real time bisogna far ricorso alle API
proprietarie che differiscono da sistema a sistema.
Quella che viene definita priorita' real-time nei S.O. da te citati e'
accademicamente parlando un abuso di notazione.
In fin dei conti confonde le idee e basta.
Per quanto riguarda l'esempio da te fatto trovo la seguente spiegazionie il
gioco sotto faceva ricorso ai servizi di un processo con priorita' eguale a
quella dello script.
A proposito, per ottenere la massima priorita' hai usato nice come super user
(nice -n -20 gioco) oppure l'hai settata (sempre come super user) dal programma
attraverso la primitiva sched_setscheduler(..)?
Ciao,
               Antonio.

Questo con il BeOS non lo puoi proprio dire...
Non lo visto. Non ci metterei la mano sul fuoco che sia *nettamente* meglio.
Sopratutto se l'archituttura e' la solita, ma con i nomi cambiati (team,
bagigi, PippoThread, PippoPlug ..)
--- (Salva il papero per le repliche) ---

 bagigi, PippoThread, PippoPlug ..)
Provare per credere...
Ciao, Fabio Alemagna

 che ho visto lo scheduler di Linux non ha questa caratteristica.
Boh? Mi pareva di si. Ti riporto un pezo della manpage. Mi sembra 
sia quel che hai detto, no? 
Onestamente non ho guardato i sorgenti dello scheduler. Mi riprometto di 
farlo, una volta o l'altra. :-)
Ribadisco, cmq, che dubito fortemente che questo DA SOLO ne faccia
un sistema real-time (e in effetti, da quel che leggo due post piu`
in la, la cosa sembra essere questa).
...
SCHED_OTHER is the default universal  time-sharing  sched­
uler   policy  used  by  most  processes,  SCHED_FIFO  and  
SCHED_RR are intended for special  time-critical  applica­
tions  that  need  precise  control  over the way in which
runnable processes are selected for  execution.  Processes
scheduled  with  SCHED_OTHER  must  be assigned the static
priority  0,  processes  scheduled  under  SCHED_FIFO   or
SCHED_RR  can have a static priority in the range 1 to 99.
Only processes with superuser privileges can get a  static
priority  higher  than  0  and  can therefore be scheduled
under   SCHED_FIFO   or   SCHED_RR.
...
SCHED_FIFO: First In-First out scheduling
SCHED_FIFO can only be used with static priorities  higher
than  0,  that  means  that  when  a  SCHED_FIFO processes
becomes runnable, it will always preempt  immediately  any
currently  running  normal SCHED_OTHER process.
Si intende che politiche diverse da SCHED_OTHER possono 
essere usate solo da root.
-- 
  Da visitare: linux Weekly News - settimanale su Linux
http://www.lwn.net

 500MHz... Provare per credere...
E di perdere caratteri dalla seriale a piu' di 9600. There is no such
thing as a free lunch.
Saluti
Lele

 thing as a free lunch.
vabbuò, grazie, la seriale su amiga non ha buffer, e quello è pur sempre
solo un 68000 a 7Mhz...
Che razza di paragone...
Già solo con un 68020 a 14 Mhz puoi usare la seriale a 38K in
multitasking senza problemi
(ricordo che un 68020 a 14 Mhz sviluppa circa 2Mips...).
Ciao,
Fabio Alemagna

 (ricordo che un 68020 a 14 Mhz sviluppa circa 2Mips...).
Con le prestazioni del sistema che calano a picco.
Se la cpu fa una cosa non ne fa un'altra. Ti sembrera' strano ma il
multitasking funziona cosi. Puoi fare un sistema reattivissimo in cui la
cpu passa il 90% del suo tempo ad aspettare gli eventi dalla console e a
ridisegnare i widget, solo per poi avere prestazioni da circo sul
networking, sulla gestione dei dischi, o su chissa' cosa. Fino ad oggi i
miracoli non li ho ancora visti. E sulla linea del BeOS anche se non ho
avuto il tempo di seguire tutto il discorso concordo in pieno con il
sig. Quack.
Saluti
Lele

fale...@studenti.unina.it
 wrote:
 >una scelta simile permette ad un'Amiga 500 con un 68000 a 7Mhz di essere
 >più reattivo di un winbug od anche un linux su uno strapentium a
 >500MHz... Provare per credere...
Certo, le finestre sono piu` reattive, ma in altri casi a che serve?
Non fara` andare piu` veloce ne` il raytracer ne` il server web.
E nulla vieta di scrivere applicazioni cosi` anche per X, la Xlib e`
rientrante.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | > Mettete 
maxa...@tin.it
 nel vostro killfile (Pub. progresso) <

 sig. Quack.
Le vostre sono teorie... mettetele alla prova, e vi convincerete che
sbagliate.
Ciao,
Fabio Alemagna

 cooperative...
Ma se qualcuno non "sveglia" lo scheduler, sara` pur lo scheduler che si deve
svegliare da solo, o tenersi sempre sveglio, no?
-- 
  Da visitare: la homepage del progetto GNOME
http://www.gnome.org

 svegliare da solo, o tenersi sempre sveglio, no?
E' questo il punto! in un OS multitasking preemptive i processi, o
tasks, o threads, o comunque tutto quello che deve essere eseguito,
vengono eseguiti secondo questa modalità:
1)la cosa fondamentale è che devono essere "svegli".
2)Poi, se è il loro turno, vengono eseguiti per un certo intervallo di
tempo, dopo di che si passa al successivo.
3)Se lo scheduler, nel momento in cui passa da un processo ad un altro,
si accorge che un processo a più alta priorità di quello che stava per
eseguire si "sveglia", allora esegue questo.
Tutto, poi, ricomincia dal punto 1).
In linea di massima le cose vanno così, a parte qualche variante.
Il punto fondamentale è che il processo, per essere eseguito, deve
essere sveglio.
Il processo si mette a "dormire" quando è in attesa di qualche evento.
Da quel momento in poi, lo scheduler non lo terrà neanche più in
considerazione, non occuperà tempo macchina.
Il "risveglio" può venire effettuato *solo* in due modi:
1) Un altro processo invia un segnale o un messaggio al processo
"dormiente" e lo risveglia.
2) Viene generato un interrupt hardware da parte dell'utente (come ad
esempio usando mouse o tastiera), oppure da parte dello stesso HW del
computer, all'interrupt è associato un handler che "sveglia" il
processo.
Questa architettura non spreca tempo CPU, anzi!!
Ciao,
Fabio Alemagna

 Questa architettura non spreca tempo CPU, anzi!!
Non tieni conto dell'overhead del cambio di contesto, allora. E del fatto che,
in misura minore, tale overhead c'e` anche per il cambio di thread all'interno
di un processo.  
Thread va bene se devo aspettare una periferica particolarmente lenta. Ma se il
beneficio che ne ricavo e` inferiore all'overhead dello scheduler o dei
meccanismi di sincronizzazione tra thread (e` gia`, i thread devono pur
cooperare tra loro per far qualcosa, no?), al diavolo i thread. Come li uso, li
butto anche. Se poi ho a disposizione una macchina con piu` di una CPU, ben
vengano i thread, se mi consentono di distribuire il carico con maggiore
granularita`.


 sbagliate.
E' piu' o meno quello che faccio da 20 anni. E' curioso che tu mi sta
dando dell'incompetente anche nel discorso che riguarda la crittografia,
subito dopo avere dimostrato le tue ampie conoscenze sul campo.
Saluti
Lele

 granularita`.
Devi chiarirtii le idee, le hai molto confuse...
Ciao,
Fabio Alemagna

 subito dopo avere dimostrato le tue ampie conoscenze sul campo.
Tu, evidentemente, da 20 anni, metti alla prova vecchie teorie su
vecchie architetture, e spari sentenze su cose che neanche conosci. Hai
provato il BeOS? No? E allora come fai a giudicarlo? Come fai a sapere,
a priori, che le cose come le fa lui non sono fatte bene? Ti sei chiesto
come mai il BeOS ha raggiunto quota 1.000.000 di utilizzatori (ed il
numero è in continua crescita)?
Ti sei chiesto come mai il QNX, che pure gestisce le cose attraverso
threads (ogni device driver è un processo e ogni filesytem anche), è
capace di gestire una seriale a 115200 baud su un semplice 386 in
multitasking e senza perdita di caratteri? E come mai venga usato sugli
shuttle come OS dei computer di bordo (già, perchè se la tua soluzione è
la migliore non viene utilizzata in un campo dove solo le cose migliori
vengono accettate?)? 
Ciao,
Fabio Alemagna


ma da quando?!?!?!!?!??
cmq per la seriale usa 8n1.device...
"...libera e felice come una farfalla..."


Infatti, me ne sono convinto anch'io.
+++
Sono riuscito finalmente a trovare quella manpage (era su un pacchetto
che non avevo installato); invece non sono riuscito a trovare nessuna
utility a riga di comando tipo nice che facesse uso di
sched_setscheduler, ne qualche utility tipo ps per visualizzare i
settaggi correnti: esistono da qualche parte, o devo farmele da me?


 vengono accettate?)?
Perche la soluzione migliore di un problema non e' automaticamente
nemmeno una risposta valida in un altro.
Saluti
Lele

 Devi chiarirtii le idee, le hai molto confuse...
A me non sembra proprio.
Saluti
Lele

 Suggeriscici una metodologia di prova oggettiva.
Quale metotologia è migliore di un analisi comparativa su macchine di
uguali prestazioni fisiche (teoriche)? Fai dei benchmarks...
Ciao,
Fabio Alemagna

 nemmeno una risposta valida in un altro.
Quale altro?
Fai un esempio, dove secondo te, il QNX non è adatto?
Sono pronto a controbattere...
Ciao,
Fabio Alemagna

 sono cambiate da allora...
Ho un 4000/40 funzionante e rlativamente in ordine, che purtroppo posso
usare solo raramente. Ma sono convinto che le cose non siano poi
cambiate cosi tanto. Le CPU, certo sono piu' potenti, per cui i problemi
di cui parlo sono infimi rispetto alle prestazioni del sistema. Ma
quando hai tempo e voglia, prova a giocare un po' con il debugger
integrato dello UAE, giusto per vedere che cosa fa il SO di Amiga per
far passare il tempo alla CPU. Soprattutto quando la CPU di tempo ne ha
pochino.
Saluti
Lele

 uguali prestazioni fisiche (teoriche)? Fai dei benchmarks...
Bene, vediamo un benchmark che dimostra che il BeOS e' piu performante
di (supponiamo) OpenBSD. Da che parte cominci?? Cosa misuri? Hai dei
numeri? Puoi escludere figure indesiderate dovute a ragioni che non
riguardano la gestione dei processi? (se il driver video e' scritto
meglio, la cosa non riguarda di sicuro lo scheduler).
Posso anche prendermi mezza giornata per fare le misure, aspetto solo
che tu mi dica quali e come.
Saluti.
Lele.

 Sono pronto a controbattere...
Tralasciando il fatto che non sai leggere, sullo z80 dell'antifurto di
casa mia non gira.
Saluti
Lele

 LAVORO, comunque rigiri la frittata.
 Guarda che stai facendo un errore di fondo, stai presupponendo che BeOs sia nato
per girare SOLO su macchine monoprocessore, mentre in realta' BeOs gira ANCHE su
macchine monoprocessore.
BeOs e' stato concepito per girare sopratutto su macchine multiprocessore (il
BeBox era un dual power pc), ragion per cui la tua obiezione cade.
Inoltre ricordo che nel cambio di contesto di un thread e' necessario cambiare
solo il processore virtuale e non tutta la macchina virtuale con conseguente
minimizzazione dei tempi necessari al suddetto cambio (i thread usano infatti un
modello a memoria comune a differenza dei classici processi pesanti).
Ciao,
           Antonio.

 modello a memoria comune a differenza dei classici processi pesanti).
E' vero ma non c'entra niente. Forse non ci siamo capiti, o non sono
capace di spegarmi io, o chissa cosa.
faccio un esempio, magari le cose migliorano.
Se devi fare un programma che calcola un immagine bidimensionale
dell'insieme di Mandelbrot e poi lo visualizza, l'approccio semplice
potrebbe essere quello di calcolare i valori dei punti della matrice,
dopodiche' chiamare la routine di visualizzazione per generare
l'immagine a video.
Ora una bella pensata potrebbe essere quella di creare due thread, uno
che calcola i valori per la matrice, e uno che, periodicamente,
svegliato dall'altro quando ci sono sufficienti dati, aggiorna la
visualizzazione.
Che differenza c'e' tra i due approcci? Nel primo caso l'eventuale
utilizzatore non vedrebbe assolutamente nulla finche il programma non e'
quasi terminato e inizia la visualizzazione. Nel secondo, pochi istanti
dopo l'inizio della esecuzione vedrebbe comparire una parte del disegno
che si completa man mano che l'elaborazione procede.
Il secondo caso e' certamente piu' "responsivo", se dovessi scrivere un
sistema orientato alla visualizzazione, certamente farei cosi, ma per
quanto tu possa rigirare le cose, non sarai mai in grado di scrivere una
implementazione del secondo metodo che sia piu' efficiente della
migliore implementazione del primo. (Sto dicendo delle cose che non sono
ovvie? Perche'??) Nel migliore dei casi i due potrebbero avere tempi di
esecuzione esattamente uguali, in un caso realistico, nel secondo
esempio, al tempo necessario per effettuare le elaborazioni, dovresti
aggiungere i tempi necessari per cambiare contesto, sincronizzare i due
thread, arbitrare gli accessi alle risorse condivise.
Questi tempi aggiuntivi diventano sempre piu' rilevati quanto piu'
frequentemente e' realizzato il cambio di contesto (anche questo mi
sembra abbastanza ovvio... non lo e'??) a prescindere da quanto impiega
il cambio di contesto stesso (se il tempo impiegato in un c.s. e' minore
l'andamento crescente della curva sara' meno marcato, ma salvo che il
cambio di contesto avvenga in un tempo negativo o nullo...) 
Se prendi come riferimento una unita' di tempo, nell'esempio due, la
quota del tempo di elaborazione dedicata a gestire i cambi di contesto
diventera' sempre maggiore a spese di quella utilizzata per fare il
"lavoro utile".
In un sistema multiprocessore? Chiaramente l'approccio due distribuisce
il lavoro tra due CPU, quindi il nostro programma risultera'
incrementato di prestazioni. Ma l'incremento non e' gratuito. E'
avvenuto a spese degli eventuali altri processi che in quel momento non
possono girare sulla seconda CPU. E a spese di qualcuno andranno i
soliti lavori di arbitraggio, sincronizzazione, ecc..
Sto dicendo un eresia (mi si passi la banalizzazione) se dico che una
sola CPU e' piu' efficiente che due CPU di "potenza" dimezzata? 
Saluti
Lele

 sola CPU e' piu' efficiente che due CPU di "potenza" dimezzata?
 Dipende....
Certamente un sistema a batch (come quelli che trovavi a giro 20 anni fa) e' piu'
performante di un sistema multitasking.
Ma nessuno al giorno d'oggi usa un sistema a batch perche' non vuole sacrificare la
reattivita' del sistema alla performance in modo cosi' drastico quindi...
Di sicuro se non usassi un sistema organizzato in piu' processi o thread non
sfrutterei le CPU aggiuntive.
In un solo caso si verifica quanto da te sopra affermato, quando il programma e' fatto
male, insomma chi ha scritto l'applicativo dovrebbe andare a zappare anziche'
programmare.
Ciao,
             Antonio



 programmare.
La necessita' di usare CPU aggiuntive deriva dal fatto che e' un sistema
facile per aumentare le prestazioni, con un minore aumento di costi
rispetto ad una singola CPU di potenza doppia. Ma non vuole dire che 
Ma se tu hai in mano una procedura di X istruzioni che viene eseguita su
una cpu in N microsecondi, voglio vederti riuscire ad eseguirla in
esattamente N/2 microsecondi su 2 CPU, N/4 su 4, N/8 su otto, e cosi
via. 
Saluti
Lele

ddain...@x52dsi.unive.it
 wrote:
 >Sono riuscito finalmente a trovare quella manpage (era su un pacchetto
 >che non avevo installato); invece non sono riuscito a trovare nessuna
 >utility a riga di comando tipo nice che facesse uso di
 >sched_setscheduler, ne qualche utility tipo ps per visualizzare i
"nice -20 programma" dovrebbe bastare.
 >settaggi correnti: esistono da qualche parte, o devo farmele da me?
Usa top(1) o ps(1) con i parametri appropriati.


 sola CPU e' piu' efficiente che due CPU di "potenza" dimezzata?
Faccio un esempio:
Un sistema monotasking č piů efficiente di uno che non lo č. Passa tutto
il tempo ad eseguire un solo programma... Cosa? Ho sbagliato? Ma va..
Forse che un sistema monotasking č *meno* efficiente di uno multitasking
perchč magari il programma passa la maggior parte del suo tempo ad
aspettare che l'utente prema un tal pulsante? Sě, mi sa che č cosě...
Tu, praticamente, vorresti un sistema Multitasking, che passasse tutto
il suo tempo a far girare un solo programma, o al massimo 2, perchč
cosě  c'č meno task switching... Mah... Non hai le idee molto chiare per
me...
Ti rammento solo una cosa: Il QNX su un P133 ha un tempo di context
switch di soli 1,8 microsecondi (tra processi, non tra threads). Ti
riporto i dati del QNX perchč solo quelli i ricordo ora.
Ciao,
Fabio Alemagna

> sbagliate.
Le *nostre* sono considerazioni di fatto. Alle -mie- consideraioni che mi
rifiuto di credere che hanno fatto una simile fesseria su BeOs, non mi puoi
rispondere che Amiga e' una figata. Rispetto la tua opinione, ma cosa
centra?
Sono i programmatori che sanno se devono usare o meno il multithreading. il
multitasking o il multipippo. Il S.O. non deve rompere le @##@. Mi spieghi a
cosa servirebbe l'architettura BeOS (se fosse realmente cosi') ad un demone
(terminologia Unix) o a un servizio (terminologia NT)? 
Te lo dico io. Ad eavere un inutile overhead. In questo momento girano 32
processi e 180 thread sul mio NTW. Ho solo 7 programmi con un interfaccia
attiva. Se BeOS avesse implementato una simile corbelleria avrebbe 25 fermi
in piu'. 
Non e' vero che un thread che dorme non consuma tempo CPU. Non lo consuma
nel suo contesto. Lo scheduler deve decidere se e' il caso di svegliarlo o
no, o credi che glie lo dica il mago Zurli'?
+++
Possono avere fatto una cosa simile, e la cosa risultare una cosa
intelligente. Per ora mi sfugge il motivo dell'intelligenza della scelta (se
l'hanno fatta).
--- (Salva il papero per le repliche) ---

 A cosa servirebbero quei famigerati dieci thread?
A sfruttare bene quattro processori che lavorano in parallelo... hai
capito? Il BeOS e' stato realizzato con in mente delle macchine
multiprocessore. Aggiungo: anche con un processore, i dieci thread
servono a sfruttare meglio la risorsa tempo. Ma e' ovvio che il buono
sfruttamento di questa risorsa dipende anche da una buona progettazione
del software. Quante thread dovranno essere instanziate per svolgere un
determinato compito? Nella struttura del framework di programmazione del
BeOS c'e' una risposta: se un processo svolge n attivita' differenti
servono n thread. La classe BLooper serve ad utilizzare efficientemente
le thread (il nome dovrebbe essere sufficientemente esplicativo). Ad
ogni istanza di un BLooper corrisponde una thread. I BLooper rispondono
a messaggi. Ad ogni messaggio corrisponde una operazione (il BLooper
puo' anche restare costantemente in attivita'). Come vedi, cosi' usate
le thread sono anche uno strumento adatto a concretizzare uno stile
modulare di programmazione. Per quel che riguarda l'influenza negativa
che l'alto numero di thread potrebbe avere sulle prestazioni generali
del sistema, posso far notare che non e' detto che le thread siano tutte
attive contemporaneamente. Anzi, nella maggior parte dei casi solo
alcune di queste saranno attive, ovvero quelle il cui BLooper non ha
ancora terminato l'azione associata all'ultimo messaggio ricevuto.
Considera anche che il context switch di una thread non e' molto
pesante. Il risultato e' che tutte le attivita', essendo associate a
thread differenti, hanno la possibilita' se necessario di essere riprese
quanto prima senza attendere che vengano completate attivita' che
occupano la stessa thread. Da qui' la reattivita' dell'interfaccia di
una applicazione per BeOS, che da quello che ho avuto modo di vedere non
ha eguali in altri sistemi attualmente in circolazione (escluso
AmigaOS), e l'efficienza del sistema operativo. In particolare, con
macchine multiprocessore, all'aumentare del carico, il BeOS mantiene un
buon livello di efficienza.
Ciao.
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio

 prendere :-(. Rimani tra quelli che scrivono solo post costruttivi.
Sono rientrato nei ranghi appena passata la febbre. Sorry per l'episodio
momentaneo.
Saluti
Lele

 me...
forbid();
Per carita`, nessuna crociata contro il multitasking e i thread. 
Pero` capisci benissimo che raggiunto un certo limite, i benefici non ci sono
piu` se non puoi distribuire il carico su piu` CPU, altrimenti hai solo
applicativi che passano il tempo a cercare di lockare mutex per tenersi
sincronizzati tra loro, visto che ci sono cose che devono PER FORZA essere
serializzate. Lockare un mutex richiede tempo, per poco che sia, e se lo devi
fare un milione di volte in tempi brevi, l'overhead diventa sensibile.
Ovviamente, un applicativo con N thread che si contendono un mutex a raffica non
e` scritto bene, e questo e` chiaro. Pero` vedo sul sito del BeOS che esso e` un
OS in cui si viene invogliati a scrivere thread a raffica, il che, quantomeno,
mi fa nascere qualche sospetto.
Perfettamente concorde che, con una GUI, e` meglio avere un thread che si occupa
della GUI e una manciata di altri che fanno il lavoro "sporco", ma permettimi di
avere dubbi che un ambiente "pervasivamente threadizzato" su macchine con una
sola CPU ci guadagnino in prestazioni assolute. Semmai, avrai una GUI reattiva,
ma spero che non giudichi le prestazioni solo dalla reattivita` del ridisegno
dei bottoni.
Il fatto e` che e` dannatamente facile per uno che si mette a sviluppare a
thread cominciare a dividere il problema in maniera eccessiva (semplifica la
vita), in modo da avere invarianti poco complicate da tenere a bada. Se poi e`
l'architettura dell'OS stesso che invoglia, questa "degenerazione" si traduce in
programmi bellissimi dal punto di vista concettuale, magari ben manutenibili,
con GUI reattive, ma delle vere chiaviche in fatto di prestazioni assolute
rispetto a programmi con meno thread ed altrettanto manutenibili.
In parole povere: pochi thread ben pensati per ogni processo per me vanno bene.
Tanti, no. Spero di essermi espresso in maniera chiara, stavolta.
permit();
-- 
  Da visitare: la Linux Gazette:
http://www.linuxgazette.com

 dei bottoni.
Ma nemmeno con due, quatto o otto CPU. Ad un certo punto, anche con N
cpu il problema e' il medesimo. Terminate le risorse libere bisogna
suddividere quelle disponibili.
E poi non credo che il caso di una macchina con 8 CPU e un solo task
"dominante" sia il caso tipico.
Saluti
Lele

 l'hanno fatta).
Gli imbecilli nonpossono pretendere di capire le cose intelligenti.
Ciao,
Fabio Alemagna

 buon livello di efficienza.
Capito gente? Prima di sparare sentenze, documentatevi...
Ciao,
Fabio Alemagna

 buon livello di efficienza.
Quest'ultima affermazione e' un po' delicata. Intanto andrebbe
conforatata da qualche specifica in piu': quali sono i criteri di
misura? C'e' qualche numero a disposizione? Confrontato con cosa? Per
che tipo di applicazione?
Saluti
Lele

dell'AS400, e dei mainframe in genere.
Cosa vuoi sapere su cio' ? (anche in privata sede...)
Obelix


Ma top e ps visualizzano solo il valore di nice, non le priorita'
statiche e le "policy" dello scheduler (ho riletto anche le man page
ma non ho trovato nulla a riguardo).


 usare le priorita' statiche da' garanzie maggiori).
Macchina lenta un P100?? Ma fai sul serio? Se per linux e- lento un
P100, mha... non so...
Ciao,
Fabio Alemagna

matteoi...@poboxes.com
 wrote:
 >In parole povere: pochi thread ben pensati per ogni processo per me vanno bene.
 >Tanti, no. Spero di essermi espresso in maniera chiara, stavolta.
Amen.


ddain...@x49dsi.unive.it
 wrote:
 >>"nice -20 programma" dovrebbe bastare.
 >Dipende, se la macchina e' lenta (un pentium 100) e si vuole far
 >andare programmi come cdrecord, nice potrebbe non bastare (e comunque
 >usare le priorita' statiche da' garanzie maggiori).
Se non basta quello allora non esiste altro.
 >> >settaggi correnti: esistono da qualche parte, o devo farmele da me?
 >>Usa top(1) o ps(1) con i parametri appropriati.
 >Ma top e ps visualizzano solo il valore di nice, non le priorita'
 >statiche e le "policy" dello scheduler (ho riletto anche le man page
  PID  UID PRI  NI  SIZE  RSS SHARE WCHAN     STAT %CPU %MEM COMMAND
 4180    0  17   0   788  788   612           R     2.4  2.5 top
PRI e` appunto la priorita`. Le policy credo che vengano indicate da un
flag in STAT ma non ne sono sicuro.


switch di soli 1,8 microsecondi 
Tempi medi, tempi minimi, o tempi massimi?
Mi sembrano poi un po' troppo bassi.
Avevo letto che QNX garantisce tempi di latenza di 2 millisecondi. Possibile
che ha tempi simili con CS non riesca ad andare piu' in basso?
Ma magari confondo i ricordi.


caso in memoria ci siano 1000 processi, attivi o inattivi che siano...
TU quella lista non la scorri mai? In questo caso 1000 o 10 non fa
differenza. 
Mi devi spiegare la magia dell'algoritmo e della tua struttura
architetturale che ti permette di avere una lista di 1000 oggetti, di avere
accesso a tutti i 1000 oggetti, e di non avere mai bisogno di scorrerla per
qualche motivo. Nel mondo reale naturalmente
Forse nei S.O. da laboratorio e' possibile. Stessa priorita', e quanto di
tempo fissi. Roba da laboratorio appunto.
Perfino il piu' gnocco S.O. alza la priorita' (o aumenta il quanto di tempo)
di un thread precendemetne addormentato. E se il processo e' alla fine della
lista?
E' contento lo stesso. Tanto avere una lista da 1000 o da 10 e' la stessa
cosa.


 Mi sembrano poi un po' troppo bassi.
Tempi massimi.
Ciao,
Fabio Alemagna

 flag in STAT ma non ne sono sicuro.
Su questo le man page di top e ps vanno in contraddizione: quella di top
dice che effettivamente PRI e' la priorita', mentre quella di ps sostiene
che e' tutt'altra roba. Vedendo che top ritorna valori di PRI fuori
dal range 0-31, sono portato a pensare che PRI non sia la priorita' del
task (lo standard posix prevede 32 livelli di priorita', da 0 a 31).
		Ciao,
			Luca


Sbaglio o tu sei molto in vena di polemiche?
Secondo te un pentium 100 e' una una scheggia per compiti come la
masterizzazione? 
Io dico no: ho sentito di gente che sotto win95 con macchine di
questo tipo (se non superiori) doveva disabilitare perfino gli
screen-saver per evitare i buffer-underrun.
Sotto Linux di certo non si arriva a questi estremi, ma usare le
priorita' statiche da comunque una maggiore garanzia.



No, ho fatto una prova e ne PRI ne STAT avevano valori sensati.
In particolare PRI non e' possibile che indichi la priorita' statica
perche' il suo valore per kswapd e' di -12 e quindi non e' compreso
fra 0 e 99.



Stai facendo un esempio sbagliato, dove la multiprogrammazione non puo'
essere applicata.
Supponiamo invece che tu abbia DUE o piu' procedure NON vincolate tra loro.
Usando 2 processori dimezzeresti il tempo di calcolo complessivo.
Ciao,
            Antonio.


L'esempio e' giusto. Sto parlando di N istruzioni che compongono la o le
procedure che preferisci. Le prestazioni di un sistema MP con n
processori non sono _mai_ (trovami un controesempio) n*X ma sempre piu'
o meno inferiori. Puoi attimizzare il tutto, in modo da avviciniarti
sempre di piu' al limite, ma non ci puoi arrivare (a meno di costruire 2
macchine separate, con memoria, dischi e tutte le altre risorse locali
disgiunte, e farci girare sopra delle procedure completamente non
correlate, che non condividano dati e che non debbano essere
sincronizzate tra loro, ma non credo che si riesca a vendere come
esempio elaborazione multiprocessore)
Saluti
Lele

 sempre di piu' al limite, ma non ci puoi arrivare
Su questo non posso che concordare.
L'esempio comunque rimane errato: mi spieghi cosa puoi parallelizzare in una
procedura di N istruzioni?
A meno di non scrivere codice a vanvera le istruzioni sono sequenzialmente
strettamente vincolate tra loro.
In tal caso multiprogrammare significa fare danno.
Ciao,
             Antonio

ha eguali in altri sistemi attualmente in circolazione 
Come dice bene Lele questo puo' essere un punto a sfavore di BeOs. Come
server credo che non userei mai un S.O. che si basa sull'efficacia
dell'interfaccia. Questo vuol dire che BeOS brucia CD da masterizzare che e'
una bellezza perche' si preoccupa troppo di ridisegnare i pulsanti.
Si, lo so che uso NT, ma i servizi (demoni) di NT funzionano senza
interfaccia, e quindi con quell'cicciribau di NT e' *disattivato*.


 In tal caso multiprogrammare significa fare danno.
Se non sbaglio, l'esempio originale (l'ho scritto io, ma ho la memoria
corta) supponeva di dovere calcolare i valori di una matrice
(nell'esempio una immagine dell'insieme di mandelbrot), e poi
visualizzarlo a video. IMHO il problema e' divisibile in almeno 2
thread. Io ho detto semplicemente "una sequanza di istruzioni" che puo'
essere "qualunque sequenza di istruzioni a tuo piacimento", per esempio
una procedura che calcoli i primi 10000 numeri primi e poi il fattoriale
di 46376. Mi sembra un esempio facilmente parallelizzabile. Eppure ti
garantisco che la forma seriale viene eseguita in un tempo che e' minore
della somma dei tempi che impiegano 2 cpu ad eseguire ciascun compito in
una forma parallela. E questo e' un caso *molto favorevole* di processi
concorrenti disgiunti, di quelli che nel mondo reale non capitano quasi
mai. 
Sara' una forma mentis, ma io tendo a vedere i programmi come flussi di
istruzioni (e dati) che vengono macinati dalle CPU. Se il problema
permette (e _preso singolarmente_ beneficia di) una suddivisione in
thread, allora la faccio volentieri. Suddividere un task in thread,
assumendo che eventuali altre CPU siano li ad aspettare i tuoi comodi e'
un lusso che ti puoi pemettere solo su una macchina molto specializzata,
particamente monoutente, in cui ci sia solo un grosso ed impegnativo
task da far girare ogni volta. Nel caso generale, la macchina avra' gia
di suo diverse cose da far giostrare tra le varie CPU.
Saluti
Lele

 esempio elaborazione multiprocessore)
Mi sembra sbagliato partire dal presupposto che N istruzioni vengano
eseguite sempre esattamente ad X microsecondi: ci sono fattori di
ottimizzazione della CPU che non rendono valida questa idea.
Poi un sistema MP ha l'indubbio vantaggio che non solo i processori ma
anche le cache di questi funzionano in parallelo diminuendo così gli
accessi in memoria in caso si due o più processi diversi.
Tempo fa vidi dei test di decodifica di chiavi RC5 su sistemi
multiprocessore e mi ricordo che 4 PowerPC 604e collegati in parallelo
diventavano quasi 8 volte più veloci di un singlo PowerPC!
Su Pentium Pro invece i risultati erano molto più deludenti proprio a
causa della diverse tecniche di ottimizzazione...
Il test dovrebbe stare ancora da qualche parte
su 
http://infopad.eecs.berkeley.edu/CIC/
Ciao,
Giamby
--
--
 Giambattista Bloisi - Amiga & pOS *Giamby* software developer
      Coordinatore giornale studentesco di ScuolaItalia
                 e-mail: 
gia...@geocities.com

Pensavo che ti riferissi ad una procedura generica e non a quella
all'origine del thread.
Perdona l'ingenuita'.
Ciao,
            Antonio

 interfaccia, e quindi con quell'cicciribau di NT e' *disattivato*.
cicciribau? Ma come scrivi? Macchimminchia vu riri, ca un si capisci? ;)
Forse vuoi dire che tutto continua a funzionare anche se l'interfaccia
viene giu? Anch'io ho qualche daemon installato. Ho gia' provato la
piacevole esperienza di vedere cadere l'interfaccia e sapere che tutto
dietro continua a funzionare tranquillamente. Peccato che non me ne
faccio niente di una WORKSTATION con l'interfaccia piantata. Spero che i
signorini abbiano aggiunto nella R4 qualche servizio per riavviare
all'occorrenza l'interfaccia.
Ciao.
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio/

fabr...@iride.com
 wrote:
 >Se mi spieghi come pensi sia fatta la cache, forse posso capire il
 >perche' della tua opinione... ah, ma forse tu raggioni con le fork di
 >Unix, per cui il codice presente sulla cache di un processore va
 >ricopiato sulla cache dell'altro... su BeOS usi la spawn_thread() che
 >richiede un puntatore a funzione. Quindi, non e' certo che si verifichi
 >il problema delle fork... sempre che sia un problema. Comunque, spiegati
Mi sembra che tu non abbia le idee chiare. Quando un unix moderno fa
fork le pagine rimangono in una sola copia e sono copy on write, cioe`
non vengono copiate se non sono state modificate.
C'e` un cache miss solo se il figlio viene eseguito su un altro
processore, ma questo mi sembra accada anche con la funzione che
descrivi.
Saro` banale, non saro` alla moda, ma continuo a ritenere che certi OS
facciano un uso assolutamente non necessario dei thread.
 >Di palo in frasca. Ti rispondo prima parlando di efficenza: qualcuno mi
 >vuole dire quanto tempo perde un processore ODIERNO (tipo PentiumII 400)
 >a fare un context switch? Forse si perde piu' tempo a swappare pagine su
 >disco (tralaltro, BeOS occupa poco spazio in memoria).
Certo.


 e' chiaro cosa vuole fare la Be.
Infatti e' esatto. La Be con il BeOS ha in mente un certo target
preciso. E le scelte di implementazione del SO riflettono le necessita'
di quel target che e' una cosa sacrosanta. 
E' per quello che sono intervenuto a sindacare quando si diceva che Be
(o AmigaOS o QNX) polverizza qualsiasi altro sistema operativo. Non
metto in dubbio che sia vero, nelle applicazioni per cui e' pensato, che
sono qualcuna delle moltissime per cui e' possibile utilizzare un
computer.
Sitnetizzando al massimo, forse perfino troppo, tutto l'ambaradan che
stiamo scatenando e' solo per dimostrare che un architettura come quella
che mi (ci) descrivete del BeOS, e' adatta IMO ad un ambiente dove pochi
processi, controllati da un utente, devono sfruttare un ambiente
multiprocessore nel migliore dei modi. Ma non e' affatto ovvio che la
stessa architettura performi altrettanto bene in altre situazioni.
Quello che voglio dire _io_, concludendo, e' tutto qui, e mi sembra
strano che qualcuno non l'abbia ancora capito, e mi fa piacere che,
invece, qualcun altro se ne sia reso conto.
Saluti
Lele

 che tipo di applicazione?
Non ho a portata di mano misure precise, ma solo l'impressione di chi ha
avuto l'occasione di provarlo su di una macchina multiprocessore e le
considerazioni che ho prima esposto.


 considerazioni che ho prima esposto.
Io ho avuto occasione di usarlo (su una macchina monoprocessore), e la
mia impressione e' stata quella che ho espresso fin qui. E' un aggeggio
che va benissimo per quello per cui e' stato pensato. E sempre la mia
impressione e' che non si comporterebbe analogamente bene impiegato in
altri campi.
Se ci sono dei numeri a smentirmi, ben vengano.
Saluti
Lele

 descrivi.
Grazie, non lo sapevo.


 timeslice piu ravvicinate.
Infatti, la scelta secondo me ricade piu' tra diversi stili di
programmazione. A mio avviso, la scelta tra diversi tipi di context
switch (tra processi o tra thread) e' ormai poco rilevante
nell'ottimizzazione del sistema.
Vorrei poi fare alcune precisazioni. Non vorrei che si diffonda l'idea
che nel BeOS per ogni applicazione vi siano centinaia di thread inutili
in esecuzione. Le thread sono almeno due (una per l'interfaccia, una per
l'elaborazione), ma generalmente NON sono molte di piu'. Fino ad ora ho
visto solo i processi di sistema con molte thread. Mi pare che siano
Kernel, AppServer, NetServices, ed altri due o tre che non ricordo.
Alcuni di questi hanno poche thread, altri ne hanno una ventina.
Comunque, ad ogni thread e' associato un particolare servizio. Alcuni
sono riconoscibili, altri no. In generale, la maggior parte di queste
thread e' in attesa.
Una cosa interessante e' che, avendo accesso libero a tutte le risorse
della macchina, posso cambiare la priorita' delle singole thread a mio
piacimento. Considerando che ogni singola thread rappresenta un
particolare servizio, posso rendere piu' reattiva la macchina su certe
operazioni piuttosto che su altre. Questo per alcuni amministratori di
server Unix o NT non sara' una novita', ma lo e' per me, che sono
principalmente un utilizzatore di workstation.
Ciao.
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio/

 principalmente un utilizzatore di workstation.
Finche sono cose che decido solo IO... :))
Saluti
Lele

 Finche sono cose che decido solo IO... :))
Parliamo di due cose differenti. La mia macchina la tocco solo io e non
c'e' non c'e' nessun rompiscatole di sorta che possa permettersi di
farlo al posto mio. Non ne ho bisogno per il lavoro che faccio e per
come lo faccio.
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio/

 come lo faccio.
Infatti e' quello che volevo dire.
Ci e' arrivata la R4. Adesso cominciamo a guardarlo seriamente.
Saluti
Lele

masterizzazione? 
Cioe', fornire un flusso di dati a BEN 600k/secondo? cacchio, certo
che e' una scheggia... ovvio, se ci metti w95 ti ci vuole un
dual-PII...
Obelix che masterizza ORA con  un P100...

 priorita' statiche da comunque una maggiore garanzia.
Io constato solo dei fatti: Su Amiga, con un misero 68030@50Mhz, che č
circa una decina di volte piů lento di un P100, si masterizza
tranquillamente....
Ciao,
Fabio Alemagna

Ti dico solo questo perchè non perdo tempo a rispondere alle emrite
cazzate che hai scritto: Tu non sai di che stai parlando. Conosci solo
il tuo «bel» NT e credi che le cose che fa lui sono fatte nel miglior
modo possibile.
Credi come vuoi, qui non si vuole evangelizzare nessuno.
Amen
Fabio Alemagna

 Ci e' arrivata la R4. Adesso cominciamo a guardarlo seriamente.
Smorzando un po' l'astio che forse si è creato tra di noi, volevo solo
dire che in linea di massima sono d'accordo con gli ultimi sviluppi del
thread (ho ancora qualche convinzione mia... ;)), cmq volevo
consigliarti di provare a compilare e a far girare sia su Linux che su
BeOS, quel benchmark multipiattaforma (ora non ricordo come si chiama):
finalmente avremo dei numeri, e alla loro evidenza ognuno di noi dovrà
prostrarsi ;).
Ciao,
Fabio Alemagna

 prostrarsi ;).
E' la prima cosa che volevo fare. Ma non mi contentero' di fare girare
un benchmark tipo SPEC o Linpac, perche non mi sembra molto
rappresentativo di quello che vogliamo misurare. Non ci interessano
tanto le prestazioni della cpu, quando le prestazioni dei sistemi
operativi *nel fare le stesse cose*. Anche se tutto sommato mi sembra
difficile eliminare i bias, comunque ci si puo provare.
Comunque, domani porto via un disco a qualche macchina e installo sulla
stessa macchina Linux, un *BSD e BeOS e vedo di tirare fuori qualche
numero indicativo. Putroppo deludero' i fan del multiprocessore, non
posso fermare delle macchine a regime per fare i miei benchmark.
Saluti
Lele

 Ci e' arrivata la R4. Adesso cominciamo a guardarlo seriamente.
Spero vivamente che arrivi anche a me. E' due mesi che l'aspetto!
-- 
Fabrizio Di Giuseppe
mailto:
fabr...@iride.com
http://www.iride.com/fabrizio/

 principalmente un utilizzatore di workstation.
Un altra vittima di una system administration fascista?  :-)
Cmq, i tuoi post precedenti mi hanno rassicurato parecchio. Mi son lasciato
traviare da quel "pervasive". 
-- 
  Da visitare: linux Weekly News - settimanale su Linux
http://www.lwn.net

 prostrarsi ;).
[DA PRENDERSI MOLTO, MOLTO, MOLTO CON LE PINZE!!!!]
Come esplorazione preliminare ho fatto girare una versione
abbondantemente evirata (non tutto si compila sul Be) del Byte Unix
Bench sia su Linux che sul BeOSr4.
Si tenga conto che il Bytebench e' un benchmark pensato esclusivamente
per *Unix* e piu' orientato a misurare le prestazioni della macchina che
del sistema operativo. Pero' e' l'unico che ho trovato che si compilasse
senza perderci ore anche sotto Be.
Ho ridotto il numero di test che vengono effettuati, eliminando, oltre a
quelli che non giravano proprio, anche tutta la lunga serie di test
orientati alla cpu, che avrebbero misurato poco e niente del sistema
operativo. Ho anche modificato il numero di iterazioni di ogni singolo
test (e' un benchmark dell'88) per avere dei valori compresi tra 10 e 60
sul BeOS (che ho provato per primo)
In sostanza e' un benchmark che non dimostra assolutamente niente anche
se questi sono i risultati che vengono fuori, potrebbero esser viziati
da chissa' quanti milioni di problemi. E' una specie di richiesta di
commenti, io NON ho guardato i sorgenti per vedere cosa fa il bench, NON
ho chiesto lumi al nostro esperto di profiling delle applicazioni, NON
ho valutato se differenze architetturalì possono viziare i risultati del
test che, ripeto, e' scritto PER UNIX. Nel weekend, quando avro' meno da
fare, conto di fare alcune di queste cose, oltre a cercare qualche test
piu significativo. (e di testare il TP di rete!)
La macchina su cui ho fatto i test (che restera' uguale anche in
eventuali altri risultati che dovessi postare) e' configuarata come
segue:
PII/375 (e' un 333 o/c a 75Mhz FSB)
Asus P2B
128Mb
Diamond Viper V550 (nVidia TNT)
Disco IDE Quantum EL 5.2Gb
3c900B
Il disco ha 3 partizioni, due con Linux e una per il Be.
Il Linux e' la nostra disribuzione interna, *vagamente* basata sulla
slackware 3.5, il compilatore e' l'egcs 1.1, il kernel e' il 2.0.36
(compilato con l'egcs con -O6 -mpentiumpro). Libc 5, KDE 1.0 avviato.
Il BeOS e' la R4, con il driver *sperimentale* per la TNT (ma la Be
sostiene che e' sostanzialmente un driver stabile)
I risultati sono espresi come TEMPI, cosi' minore e' migliore. Ho
eseguito ogni test 10 volte, il risultato e' la media dei singoli
tentativi.
					Be		Linux
Integer arithmetic
(1000000 iterations)			11.088		9.710
Floating point 
arithmetic
(1000000 iterations)			10.556		10.070
Dhrystone loop
without register vars
(10000000 iterations)			18.513		14.840
Recursion test:
Tower of Hanoi
(27 disks)				21.240		15.250
System Call Overhead
(1000000 calls)				11.282		7.520
Pipe based context switch
(1000000 iterations)			36.659		12.850
Child process creation 
(1000 processes)			13.324		2.330
Exec throughput
(1000 execs)				15.906		2.160
File System performance
(10 secs)				8288  write	11664 write
					11724 read	11070 read
					7980  copy	5635  copy
Proprio per le premesse di cui sopra mi astengo dal fare commenti ai
numeri, per il momento.
Saluti
Lele

cicciribau? Ma come scrivi?
Cicciribau fa parte del vocabolario del bravo informatico.
Come PippoOS, Visual Pippo, PriProQuack, QuackAssert, "nel mio mondo",
BauBauEIlBugsNonCePiu, "e tu ti fidi dell'uomo delle merendine?", "e poi
venne il mangiatore di ciocori'", "il ruggito del topo" e altre cose.
Sono tutti termini tecnici di uso comune in questo NG.
Adeguati, o perisci :-)
+++
"e poi venne il mangiatore di ciocori'" e' l'unica frase di cui non sono
l'inventore. E' un poco lungo spiegare chi si deve intendere con: "il
mangiatore di ciocori'"
Dico solo che "il mangiatore di ciocori'" e' il terrore di ogni
programmatore senior.


 numeri, per il momento.
Faccio un primo commento che non ho avuto il tempo di completare prima.
E' evidente che questo tipo di test non puo fare altro che misurare la
risposta del sottosistema Posix del BeOS, quindi la creazione di
processi tramite fork(), la quale, vista l'architettura di cui abbiamo
parlato, potrebbe essere particolarmente inefficiente, non essendo il
metodo privilegiato dal sistema.
D'altra parte non ho proprio niente di meglio pronto, se qualcuno avesse
qualcosa di precotto sarebbe il benvenuto.
Saluti
Lele


Cio' non toglie che un pentium 100 non e' certo il massimo per
masterizzare, a meno di non fare altro durante la masterizzazione.
-- 
d i e g o
--
Per le repliche elimina dal mio indirizzo le cifre e le croci

 metodo privilegiato dal sistema.
Infatti, stavo per risponderti dicendoti proprio questo. Bisognerebbe
fare un benchmark che testi gli OS nel fare le *stesse cose* in modo
nativo. Per la creazione dei processi, ad esempio, bisognerebbe usare
delle chiamate native dell' OS, cosě come pure per le altre cose.
Posso provare a contattare un mio amico che programma sotto BeOS e
chiedergli di scrivere un programmino che faccia queste cose.
Prima nettiamoci d'accordo su quello che deve fare perň.
Ciao,
Fabio Alemagna


Ah, ma sotto BeOS che versione di egcs c'č? E quali erano le opzioni di
compilazione?
Ciao,
Fabio Alemagna

 Prima nettiamoci d'accordo su quello che deve fare perň.
Mi sembra un problema discretamente complesso... comunque ci penso su
ancora un po.
Saluti
Lele

 compilazione?
gcc version 2.9-beos-980929 
Ho usato lo stesso Makefile per entrambe le piattaforme. Con un generico
"-O" per l'ottimizzazione del codice.
Saluti
Lele

 qualcosa di precotto sarebbe il benvenuto.
Beh, quantomeno vale un ringraziamento per lo sforzo. :-)
-- 
  Da visitare: la homepage di Linus Torvalds
http://www.cs.helsinki.fi/~torvalds

 Beh, quantomeno vale un ringraziamento per lo sforzo. :-)
Il punto e' che non posso investire una settimana di lavoro nel portare
una suite di benchmark ottimizzata per BeOS. Se qualcuno ha qualche
interesse "mi piacerebbe vedere come si comporta a fare questo o
quello", e mi indica dove trovare un sorgente che si porti con poco
sforzo, e' il benvenuto. Io sto provando lo stack IP, con il quale mi
sento piu' a mio agio, per il momento piu' dal punto di vista
dell'implementazione che delle prestazioni. (ma arrivero' anche a
quello!)
Saluti
Lele


Vabbeh, senza farla tanto lunga, e' evidente che abbiamo una visione
molto diversa di cosa e' o non e' una scheggia
--
d i e g o
--
Per le repliche elimina dal mio indirizzo le cifre e le croci

 molto diversa di cosa e' o non e' una scheggia
Il prob è che tu sei stato abituato a prestazioni scadenti dell'OS e dei
programmi, e di conseguenza di tutta la macchina,,,
Se vennissi da un mondo dove l'efficienza è la parola d'ordine, allora
sapresti davvero cosa è una scheggia.
Ciao,
Fabio Alemagna

 una suite di benchmark ottimizzata per BeOS.
Mi sono spiegato male: volevo semplicemente ringraziarti per quanto hai gia`
fatto.
-- 
  Da visitare: linux Weekly News - settimanale su Linux
http://www.lwn.net

 fatto.
Certamente. Il mio era un modo per stimolare proposte.
Saluti
Lele

molto diversa di cosa e' o non e' una scheggia
That's probably true, specie se tu la tua 'scheggia' la massacri con
win9x. Pensa ad un p100 con 32mb di ram, w311 e word 2.0. Ti assicuro
che batte tranquillamente qualsiasi word97 up to a dual processor...
Obelix

 wrote:
: >
: >>Secondo te un pentium 100 e' una una scheggia per compiti come la
: >>masterizzazione? 
: >Cioe', fornire un flusso di dati a BEN 600k/secondo? 
: Il problema ovviamente e' che il flusso deve essere abbastanza
: costante, in modo che la cache non si svuoti mai.
Cavolo... lo forniva anche il mio vecchio pentiun 75 con su linux...
bye
Gianluca
--
e-mail gianluca(at)
pluto.linux.it
        Member of the Pluto Linux User Group
http://www.pluto.linux.it/phl/index.html
 Pluto Hardware List
Boycott Microsoft 
http://www.cs.berkeley.edu/~mdw/boycott/
-----
Esprimo sempre e solo opinioni personali


Guarda, io win95 non lo vedo mai (a parte quando devo giocare); come
forse avresti potuto intuire dagli headers, faccio tutto con Linux.
Quanto al tuo discorso su il p100+w311+word2, mi dispiace, ma si stava
parlando di avere la possibilita' di fare altro durante la
masterizzazione, quindi non mi pare sia li caso di tirar fuori SO
mono-task (o meglio, multitasking cooperativo che praticamente e' lo
stesso).
Ciao,
-- 
d i e g o
--
Per le repliche elimina dal mio indirizzo le cifre e le `x'


Questa tua affermazione mi lascia piuttosto perplesso, visto che io
uso Linux per tutto tranne che per alcuni giochi.
Se magari lo sapevi gia', e volevi proprio insinuare che Linux e'
inefficiente, ti invito a dirmi quale SO va meglio di Linux per
masterizzare (ma anche per fare tutto il resto se e' per questo), a
parita' di macchina, e perche'.



Comincio a sospettare di non essere abbastanza chiaro... 
Sono d'accordissimo che si puo' masterizzare anche con un pentium 75
(una volta si masterizzava anche con i 486+win95 credo), ma io
sostengo che un pentium 100 non e' proprio il massimo se si vuole
masterizzare E CONTEMPORANEAMENTE FARE ALTRO.
Ciao,


Diego Dainese ha scritto nel messaggio ...

Dipende dall'OS che usi... Sempre che il masterizzatore sia SCSI  (in altre
parole: sempre che tu non sia masochista).
Ciao,
Fabio Alemagna

bruciare il CD con un pentium 100. Per la cronaca tutto questo si puo'
Ma tu ti rendi conto di quello che hai detto??? Ma lo sai quanto tempo CPU
consuma quake?? mi pare quanto meno ovvio che non si possa masterizzare e
giocare a quake contemporaneamente su un P100. Mi meraviglio che tu ti...
meravigli che non si possa fare. Addirittura tu proponi pure di compilare il
kernel mentre giochi a quake e masterizzi un CD... Vabbè, a 'sto punto la
tua affermazione "con un P100 non si può masterizzare", mi appare sotto
tutta un'altra luce.
Ciao,
Fabio Alemagna


Io non ho mai affermato questo!! Anzi ho specificato un paio di volte
che sono d'accordissimo sul fatto che un pentium 100 va bene per
masterizzare... 
Non va bene pero' se si vuole masterizzare e avere la possibilita' di
fare qualsiasi altra cosa durante il processo, a meno di non usare le
priorita' real-time. In pratica e' questo che volevo dire con
quell'affermazione nel messaggio che ha dato via a questo (inutile)
thread.


cos'e' allora un K6-300 (l'attuale entry-level)?
E' un processore ammazzato dal software, cosa altrimenti???
Obelix