Newsgroup: it.comp.programmare.win32
Titolo: [VC++] Compilazione molto lenta

Sto tentando di compilare un programma che contiene un modulo con circa
70000 righe di questo tipo:
bct= 3.77138066766 +   20426.57109242200  *t1; ac=     0.00000000004
*cos(bct); V3+= t5 *ac; V6+= t4* 5 *ac-t5*    0.00000000004 *
20426.57109242200  *sin(bct).
Il problema č che il compilatore sta ragionando da tre ore e mezzo e non ha
ancora finito; e non ho impostato alcuna ottimizzazione!
Se penso che devo compilare 8 moduli come questo, e magari con
l'ottimizzazione...
Avete idea di come posso velocizzare l'operazione?
Io ho pensato ad usare l'assembler; trovandosi le istruzioni bell'e pronte
dovrebbe essere pių veloce nella compilazione.
Grazie
Cristiano

 non ha ancora finito; e non ho impostato alcuna ottimizzazione!
C'č poco da ragionare su queste righe...
Il compilatore sarą andato in palla perchč neanche con codice di milioni di
righe ci mette tanto.
Controlla che non ci siano un numero spropositato di funzioni inline e in
tal caso prova a eliminarne qualcuna (nel senso di cancellare la keyword
"inline").
Comunque l'intera faccenda mi sembra molto strana.
Kiuhnm

 Comunque l'intera faccenda mi sembra molto strana.
Sembra strana anche a me. Non riesco a capire che accidente avrà da fare per
essere così lento!
Cristiano

 Non ce n'è nemmeno una.
Non è che ci sono un mare di include?
Kiuhnm

 Non č che ci sono un mare di include?
Solo uno (oltre a quello standard).
Cristiano

 20426.57109242200  *sin(bct).
Si`, ma qual'e` la struttura del sorgente? Una funzione per ogni riga,
un'unica mega-funzione nella quale i risultati precedenti costituiscono
i parametri successivi...
--
Lorenzo

 costituiscono i parametri successivi...
Quella che vedi qui sopra è una riga; nelle altre cambiano solo i numeri.
Comunque ho già risolto seguendo il consiglio di uno straniero :-)
Ho spezzettato il codice e ora la velocità di compilazione è "normale".
Grazie lo stesso per l'interessamento
Cristiano

 compilazione è "normale".
Allora questo è un bug del compilatore.
Kiuhnm

 Allora questo è un bug del compilatore.
Non e' affatto detto.
Tanto piu' che lo stesso problema capita con il compilatore Borland.
--------------------------------
Inviato via 
http://usenet.libero.it


Che il BCB V1 e il VC++ 6 siano "snarffed" (pieni di bachi) non ho dubbi, ma
non credo che questo possa considerarsi un bug.
Quoto la risposta del tizio che m'ha dato il suggerimento:
"I bet it will speed it up a lot. Compiling source code is a high order
algorithm, meaning that increases in the size of the input (source code in
this case) have disproportionately large effects on the speed.
That is, the overhead involved in compiling the file grows larger per line
added for every line you add to the file.".
In pratica, lui dice che il tempo necessario a compilare un modulo cresce
esponenzialmente con il numero delle righe (o istruzioni).
Io non lo sapevo e nemmeno lo immaginavo, ma da alcune prove che ho fatto ho
notato che è proprio così. Non credo che sia un bug.
Tornando, invece, ai bug veri e propri dei due compilatori, il BCB V1
"Standard edition" ritorna risultati completamente falsati quando un modulo
supera una certa dimensione (qualche centinaio di k) e non dà alcun avviso
durante la compilazione.
Il VC++ 6 "Enterprise edition", invece, genera un errore di codice corrotto
durante il linking (sempre per moduli da circa 500-600 k).
Preciso che questi comportamenti (che io ritengo assurdi) li ho notati
soltanto con il codice che ho postato l'altra volta.
Cristiano

 larger per line added for every line you add to the file.".
Allora diciamo che è palesemente inefficiente.
Se la velocità di compilazione aumentasse così velocemente al crescere della
lunghezza del file, perchè non spezzare il source code in modo automatico?
Non mi sembra un "algoritmo" troppo complesso da implementare!!!
Kiuhnm


Ma nemmeno troppo semplice :-)
Il compilatore, oltre a tutto quello che fa già (e non è poco), dovrebbe
pure "capire" in che modo unire efficientemente il modulo che lui stesso ha
spezzettato. Anche per le ottimizzazioni non sarebbe proprio semplice. E
sicuramente ci sarà qualche altro problema che adesso mi sfugge.
Cristiano