-fshort-enums

Le
cLx
Bonjour,

Que pensez vous de -fshort-enums ? J'ai trouvé ça quand je me suis rendu
compte que typedef enum { } monenumtype; bouffait 4 octets (sous mon
architecture).

J'ai un peu testé, avec cette option lors de la compilation, mes binaires
sont plus petits et sizeof(monenumtype) donne bien 1 au lieu de 4.

Bref, ça semble bien sympa. Cela comporte t-il des inconvénients ?

Merci,

--
cLx
http://clx.freeshell.org/
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal J. Bourguignon
Le #23488601
cLx
Que pensez vous de -fshort-enums ? J'ai trouvé ça quand je me suis rendu
compte que typedef enum { ... } monenumtype; bouffait 4 octets (sous mon
architecture).



Comment, je ne comprends pas, tu n'as pas 100000 differentes constantes
dans tes enums?


J'ai un peu testé, avec cette option lors de la compilation, mes binaires
sont plus petits et sizeof(monenumtype) donne bien 1 au lieu de 4.



Mais avec certains processeurs, maintenant traiter tes enums et les
structs qui les contiennent deviennent plus lent. Ou, avec certain
compilateurs, ça ne change rien pour les enums dans les structures, ils
occuperont toujours 4 octets (afin de ne pas ralentir les accès aux
champs qui les suivent).


Bref, ça semble bien sympa. Cela comporte t-il des inconvénients ?



Effectue une comparaison pour vérifier qu'il y a réellement un gain sur
le processeur et avec le compilateur que tu utilise.

--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
cLx
Le #23517071
On 22/06/2011 00:47, Pascal J. Bourguignon wrote:
Que pensez vous de -fshort-enums ? J'ai trouvé ça quand je me suis rendu
compte que typedef enum { ... } monenumtype; bouffait 4 octets (sous mon
architecture).



Comment, je ne comprends pas, tu n'as pas 100000 differentes constantes
dans tes enums?



Non, justement. Si j'en ai <= à 256, monenumtype peut très bien être un char
et pas un int.

J'ai un peu testé, avec cette option lors de la compilation, mes binaires
sont plus petits et sizeof(monenumtype) donne bien 1 au lieu de 4.



Mais avec certains processeurs, maintenant traiter tes enums et les
structs qui les contiennent deviennent plus lent. Ou, avec certain
compilateurs, ça ne change rien pour les enums dans les structures, ils
occuperont toujours 4 octets (afin de ne pas ralentir les accès aux
champs qui les suivent).



OK.

Bref, ça semble bien sympa. Cela comporte t-il des inconvénients ?



Effectue une comparaison pour vérifier qu'il y a réellement un gain sur
le processeur et avec le compilateur que tu utilise.




D'accord (on vient d'y coder des trucs en plus). Que dois-je regarder pour
voir la consommation mémoire totale (car %MEM c'est pas très précis) ? le 'RSS' ?

Ce que dit la doc:
"RSS: resident set size, the non-swapped physical memory that a task has
used (in kiloBytes). (alias rssize, rsz)."

Sinon après deux "make rebuild" voilà ce que ça donne sur une machine i386:

$ ls -l
-rwxr-xr-x 1 clx clx 25728 2011-06-30 10:49 with
-rwxr-xr-x 1 clx clx 25920 2011-06-30 10:50 without

$ ps ux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
clx 18627 0.1 1.8 6744 3560 pts/1 S<s 10:37 0:02 -bash
clx 19609 0.1 0.3 1924 764 pts/1 S< 10:53 0:00 ./with
clx 19610 0.1 0.4 1928 768 pts/1 S< 10:53 0:00 ./without

Ce qui voudrait dire que -fshort-enums m'a fait gagner 4Ko de ram ?


La doc dit aussi :
"The SIZE and RSS fields don't count some parts of a process including the
page tables, kernel stack, struct thread_info,
and struct task_struct. This is usually at least 20 KiB of memory that is
always resident. SIZE is the virtual size of
the process (code+data+stack)."

Donc pour que le test voit valide il faudrait que tout ce qui n'est pas
compté soit constant entre les deux tests avec et sans -fshort-enums ?

--
cLx
http://clx.freeshell.org/
Antoine Leca
Le #23521081
cLx écrivit :
Effectue une comparaison pour vérifier qu'il y a réellement un gain sur
le processeur et avec le compilateur que tu utilise.



Sinon après deux "make rebuild" voilà ce que ça donne sur une machine i386:

$ ls -l
-rwxr-xr-x 1 clx clx 25728 2011-06-30 10:49 with
-rwxr-xr-x 1 clx clx 25920 2011-06-30 10:50 without



Réduction de ~200 octets sur le total code + données pré-initialisées, y
compris donc les nécessaires extensions et contractions (pour interfacer
le stockage en mémoire qui utilise des octets, avec les registres sur 32
bits où se font les opérations).


$ ps ux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
clx 18627 0.1 1.8 6744 3560 pts/1 S<s 10:37 0:02 -bash
clx 19609 0.1 0.3 1924 764 pts/1 S< 10:53 0:00 ./with
clx 19610 0.1 0.4 1928 768 pts/1 S< 10:53 0:00 ./without

Ce qui voudrait dire que -fshort-enums m'a fait gagner 4Ko de ram ?



Probablement oui. Cependant, 4 Kio est l'unité de base pour
l'affectation de la mémoire avec la plupart des systèmes i386, donc le
gain réel est quelque part entre 1 octet et 8191 octets; il faudrait
faire plus de tests en faisant varier les autres tailles pour savoir de
combien réellement est le gain.
Autre point de vue, 8191 octets sur une consomation mémoire de 1,9 Mo,
au maximum tu as gagné 0,42 % ; pour ce qui concerne ton jeu d'essai, tu
as gagné 0,21 %.


Autre chose : quand Pascal faisait référence à faire une comparaison, il
faut aussi comparer les temps d'exécution : il est possible que les
extensions et contractions supplémentaires dont je parlais plus haut ait
un impact mesurable sur les temps de calcul.


Antoine
Publicité
Poster une réponse
Anonyme