Discussion :

[progfou]

Bonjour tout le monde !
J'ai une question (qui en appelle probablement d'autres) concernant static.

J'ai une fonction, dans laquelle se trouve un tableau qui est toujours le même. Par conséquent, je le déclare en static :

Code :

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

static short tab[]={12, 5, 9, -196, 998};

C'est un exemple .

Mes questions :

• Est-ce que rajouter const devant short peut apporter quelque chose ?
• Puis-je savoir où est stocké ce tableau ?
• Dans le cas où mon tableau est "grand" (dans mon cas, 96 éléments), dois-je aligner celui-ci ? Si oui, quel alignement ?
• Toujours dans mon cas, les données tiennent dans un char, mais il est déclaré short. Est-ce préjudiciable ?

J'ai probablement d'autres questions, mais celles-ci sont essentielles pour ma compréhension .

Merci d'avance !

[Laurent Gomila]

Est-ce que rajouter const devant short peut apporter quelque chose ?

Si les éléments ne sont pas censés être modifiés par la suite, ça ne peut pas faire de mal de mettre un petit const.

Puis-je savoir où est stocké ce tableau ?

Dans la zone mémoire réservée aux variables statiques (qui n'est ni la pile ni le free-store).

Dans le cas où mon tableau est "grand" (dans mon cas, 96 éléments), dois-je aligner celui-ci ? Si oui, quel alignement ?

Pas forcément non, à moins que tu aies des contraintes d'alignement spécifiques ça ne sert à rien vis à vis de la taille du tableau.

Toujours dans mon cas, les données tiennent dans un char, mais il est déclaré short. Est-ce préjudiciable ?

A part que tu vas manger un peu plus d'espace mémoire, non. Mais dans ton exemple les données ne tiennent pas dans un char. Et si dans ton vrai code c'est le cas, alors pourquoi les déclarer en tant que short ? Tu as sans doute une bonne raison non ?

[progfou]

J'avais en tête une éventuelle utilisation des instructions MMX, mais à priori ce ne sera pas le cas. Du coup, la question hors coup mémoire s'est posée. Mais je suppose que de toutes manières ça ne change rien aux temps d'accès.

EDIT: Je me suis posé la question vis à vis de l'utilisation, car le tableau en question contient des coefficients, qui sont utilisés dans la fonction pour appliquer un filtre sur une image. Celle-ci contient des données qui tiennent dans un short. Le fait d'avoir un type différent n'implique rien ?

[MatRem]

Celle-ci contient des données qui tiennent dans un short. Le fait d'avoir un type différent n'implique rien?

Un short est souvent sur 16 bits, dans ce cas la valeur max est de 65535, donc à part les risques de dépassement de capacité ou de changement de signe tu peux faire des opérations avec d'autres types, certains cast seront automatiques et d'autres non...

[droggo]

Jao,

J'avais en tête une éventuelle utilisation des instructions MMX, mais à priori ce ne sera pas le cas. Du coup, la question hors coup mémoire s'est posée. Mais je suppose que de toutes manières ça ne change rien aux temps d'accès.

Oh que si.

D'une manière générale, les processeurs modernes n'aiment pas qu'on mélange les accès de différentes tailles, ni qu'on fasse des accès autre que la taille nominale du cpu (la largeur de son bus, quoi), ce qui signifie la même chose .

Donc, comme tu sembles sensible à la vitesse (envisage mmx ), pour ton tableau, le mieux serait de le faire en tableau de int.

[progfou]

Je ne trouve rien qui permette d'être catégorique sur ce point...
Peux-tu appuyer ton propos par un exemple ?
Ou un lien vers un site qui bench et montre l'intérêt ?

[koala01]

Je ne trouve rien qui permette d'être catégorique sur ce point...
Peux-tu appuyer ton propos par un exemple ?
Ou un lien vers un site qui bench et montre l'intérêt ?

Salut,

Au niveau des types, il y a déjà le problème de la "perte" potentielle d'informations lors de la conversion:

Si on considère, pour les besoins de l'exemple, qu'un char fait 8 bits et qu'un short en fait 16:

• convertir le short en char occasionnera la perte de 8 bits d'informations
• convertir un char de valeur négagive en short risque de provoquer un changement de signe et de valeur (selon le boutisme et ou le bit de signe)

Pour ce qui est du point de vue qui dit que les processeurs préferent quand on utilise les types correspondant à leur largeur de bus:

Si tu n'utilises pas le type qui correspond à la largeur de bus de ton CPU, il y a deux possiblités:

1. Soit tu utilise un type d'une taille inférieure à la largeur de bus, et, dans ce cas, tu perds tout l'avantage d'avoir une telle taille, vu que tu n'en utilise qu'une partie
2. Soit tu utilise un type d'une taille suppérieure à la largeur de bus, et, il te faut alors deux (jeu d')instructions pour gérer le type voulu en entier: un sur la partie qui rentre dans la largeur de bus, et l'autre, qui se rapporte à la partie exédentaire (avec le probleme en (1) qui revient )

Enfin, tu peux tomber sur des cas particuliers assez surprenants:

Si on considère (pour la facilité et pour l'exemple) qu'un char vaut 8 bit et que tu as une architecture 32 bits:

Tu pourrais te dire "comme il rentre 4 char dans ma largeur de bus, je fais copier les octets 4 à 4 dans mon accu"...

Sauf que:

• tu va devoir jouer avec les parties hautes, intermédiaire et basses de l'accu
• tu devra fournir quatres instructions pour remplir l'accu, là où tout le travail aurait pu etre fait en une seule

Bref, tu risque de mettre quatre fois plus de temps à utiliser un char plutot qu'un entier dans le cas précité