Free vs Net

rookie asmrookie a gmail.com
Lun 13 Feb 2006 14:47:38 CET


Il 13/02/06, Luigi Rizzo <rizzo a icir.org> ha scritto:
>
> On Sun, Feb 12, 2006 at 10:37:19PM +0100, Matteo Riondato wrote:
> ...
> > > > Dico -CURRENT vista la patch per il cpu time accounting committata
> in
> > > > questi giorni da phk@ [1]. Andrew Gallatin e lo stesso phk@ hanno
> > > > riscontrato ampi miglioramenti nelle prestazioni [2]. Come esposto
> da
> > > > Julian Elischer tuttavia, alcune cose non sono ancora "a posto", ma
> > > > phk@ ci sta lavorando [3]. La modifica comprende anche sparc64 e
> > > > sarebbe interessante vedere quanto migliorano/peggiorano i test,
> visto
> > > > che tu hai l'hw quasi pronto ;)
>
> visto che mi chiami in causa... il benchmark in questione,
> ammesso che sia significativo, ha risultati cosi` scarsi
> (su tutti e due i sistemi) che rendono difficile capire quale
> parte del sistema o del software sia responsabile della differenza:
> non esiste che per sparare una pagina html da 2k ci si mettano 20-40ms,
> a meno che non si debba aspettare di raccattare la pagina dal
> disco, oppure il sistema non resti bloccato su qualche select per
> troppo tempo, oppure apache o il benchmark facciano un numero spropositato
> di system calls, etc.r) la modifica di cui parlate sopra ti risparmia
> un microsecondo per schedulazione, dubito che l'effetto sia anche
> solo misurabile in questo caso.


Come ho gia' detto in un'altra e-mail, il porting su SPARCv9 fa pena.
Una cosa che nessuno tiene quasi in considerazione e' che FreeBSD e' stato
progettato ed implementato inizialmente per i386 e alpha. La 5, la 6 e la 7
sono punti di passaggio che rappresentano una maggiore apertura di FreeBSD
verso altre piattaforme e soprattutto verso piattaforme multi-core.
Non sono cose banali.
Soprattutto, non si possono fare paragoni per un semplice motivo: e' tutto
troppo acerbo (l'avro' detto circa 500000 volte...).
In piu' considerate una cosa importante: i sistemi di sincronizzazione
fine-grained (per inciso quelli che utilizzano FreeBSD, Linux, etc.)
funzionano bene solo se il lavoro e' stato gia' scritto avendo in mente
parallelismi vari. Convertire del codice pensato per funzionare in modo
'seriale' a parallelo e' difficile. Quindi in queste release quello che si
e' cercato di fare e' stato:
1) Parallelizzare il workload del kernel
2) Introdurre meccanismi di sincronizzazione adeguati
3) Portare FreeBSD ad altre architetture

(E scusate se e' poco....)
Mi sembra abbastanza per avere molte release di transizione in cui le cose
non possono funzionare in modo ottimale (parlo sia a livello di
funzionamento che di performance).

> BTW, e mi rivolgo anche a Luigi, qualcuno ha mai effettuato test
> > seri sulle prestazioni sugli SMP ?
>
> io non ho dati sottomano. Paolo Pisati forse ha letto qualche articolo
> significativo.
>
> > Visto che il futuro pare essere multi{core|thread|cpu}, mi domando se
> > il design assunto da FreeBSD dia davvero vantaggi in tali ambienti.
>
> mah... difficile da dire.
>

Avere delle primitive di questo tipo e' solo un dei vari approcci, e di
sicuro ce ne sono altri che hanno pro e contro. Nell'ordine:

- DFlyBSD attualmente non ha vere primitive di sincronizzazione.
Semplicemente si cerca di scrivere del codice che sfrutti poco parallelismo
e nelle sezioni di codice che necessitano di sincronismo si usano i token.
Questo approccio (molto piu' coarse-grained), rispetto a quello adottato da
FreeBSD, ovviamente snellisce il lavoro di sincronizzazione ma purtroppo
sfrutta poco il tanto decantato parallelismo che si dovrebbe avere in
macchine multi-cored.
- Linux usa in pratica un design analogo a quello di FreeBSD.
- Su NetBSD e OpenBSD non ho dati.

Ultima cosa: considerate anche che le macchine SMP hanno un design molto
povero. Il numero di CPU scala pochissimo (per un massimo di 4 se non si
vogliono troppi problemi con i bus). Forse il futuro sara' rappresentato da
macchine NUMA (certo non un futuro prossimo, ma con l'abbattimento di alcuni
costi forse...).

I miei 2 cents,
Attilio

--
Peace can only be achieved by understanding - A. Einstein
-------------- parte successiva --------------
Un allegato HTML  stato rimosso...
URL: http://mailman.gufi.org/pipermail/varie/attachments/20060213/24db34eb/attachment.html


Maggiori informazioni sulla lista varie