Pier Luigi Fiorini plfiorini@xxxxxxxxx [mlerlug/erlug list] wrote:
http://www.debianplanet.org/debianplanet/article.php?sid=285&mode=thread&order=0&thold=0
Bah! Per me sprecano solo del tempo.
Pare che una compilazione per i586 (quindi Pentium) dia un 20% al
massimo di performance in piu' e che in altre macchine (tipicamente
i686) si possa verificare un decremento delle prestazioni.
Forse con Pentium GCC si possono ottenere migliori risultati.
Che ne pensate?
Scrivo offline, prima di aver letto l'articolo, ma supponiamo che più o
meno si tratti di una intera distribuzione, piuttosto che di un kernel e
di una libc, compilata ottimizzando per una CPU in oggetto.
Supponiamo che di ciò si tratti e sorvoliamo su come tale cifra sia
ottenuta (una media ? un mix di applicazioni ? un benchmark ?) basandoci
sul solo fatto che l'utente percepisca un miglioramento nel tempo di
risposta delle operazioni che di solito compie. Non eclatante ma
rispettabile.
L'aspetto che voglio discutere, non ne sia sorpreso chi legge i miei
messaggi abitualmente, riguarda più il possibile impatto di quanto
sopra sulla diffusione di Linux che il merito tecnico in senso stretto.
Da un certo punto di vista, poter affermare "Linux è ottimizzato per la
mia CPU mentre Windows è sempre quello" può costituire un vantaggio dal
punto di vista della soddisfazione del cliente: ne aumenta il senso di
autorealizzazione. Scadendo nel greve: "il mio è più lungo del tuo".
Tecnicamente, non è vero: rincorrendo gli errori OLE in Windows mi è
capitato più volte di vedere salti condizionati su flag impostati
riconoscendo la CPU al caricamento di una DLL (non tutte le DLL usano
gli stessi, ma questa è un'altra storia). Probabilmente per avere il
grosso del vantaggio basterebbe ricompilare kernel, libc, X e una
manciata di librerie di largo utilizzo, oltre a qualche server specifico
come ad esempio Apache.
Se per avere una distribuzione ottimizzata devo avere un CD separato,
tuttavia, ci sono svantaggi pratici non indifferenti: distribuzione
multipla, poca semplicità (non dimentichiamo che il ragionamento
prevede un contesto in cui un utente si fa impressionare da un argomento
di validità tecnica marginale), disallineamento e così via.
Mi pare che il discorso acquisterebbe maggior peso se un pacchetto,
diciamo .rpm visto che il contesto si presta più alle distribuzioni
commerciali, contenesse versioni compilate per le principali CPU e
scegliesse la versione appropriata a tempo di installazione. Ora come
ora non si tratta di una cosa plausibile: lo spreco di spazio
aumenterebbe il numero dei CD, che sono un costo vivo e un problema
logistico - ma con l'avvento della distribuzione su DVD potrebbe
benissimo diventare abbastanza pratico.
Due parole sull'implementazione:
- i pacchetti dovrebbero avere versioni compilate per le varie
CPU ma esprimere le dipendenze senza indicare la CPU [1];
- il singolo pacchetto può riportare una collezione arbitraria di
versioni compilate, in tal modo preparare il pacchetto diventa "ci
metto tutto ciò che si compila" ovvero un procedimento abbastanza
semplice da essere automatizzabile e quindi limitare al massimo il
disallineamento;
- l'installatore scarta i pacchetti che non hanno una versione
compilata compatibile con la CPU target, quindi quelli che restano
vanno implicitamente bene;
- l'installatore dovrebbe dare delle soddisfazioni, ovvero
"Installing X ... using the version optimized for your CPU ... done".
Condizione fondamentale perchè la cosa funzioni, tuttavia, è che questa
ottimizzazione sia sempre automaticamente valida, ovvero non sia mai
necessario nè desiderabile poter configurare questa scelta: se occorre
che io possa configurare questa ottimizzazione in modo da escluderla nel
caso essa dia origine a problemi, tanto vale fare come si fa adesso e
buonanotte.
[1] Questo è un requisito delicato: è possibile che a seconda della CPU
nell'ambito della stessa famiglia, p.es. compatibili 80x86, vengano
messe in atto ottimizzazioni diverse che possono precludere una perfetta
compatibilità binaria. Ad esempio, un allineamento diverso dei membri di
una struct. Non sono sicuro che si tratti di uno scherzo che non
richieda la collaborazione di chi scrive i sorgenti, oltre che di chi
realizza i pacchetti.
Davide Bolcioni
--
There is no place like /home.
|