Newsgroup: it.comp.lang.c++
Titolo: Visual C++ 6

Cari amici, ho scritto il seguente programmino di test per controllare,
su richiesta di un cliente, eventuali differenze di efficienza tra array
globali (statici), array locali (automatici) e array inglobati in una
classe:
#include <iostream>
#include <ctime>
using namespace std;
const int nElem = 20000;
int v1[ nElem ];
int main()
{
    clock_t ticks = clock();
    for ( int i = 0; i < nElem; i++ )
        for ( int j = 0; j < nElem; j++ )
            v1[ i ] = v1[ i ] + v1[ j ];
    cout << clock() - ticks << endl;
    int v2[ nElem ];
    ticks = clock();
    for ( int i = 0; i < nElem; i++ )
        for ( int j = 0; j < nElem; j++ )
            v2[ i ] = v2[ i ] + v2[ j ];
    cout << clock() - ticks << endl;
    class V3
    {
        public:
            int &operator [] ( int i ) { return v[ i ]; }
        private:
            int v[ nElem ];
    } v3;
    ticks = clock();
    for ( int i = 0; i < nElem; i++ )
        for ( int j = 0; j < nElem; j++ )
            v3[ i ] = v3[ i ] + v3[ j ];
    cout << clock() - ticks << endl;
}
Ebbene, sul mio DJGPP il risultato è stato (come prevedevo) che questi
sono perfettamente equivalenti (i tre tempi risultano uguali) mentre il
mio cliente, sul suo VC++ 6, riscontra una netta superiorità di quello
statico rispetto, soprattutto, a quello nella classe (circa quattro
volte più lento).
Sapete illuminarmi? Non credo che il VC++ 6 sia così peggio del DJGPP, o
no?
EMG

 volte più lento).
Potrei dire una scempiaggine, visto che non conosco minimamente il VC++6,
ma potrebbe trattarsi di un problema con l'inlining di V3::operator[]...
Mi pare che quando la definizione di un metodo compare nella dichiarazione
di classe, il compilatore dovrebbe considerarlo implicitamente inline, ma
niente gli _impone_ di renderla effettivamente inline, potrebbe avere
qualche buona ragione per non farlo. Boh.
Max

no?
Al momento non ho il tempo di fare delle prove, se trovo un buco di 
tempo cerchero` di fare un test con diversi compilatori...
Cmq molto dipende sicuramente dal fatto che il metodo inline
venga effettivamente espanso o meno... in ogni caso i risultati
sono legati anche all'implementazione della classe, nel tuo caso mi
sembra sia solo un wrapper ad un normale array C... non mi aspetterei
differenze se operator[] viene effettivamente espanso inline.
Inutile dire che sul fronte design e manutenibilita` una classe ben 
fatta e` enormemente superiore.
Ma il tuo cliente ha necessita` cosi` strette?
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------


Con il BCC55 ho ottenuto praticamente gli stessi tempi.
Saluti  Manlio Perillo

 Ma il tuo cliente ha necessita` cosi` strette?
In realtà penso che sia caduto nel classico errore della
early-optimization.
EMG

 no?
No, no. Non pensiamo subito male del povero compilatore Microsoft che mi
piace così tanto:) Per smentirmi subito ho dovuto modificare leggermente il
programma perchè mi da un errore di redefinizione della variabile i :(( Poi
l'ho compilato ed ho ottenuto 18616, 19468, 180.000 e rotti !!! Cazzarola,
mi sono detto. Settings -> Ottimizzazione -> Inline funtion -> Any suitable.
Risultato 20950, 21791, 21821, meglio. Non so perchè non siano perfettamente
uguali, suppongo perchè clock() restituisce un valore totale e non un timing
relativo al thread in esecuzione (non ho voglia di usare GetThreadTimes).
Anche lasciando l'opzione di ottimizzazione sul valore di default only
__inline function, si ottiene lo stesso risultato spostando la dichiarazione
della classe V3 all'esterno della funzione main(). Ciao.

 mi sono detto. Settings -> Ottimizzazione -> Inline funtion -> Any suitable.
Grazie molte.
EMG