linux user group brescia

>
> non male, se si pensa che tutto questo si ottiene semplicemente
> ricompilando in un paio di minuti i sorgenti.
> il pc in questione e` la mia macchina di casa, un petum 133, con 64 mb
> di ram. i test gli ho eseguiti su un hd scsi del 90, o giu` di li`,
> il piu` lento che ho. il carico di lavoro, al momento della prova,
> era di una cinquantina di processi, ovviamente non tutti attivi, 
> e una trentina di mb di swap in uso. comunque una normale situazione
> di lavoro, almeno nel mio caso, senza nessun accorgimento particolare
> per la prova.
>
> ora ho iniziato a fare delle prove con grep e, successivamente
> testero` awk, ma i dati che ho ottenuto mi lasciano delle perplessita`
> che, fino a che non mi saro` chiarito, non vale la pena postare.
> un'ultima nota... abilitare queste opzioni, al momento, in fase
> di compilazione del kernel non ha piu` senso. fondamentalmente
> per due ragioni: a) la fase di compilazione del kernel abilita
> da se` le dovute ottimizzazioni per il micro specificato nel
> config[1], e b) l'utilizzo del flag -O3 si rivelerebbe controproducente,
> in luogo del -O2, per ragioni che adesso non mi interessa analizzare
> (comunque leggendo la man del gcc si puo` capirne il perche`).
>
> salutoni e salutini,
> andrea gelmini
>
E' buona cosa fare tests di questo genere, anche per dimostrare che il
 lavoro del team di egcs serve ed e' servito a qualchecosa...
 Tieni conto che -mpentium non usa gli opcodes PROPRJ del pentium
 [vs. il set di istruzioni dei 486] ma semplicemente attiva alcune
 ottimizzazioni `economiche'. L'opzione -funroll-loops e una 
 -malign-jumps=2 dovrebbero fornire risultati ancora migliori...

Riguardo la compilazione del kernel:
 se volete sperimentare cose del genere siete benvenuti, ma potrebbero
 esserci degli inconvenienti. In particolare il kernel di linux sfrutta
 certe `particolarita'' del codice generato dal gcc e non e' troppo
 felice con ottimizzazioni `assurde' tipo -O9 -mpentium -funroll-all-loops.

In effetti quello e' un modo sicuro per raddoppiare il numero di bogomips
 sotto 2.2 e avere un grazioso lock subito dopo il computo della
 velocita' del sistema.
[questo e' dovuto al fatto che i bogomips erano calcolati (l'aloritmo e'
 cambiato nel 2.3.51) come tempo impiegato nell'eseguire un `ciclo a
 vuoto'; il -funroll-loops  dice al compilatore di sfruttare il
 parallelismo interno dei P5 per tentare di eseguire due istruzioni
 per volta e le NOP non mandano in stallo la pipeline... risultato:
 il ciclo viene eseguito a velocita' doppia e la calibrazione non 
 e' valida :( ]

L'ottimizzazione `spinta' del kernel puo' dare anche altri problmemi,
 soprattutto con versioni vecchie: uno dei peggiori che ho incontrato e'
 stato un errore nella gestione dei securlevel sotto 2.0 che comportava
 l'impossibilita' di avviare il server X... non carino.

Infine: le opizioni `per CPU' nella config del kernel attivano del
 codice in assembler per la CPU opportuna (salvo nel caso 486 in
 cui vengono cambiati anche gli allineamenti) piuttosto che ottimizzare
 il tutto globablmente.

Ciao,
 lg