View Full Version : [C]Utilizzo variabili globali e ottimizzazione
Ciao a tutti.
Sto facendo un programma dove, in gran parte delle funzioni, utilizzo una matrice. Per quantificare: se ho 10 funzioni, 8/9 fanno uso di questa variabile...
Ora mi chiedevo: dal punto di vista dell'ottimizzazione ed efficienza, conviene definire la variabile globale o continuare a passarla come parametro come sto facendo ora?
Io ho pensato che non convenisse metterla come globale perchè se alcune funzioni non la usano, vorrebbe dire allocare della memoria in più inutilmente.
Cosa ne pensate?
Supdario
09-01-2011, 11:02
Non serve metterla come globale, la differenza di prestazioni sarebbe trascurabile.
Al massimo puoi passare l'indirizzo della variabile alle funzioni (&variabile).
Non serve metterla come globale, la differenza di prestazioni sarebbe trascurabile.
Al massimo puoi passare l'indirizzo della variabile alle funzioni (&variabile).
Beh, ma se la differenza di prestazioni è trascurabile, allora converrebbe metterla globale, o no?
Supdario
09-01-2011, 11:24
Volendo puoi farlo, ma comunque si tratterebbe solo di una comodità tua, dato che non si tratta di un reale vantaggio prestazionale. :D
A meno che, ovviamente, non si tratti di una funzione velocissima che viene richiamata in continuazione.
L'inefficenza consiste nel copiare i dati ad ogni context switch specialmente se usi lunghe iterazioni o ricorsioni su queste funz.
Poi se davvero venga copiato oppure no dipende dal codice e dal compilatore, ad esempio nel Php che uso ora i parametri anche se passati by value non vengono duplicati in toto eccetto modifiche quindi di fatto la scelta se passare value o reference nella maggior parte dei casi e` solo un fatto di logica del programma ma non di efficenza.
Non uso il C da tempo ma mi pareva sia possibile copiare le struct quindi evita di farlo.
Visto che ti serve sempre sta variabile e non muta dimensione, se la metti static globale o passi un puntatore rimane solo una questione di stile, personalmente userei la static per pulizia.
L'inefficenza consiste nel copiare i dati ad ogni context switch Cosa vuol dire? :what:
Visto che ti serve sempre sta variabile e non muta dimensione, se la metti static globale o passi un puntatore rimane solo una questione di stile, personalmente userei la static per pulizia.
Io quello che faccio ora è:
la variabile matrice è dichiarata nel main del programma.
Quasi tutte le altre funzioni hanno un prototipo che chiama la matrice...
Cosa vuol dire? :what:
Termine errato in effetti, mi si erano attorcigliati i neuroni.. sarebbe solo chiamata+ritorno:)
Quasi tutte le altre funzioni hanno un prototipo che chiama la matrice...
Appunto dipende da che cos'e` la matrice o comunque che cosa dichiari nei parametri della funz. Se passi struct c'e` la duplicazione, array (o puntatori) no.
Termine errato in effetti, mi si erano attorcigliati i neuroni.. sarebbe solo chiamata+ritorno:)
Appunto dipende da che cos'e` la matrice o comunque che cosa dichiari nei parametri della funz. Se passi struct c'e` la duplicazione, array (o puntatori) no.
È un'array di struttura...
in C gli array vengono sempre passati per riferimento, quindi questo problema non si pone e non serve neanche esplicitare; per il resto dipende anche dal codice, di solito le variabili si dichiarano nel loro blocco di codice anche per comodità e per una migliore manutenibilità del codice.
Si ok lo so come funziona il tutto... Evidentemente non ci siamo capiti :)
Premessa: 8/9 funzioni su 10 hanno sempre lo stesso parametro tra gli argomenti del loro protipo, una matrice struttura ( formata da due interi per ogni cella ).
Domanda: Dal punto di vista prestazione e dell'efficienza, conviene dichiarare questa matrice come globale ( togliendola quindi da tutti i prototipi ) oppure continuare a passarla per riferimento come sto facendo ora?
cdimauro
11-01-2011, 05:54
Conviene utilizzarla come variabile globale, perché non perdi tempo a passarla ogni volta nelle funzioni (e se usi lo stack a eseguirne il push; l'eventuale "ripulitura" dello stack è una singola istruzione che elimina in un colpo tutti i parametri e le variabili locali, per cui in questa fase una variabile in più o in meno non pesa).
Questo a livello di ottimizzazione. A livello di manutenibilità del codice, in genere è meglio evitare l'uso di variabili globali accessibili da più "moduli".
In ogni caso dipende sempre dal problema da risolvere. Per il decoder JPEG 2000 che ho scritto avevo lo stesso problema che hai tu, ma le prestazioni erano molto importanti per cui il framebuffer e le strutture "statiche" relative alle informazioni di stato le ho infilate in singolo "modulo", e rese accessibili a tutti gli altri tramite il classico file include in cui le definivo come "esterne".
E' una cosa che quando l'ho proposta ha fatto storcere il naso al mio responsabile, ma che s'è rivelata semplificatrice e più efficiente a conti fatti.
Conviene utilizzarla come variabile globale, perché non perdi tempo a passarla ogni volta nelle funzioni (e se usi lo stack a eseguirne il push; l'eventuale "ripulitura" dello stack è una singola istruzione che elimina in un colpo tutti i parametri e le variabili locali, per cui in questa fase una variabile in più o in meno non pesa).
Questo a livello di ottimizzazione. A livello di manutenibilità del codice, in genere è meglio evitare l'uso di variabili globali accessibili da più "moduli".
In ogni caso dipende sempre dal problema da risolvere. Per il decoder JPEG 2000 che ho scritto avevo lo stesso problema che hai tu, ma le prestazioni erano molto importanti per cui il framebuffer e le strutture "statiche" relative alle informazioni di stato le ho infilate in singolo "modulo", e rese accessibili a tutti gli altri tramite il classico file include in cui le definivo come "esterne".
E' una cosa che quando l'ho proposta ha fatto storcere il naso al mio responsabile, ma che s'è rivelata semplificatrice e più efficiente a conti fatti.
Boh la stack non so come si usi in C ( se si può veramente usare come nell'assembler... ).
Siccome il codice che andrò a scrivere sarà per un programma 'embedded' diciamo, non ho problemi di manutenibilità del codice, visto che ci metterò le mani su solo io ( e poi il professore guarderà solo per valutarne l'efficienza )...
Detto questo, c'è modo di misurare effettivamente quanto il programma impieghi ad eseguiere le operazioni con una certa struttura ( matrice tramite parametro ) piuttosto che con un'altra ( variabile globale )?
cdimauro
11-01-2011, 13:07
Boh la stack non so come si usi in C ( se si può veramente usare come nell'assembler... ).
E' trasparente, nel senso che usando il C generalmente viene eseguito il push sullo stack dei parametri della funzione da chiamare.
Siccome il codice che andrò a scrivere sarà per un programma 'embedded' diciamo, non ho problemi di manutenibilità del codice, visto che ci metterò le mani su solo io ( e poi il professore guarderà solo per valutarne l'efficienza )...
Detto questo, c'è modo di misurare effettivamente quanto il programma impieghi ad eseguiere le operazioni con una certa struttura ( matrice tramite parametro ) piuttosto che con un'altra ( variabile globale )?
Scrivere un codice d'esempio con un loop sufficientemente grande da rendere apprezzabili le differenze. :fagiano:
E' trasparente, nel senso che usando il C generalmente viene eseguito il push sullo stack dei parametri della funzione da chiamare.
Scrivere un codice d'esempio con un loop sufficientemente grande da rendere apprezzabili le differenze. :fagiano:
Eh... Mi diventa già più difficile la cosa, perchè in se il programma non esegue grosse e complicate operazioni che richiedono una grande valutazione da parte del processore, sono tutte istruzioni molto banali che il processore esegue o meno, a seconda delle condizioni...
cdimauro
11-01-2011, 20:34
In questo caso vale la massima: "Premature optimization is the root of all evil" - Donald Knuth.
Ci stiamo bagnando prima del tempo. Pensavo che avessi già sperimentato una certa lentezza nell'esecuzione, tale da averti spinto a chiedere consigli su eventuali ottimizzazioni come quella di utilizzare una variabile globale, appunto.
In questo caso vale la massima: "Premature optimization is the root of all evil" - Donald Knuth.
Ci stiamo bagnando prima del tempo. Pensavo che avessi già sperimentato una certa lentezza nell'esecuzione, tale da averti spinto a chiedere consigli su eventuali ottimizzazioni come quella di utilizzare una variabile globale, appunto.
No :D Stavo chiedendo un vostro parere perchè molti dei miei compagni hanno utilizzato la variabile come globale, cosa che io invece, inizialmente non ritenevo opportuna ( ora non saprei )... Tutto qua... :)
La chiamata in funzione C non è molto esosa, per cui se non chiami quelle funzioni troppo spesso il gioco non vale la candela.
Poi non ricordo se in C c'è la possibilità di fare l'inline (e quindi eviti del tutto le chiamate a funzione se lo vuoi, tramite la keyword "inline") del codice o era solo fattibile in C++.
banryu79
12-01-2011, 14:47
Poi non ricordo se in C c'è la possibilità di fare l'inline (e quindi eviti del tutto le chiamate a funzione se lo vuoi, tramite la keyword "inline") del codice o era solo fattibile in C++.
In C99 hanno aggiunto l'inline dlle funzioni, se non ricordo male; in alternativa si usavano le macro :eek:
Mha, non so di cosa stiate parlando! :D
Io conosco le strutture fondamentali e leggermente avanzate, niente di più... :p
Mha, non so di cosa stiate parlando! :D
Io conosco le strutture fondamentali e leggermente avanzate, niente di più... :p
L'inline delle funzioni consiste nel dare una direttiva al compilatore di modo che ogni volta che vede il nome di quella funzione sostituisce la chiamata col codice stesso della funzione (evitando la chiamata appunto).
Esempio:
inline int add(int a, int b)
{
return a+b;
}
int main(void)
{
for (int i=0; i<10; i++)
{
printf(add(i, i+1));
}
return 0;
}
Se add viene dichiarata come "inline", nella printf viene generato direttamente il risultato (i + i +1) evitando appunto la chiamata a funzione.
Questo a grandi linee.
Non è una macro?!? :eek:
Com è che siamo finiti a parlare di questo? XD
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.