[Tech] biprocessore

[Sergio Ballestrero]

 Ciao,
continuo questo thread - e mi scuso se e' venuto a noia a qualcuno -
perche' penso sia molto interessante.
 In particolare il circolo vizioso programmi single-thread -> richiesta di
velocita' della singola CPU -> abbassamento continuo dei prezzi delle CPU
veloci -> mancanza di richiesta di MB dual -> alti prezzi delle stesse ->
poco sviluppo di programmi multithread.
 Il tutto fa il gioco dei produttori di CPU e MB, cosi' che invece di
aggiungere un processore, ci troviamo a ricomprare tutto nuovo...

 Per quanto riguarda i dischi SCSI, beh, e' un oramai antico argomento,
che secondo me soffre anche del fatto che non si trovano praticamente mai
pubblicati dei benchmark di dischi sotto Linux, e che quindi quella
"migliore sensazione" nell'uso che spesso danno gli SCSI, risulta
difficilmente misurabile...
 Nei giorni prossimi dovrei mettere insieme (non per me, purtroppo :-) un
K7-800 con un buon disco UATA/66 7200 e ne approfittero' per farci girare
qualche benchmark (mi vengono in mente bonnie e iozone). Qualcuno avrebbe
mica la possibilita' di fare dei bench su un sistema SCSI non troppo
diverso ?

On Tue, 19 Sep 2000, Marco Ermini wrote:

> Sergio Ballestrero wrote:
> > 
> > > IMHO, un biprocessor non e' una via per avere un buon sistema
> > > risparmiando: e' una via per avere un ottimo sistema spendendo tanto...
> > 
> >  questo dipendo molto da cosa fai. Per l'uso "interattivo", di
> > "spippolamento generico" hai ragione, ma se hai spesso dei processi grossi
> > che girano (tipo simulazioni, data processing),
> 
> Che purtroppo non sempre sfruttano il multi-threading...

 quasi mai - il multithreading di solito lo faccio "a mano" :-)
 
> > e nel frattempo devi poter
> > anche fare qualcos'altro, ad esempio edit-compile-run, ti assicuro che il
> > dual e' favoloso: non e' piu' veloce di una macchina con singola CPU, ma
> > non ti rallenta mai. In pratica, e' una comoda alternativa al farsi un
> > minicluster :-)
> 
> Non dico che non sia favoloso: quello che ho detto e' che _forse_ non
> vale il prezzo che paghi. Paghi quasi quanto ad avere due computer, se
> conti il costo di una mobo dual, e non ne hai assolutamente le stesse
> prestazioni. Il mio invito e' a valutare bene il rapporto
> prezzo/prestazioni.
> 
> Se non sia hanno problemi di soldi, un dual processor e' un bel
> giocattolino, e non vedo particolari problemi ad usarlo con Linux
> (questo per sfatare qualche paura mistica: quando installi RedHat, ad
> esempio, il setup riconosce automaticamente il sistema dual e ti
> installa il kernel SMP): altrimenti meglio spendere i soldi in altro
> modo.
> 
> IMHO la Abit dual Celeron e' carina dal punto di vista didattico ;-) ma
> non vale assolutamente un bel Pentium III! (o perche' no, un Power PC!)

 penso che siamo d'accordo - semplicemente, io (quando ho comprato la mia,
che con i due celeron 400 mi costo' meno di un PIII 600) stavo facendo
cose (analisi dati di fisica delle alte energie, e in contemporanea
sviluppo del relativo software, con a volte qualche altro utente che usava
il mio PC come server da un Xterminal) per cui avevo occasione di usarla
davvero.
 Mi spiego meglio: dal mio punto di vista il fatto che nessun programma
riesca ad acchiappare tutta la disponibilita' di CPU, e' una benedizione.
Se ho da fare calcoli grossi, sono sempre cose che si possono in qualche
modo "dividere in due", magari facendo attenzione che lavorino su dichi
diversi; spesso, dato che sono cose che prendono comunque ore, preferisco
avere una CPU a disposizione per compilare, nel frattempo - e, per chi non
ha mai avuto fra le mani una dual, vi assicuro che funziona meglio che
tenere i processi in nice.
 E come ciliegina sulla torta, avere un sistema che rispondeva ancora
anche se il processo il soft real time che stavo sviluppando andava in
loop, e' stata una gran comodita'...
 L'altra cosa notevole e' che, con un gruppo senza enormi risorse, i
colleghi hanno spesso la passione di far girare i loro programmi dove
stanno i dati, e pazienza se e' la tua macchina. Se uno non vuole fare il
fascista e il geloso, forzandoli continuamente in nice 20, l'altra CPU ti
salva.

 Quindi si, sto parlando di un uso _molto_ diverso da quello comune. 

> >  Anche per compilare roba grossa, con un export MAKEFLAGS=-j3, spesso
> > riesci a sfruttarlo bene.
> 
> Purtroppo per molti programmi, come per esempio anche per il kernel,
> devono comunque attendere che si risolvano le dipendenze, per cui la
> compilazione con -j non porta significativi vantaggi (anzi con alcuni
> gcc capita che la compilazione termini con errore, perche' non vengono
> trovati i file oggetto compilati da un altro thread che ancora non ha
> terminato).

 sigh, lo so. quasi nessuno si da la pena di fare dei Makefile come si
deve. Ma quando sono i tuoi Makefile, allora ci puoi pensare...

> >  Comunque, concordo sul disco: non risparmiare su quello, anche se insisto
> > che lo SCSI vale i soldi che costa solo per certe cose (tipo tanti
> > processi che fanno piccoli accessi random a dischi diversi - come un
> > server http).
> 
> Attenzione, lo SCSI vale piu' di quello che puo' sembrare. Oltre due
> lustri di esperienza mi insegnano che e' sempre bene - soprattutto per
> quanto riguarda l'HW - comprare cose che possono essere riciclate molto
> bene in futuro. 

tipo il disco IDE da 250MB su cui tengo il backup della home ? :-P

> Io ho degli amici che usano ancora i dischi dei vecchi Amiga 4000 ;-)
> che si fanno ben onore! l'EIDE e' uno standard troppo precario,
> funziona bene soltanto se hai una mobo che ne sfrutta le
> caratteristiche ecc., e significa in buona sostanza ricomprare i
> dischi ogni volta che cambi il computer.

 cosa che uno si puo' permettere di fare perche' i costi sono ragionevoli !
