Discussion :

[Nohatred]

Bonjour. J'ai une question très simple sur les variables.

Déjà, est ce que ca prend du temps au programme de réserver de la place dans la mémoire quand on initialise une variable ?

Ainsi, si on initialise nos variables dans la boucle infinie du programme, est ce que ca prend plus de temps que d'initialiser toutes les variables au début du programme ?
j'explique en code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
do
{
int var=0;
/* suite du programme */
}while(1);

prend-il plus de temps que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int var=0;
do
{
/*suite du programme */
}while(1);

Si oui, on m'a pourtant déconseillé les variables globales, quelle est la meilleur solution ?

[gorgonite]

faire int var=0; à chaque fois dans la boucle prend plus de temps que de faire int var; avant la boucle, et puis de de faire var=0; en début de boucle...

mais ça te permet d'être sûr de la portée véritable de ta variable... surtout dans un langage comme le C qui permet toute sorte de manipulation

[Nohatred]

ok, merci ^^

[MatRem]

Plutôt que de redeclarer la variable à chaque boucle, si tu veux réduire sa portée tu peux faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
{
   int var =0;
   do
   {
      /* suite du programme */
   }while(1);
}

[ToTo13]

l'espace mémoire est réservé lors de l'appel de la fonction.
En plus dans ce que tu fais, tu initialise à chaque passage dans la boucle, alors que si tu déclares au début, ca n'initialise qu'une seule fois.
Mais cela ne rentre pas en compte dans la complexité de ton algo.

[Emmanuel Delahaye]

Déjà, est ce que ca prend du temps au programme de réserver de la place dans la mémoire quand on initialise une variable ?

Un peu.

Ainsi, si on initialise nos variables dans la boucle infinie du programme, est ce que ca prend plus de temps que d'initialiser toutes les variables au début du programme ?

Ca en prend infiniment plus, par définition, mais c'est peut être nécessaire. Ca dépend de l'algo.

j'explique en code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
do
{
int var=0;
/* suite du programme */
}while(1);

prend-il plus de temps que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
int var=0;
do
{
/*suite du programme */
}while(1);

Si oui, on m'a pourtant déconseillé les variables globales, quelle est la meilleur solution ?

Aucun rapport avec les globales.

Ce n'est pas même algo. Ce n'est donc pas comparable. Que veux-tu faire exactement ?

[mehdi.berra]

Comme a dit TOTO ta question n est pas importante du tout dans la mesure ou ton programme est trop court pour poser ce genre de question


Mais effectivement,le fait de mettre la declaration a l interieur de la boucle,prendra plus de temps

[Emmanuel Delahaye]

faire int var=0; à chaque fois dans la boucle prend plus de temps que de faire int var; avant la boucle, et puis de de faire var=0; en début de boucle...

Ce n'est pas spécifié par le langage. La manière dont sont créées les variables locales peut changer d'un compilateur à l'autre.

[zooro]

Est-ce que certains compilateurs n'optimiseraient pas ce genre de choses en sortant la déclaration de la boucle, s'ils trouvaient que ce serait mieux ?

[jowo]

Ce n'est pas spécifié par le langage. La manière dont sont créées les variables locales peut changer d'un compilateur à l'autre.

Et moi qui croyait que les variables locales à une fonction étaient sauvées automatiquement dans le stack.

[Médinoc]

jowo: Ben non, les optimiseurs peuvent stocker ces variables dans des registres.
Bon, pas tellement sur un x86, mais sur un proc avec beaucoup de registres, c'est courant.

zooro: Si justement, c'est le boulot de l'optimiseur. Ton boulot, c'est de mettre la variable dans la boucle si sa valeur ne doit pas être reportée d'une itération sur la suivante: Cela réduit sa portée et augmente la lisibilité du code, puisqu'on sait du premier coup d'oeil que la variable n'est valide que dans la boucle.

[jowo]

Bingo Médinoc, j'avais oublié les registres. Honte à moi

[homeostasie]

Et moi qui croyait que les variables locales à une fonction étaient sauvées automatiquement dans le stack.

Ben non, les optimiseurs peuvent stocker ces variables dans des registres.
Bon, pas tellement sur un x86, mais sur un proc avec beaucoup de registres, c'est courant.

Je pense en effet que les variables locales sont sauvées dans la pile mais lors d'un changement de contexte, notamment appel d'une autre fonction.

Sinon, quand cette variable locale est utilisée, elle est chargée soit dans un registre soit en mémoire cache. Pour le cas de la boucle, je ne serais pas étonné qu'elle soit chargée en mémoire cache.

[Médinoc]

Je considère la mémoire cache comme de la mémoire.
Et pour un changement de contexte, ça peut être les registres eux-mêmes qui sont sauvés dans une zone mémoire associée au thread (sans passer par la pile, donc).

[gege2061]

Je pense en effet que les variables locales sont sauvées dans la pile mais lors d'un changement de contexte, notamment appel d'une autre fonction.

Nan tout le temps, pour le changement de contexte, suffit d'empiler à l'appel de la fonction puis de dépiler au retour.

Sinon, quand cette variable locale est utilisée, elle est chargée soit dans un registre soit en mémoire cache. Pour le cas de la boucle, je ne serais pas étonné qu'elle soit chargée en mémoire cache.

Si la variable est utilisée souvent, elle sera surement mieux dans un registre (si c'est possible).

[Trap D]

Si la variable est utilisée souvent, elle sera surement mieux dans un registre (si c'est possible).

Ce n'est pas le compilateur qui se charge de ce genre de chose ?

[homeostasie]

Citation:
homeostasie a écrit :
Je pense en effet que les variables locales sont sauvées dans la pile mais lors d'un changement de contexte, notamment appel d'une autre fonction.

Nan tout le temps, pour le changement de contexte, suffit d'empiler à l'appel de la fonction puis de dépiler au retour.

Je me suis relu, j'ai mal tourné ma phrase, c'est ce que je voulais dire!

Et pour un changement de contexte, ça peut être les registres eux-mêmes qui sont sauvés dans une zone mémoire associée au thread (sans passer par la pile, donc).

Je pense que la mémoire associée au thread peut être assimilée à une pile.
Puisque au moment où l'on crée un process, on lui alloue son espace mémoire que je considère comme sa pile. Les processus légers viennent donc taper dans cette zone mémoire.
Qu'entends tu par "registres eux mêmes qui sont sauvés"? C'est à dire qu'ils sont momentanément inutilisables tant que l'on ne restaure pas le contexe (ca serait dommage) ou on sauvegarde justement les valeurs de ces registres dans l'espace mémoire du thread?

[Médinoc]

Je veux dire que dans certains systèmes, dans la commutation de contexte, c'est le Kernel qui sauve les registres du thread d'origine quelque part en mémoire (et moi, je différencie le thread-local storage, les infos Kernel du thread et sa pile) et qui charge les registres du thread destination. Cela se fait donc à chaque changement de thread, et à aucun moment les registres ainsi sauvés ne passent par la pile.

Et dans un système multi-registre, même les appels de fonctions peuvent se faire par registre.