[Tech] biprocessore

[Marco Ermini]

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...

> 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!)

>  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).

>  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. 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. 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.

> 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!

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).

> Occhio ai backup, pero' !

Se usi RAID software sotto Linux e' un must. Quotidiano.


>  Sergio

ciao!

-- 
Marco Ermini
http://www.markoer.org
There are two major products that come out of Berkeley: LSD and UNIX.
We don't believe this to be a coincidence.      -- Jeremy S. Anderson