Con l'andamento mostruosamente deflazionario dei prezzi, per quanto mi
riguarda le uniche cose su cui vale la pena comprare il meglio sono i
monitor e i mouse !

> Inoltre generalmente i dischi SCSI sono di fattura migliore (meno
> guasti ecc., spesso hanno un MFT o come si chiama garantito), hanno
> piu' cache ecc. e offrono in media prestazioni migliori di dischi EIDE
> a parita' di giri al minuto.

 Ci mancherebbe altro - con quello che se li fanno pagare ! :-)
Anch'io ho avuto una gran passione per le SCSI, ma adesso, con le CPU
veloci, non trovo piu' cosi' tanta differenza, almeno per l'uso che faccio
io del computer. Certo, se qualcuno mi chiede consigli per un server, io
rispondo SCSI !

> > E insisto anche con il RAID 0, che fa davvero miracoli.
> 
> Ovviamente ciascuno puo' avventurarsi dove pensa sia meglio, e come
> sempre, se uno se la sa cavare in un campo e' bene che ci stia ;-) per
> cui se uno lo sfrutta, e sa a cosa va incontro, buon per lui!

 Stai parlando di RAID, o di Linux in generale ? :-)

> Il mio consiglio - generico - sotto Linux e' pero' di evitare il raid
> software se non si sa quel che si fa, perche' puo' portare ad una serie
> di problemi. Rispetto agli Unix commerciali non c'e' ancora un
> filesystem completamente affidabile, i tool per il RAID sono scarsetti
> ed esistono almeno due algoritmi diversi di RAID, per cui un RAID fatto
> con un kernel non e' necessariamente riportabile nel successivo (es. un
> raid 0 fatto col 2.2.x puo' non essere compatibile con il 2.4.x, bisogna
> ricreare il set).

 Se non mi sbaglio, gia' dalla 6.1 (o forse addirittura la 6.0), la RedHat
patchava il kernel con la nuova versione di RAID che adesso e' standard
nel 2.4 (e credo anche negli ultimissimi 2.2) - il cambiamento dovrebbe
essere gia' passato.

> > Occhio ai backup, pero' !
> Se usi RAID software sotto Linux e' un must. Quotidiano.

 Ho tenuto due dischi (un 10GB e un 4GB, 5400 RPM) con delle partizioni in
RAID 0 per alcuni mesi, senza mai avere un solo problema (beh, si, uno:
quando ho fatto un upgrade e ho sbagliato il file di configurazione :-((
). Usati ovviamente come dischi di lavoro, non per i dati "delicati",
hanno retto un via vai di diversi GB ogni giorno, con delle prestazioni
tutto sommato vicine a quelle del vicino server con un disco SCSI III 7200
RPM, soprattutto come transfer rate.
 Certo, non gli affiderei l'unica copia di un database aziendale...
 
ciao !

--------------------------------------------------------------------------
 Things will get better despite             Sergio Ballestrero
our efforts to improve them.                  Sergio.Ballestrero@cern.ch
	-- Will Rogers                             S.Ballestrero@iname.com