linux user group brescia

On Fri, Jun 25, 2004 at 03:07:19PM +0200, Sergio Bevilacqua wrote:
> Io farei un tentativo così:
> - prima di tutto ricompilar il kernel per pentium4 SMP
> - ricompilare gcc (questo di da un compilatore ottimizzato)
> - con il gcc ottimizzato ricompili httpd, php, e postgresql-server
> 
> è impossibile che questo non ti dia vantaggi di prestazioni!!!
con i programmi che abbiano interazioni delicate con il resto del sistema,
e' garantito che ottimizzazioni spinte portino solo a comportamenti
indeterministici (questo discorso vale per il kernel, come per postgres,
ecc... si badi, non mi sto riferendo a mie personali opinioni, ma ad eventi
gia' accaduti nel passato).
detto questo, se ottimizzare in questo modo mi richiede una settimana di
lavoro, mi costa molto meno prendere un micro piu' veloce, o una macchina
aggiuntiva (senza contare l'installazione delle patch di sicurezza future).
non solo, facciamo pure il caso che ricompilando ottenga un vantaggio
misurabile, ma:
a) il collo di bottiglia per un apache e' la banda e, in seconda battuta,
l'i/o dei dischi;
b) idem con patate per i database: selezionare cento tuple su 400.000.000
di tuple non e' sicuramente un problema di cpu, in primis;

inoltre, per i team di sviluppo, o almeno per quelli che seguo io, il
debugging/diagnosi di applicazioni compilate in modo buffo rappresenta
sempre una tragedia e un fottio di tempo perso.
detto questo, anch'io sono d'accordo che la ricerca di soluzioni per un
utilizzo piu' spinto del proprio hw sia cosa buona e giusta, cio' detto,
pero', la stabilita' e' la priorita', e delegare tutto questo alla sola
ricompilazione e' una strada che non porta a buoni risultati.

concludo giusto con un aneddoto...
tempo fa, vennero fatte delle modifiche alla gestione delle liste di
python, con un incremento prestazionale che andava ben oltre il 1000%.
inutile dire che questo riguardava la riscrittura di una parte
dell'algoritmo, piuttosto che la banale ricompilazione. idem per quanto
riguarda postgres, ad esempio nella gestione degli indici.

> rpm ricompilati con ottimizzazioni varie, e per i686. La differenza
> c'era eccome, sotto ogni aspetto.
sarebbero bello avere dei numeri (non sto ironizzando).
nella notte dei tempi, nella mia fanciullezza, scrissi un programmino
idiota, sul prestiogioso commodore 64, che si preoccupava di scrivere n
volte la A sullo schermo. bene, lo scrissi in basic e in assembly,
constatando un'incredibile diversita' di performance, in modo empirico.
poi, pero', mi accorsi che in realta' stavo eseguendo sempre lo stesso
programma basic, e che quindi non potevano esserci assolutamente le
diferrenze che ritenevo di percepire.

ad ogni modo, l'argomento e lungo e articolato, se qualcuno se ne vuole
fare carico si potrebbe affrontare in uno degli incontri del lug, ma in
maniera seria (ho l'applicazione Y che cosi' parte in 10 secondi, mentre
rifatta cosi' ci impiega 1 secondo).

> altro non so cosa dirti. prova e facci sapere. è una cosa interessante
> :)

baciotti e bacini,
andrea gelmini