linux user group brescia

On Tue, May 13, 2003 at 04:18:08PM +0200, Maurizio Paolini wrote:
> 
> > From: Enrico Colombini <erix a erix.it>
> >
> > ...anche perche' ottimizzare a tutti i costi un singolo punto non ha molto 
> > senso, l'ottimizzazione e' un processo globale :-)
> 
> Non ho seguito il thread, quindi potrei essere fuori tema.  Pero' mi sento
> di dire che, al contrario, l'ottimizzazione e' un processo puntuale, nel
> senso che si deve "battere" dove c'e' il collo di bottiglia.
> Quindi di 'globale' c'e' l'individuazione del collo di bottiglia, poi ci si
> deve concentrare li.
> 
Concordo appieno su questo... 
e' vero pero' che il discorso (per quello che ho seguito) non era sul disegno
di compilatori ma sull'opportunita' di alcune micro-ottimizzazioni locali
che tempo addietro (pensiamo macchine a 1/2 Mhz) potevano servire, ma
oggi rischiano solo di essere perniciose.

In realta' il profiling solitamente mostra che 
 a) micro-ottimizzazioni locali non portano quasi mai a guadagni
   apprezzabili [l'aumento di complessita' rende il codice meno
   gestibile e, solitamente, annulla tutti i vantaggi]
 b) le funzioni da analizzare sono quelle piu' semplici e piu' 
   di base... ad esempio, nel caso dell'algebra lineare, conviene
   ottimizzare la BLAS (vedi il progetto Atlas) piuttosto che 
   la LAPACK [chiaramente le librerie devono essere corrette e
   gli algoritmi i migliori possibili, ma ... ]
 c) un buon disegno di programma (ie. selezione delle strutture
   dati piu' opportune in partenza, struttura lineare delle
   operazioni da compiere, etc.) oltre che a migliorare la
   leggibilita' del codice, ha effetti positivi anche sulle
   prestazioni.

Questo detto, bisogna aggiungere una ultima cosa:
 le regole di ottimizzazione per processori diversi sono diverse...
 e questo si applica non solo quando si passa da una architettura
 all'altra (leggi, ad es. da ppc ad ia32 ad alpha, etc.) ma anche
 quando si passa da un processore all'altro: non sorprendentemente
 (ma nemmeno piacevolmente) del codice ottimizzato per athlon ha
 prestazioni scadenti su di un p4 e viceversa... [nota: i cicli
 di clock per eseguire una istruzione sono una buona indicazione, 
 ma non la sola ... tutte le CPU moderne sono superscalari, per
 cui una istruzione `veloce' che provoca lo stallo della pipeline
 puo' essere peggio di una `piu' lenta' che pero' non blocca
 la parallelizzazione]

Ciao,
 lg

 

> mp

--