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 ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pascal J. Bourguignon
cLx 'aimail.com.almost.invalid> writes:
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 <clx.kat@j'aimail.com.almost.invalid> writes:
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 {}.
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
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
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/
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
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 ?
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
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
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).
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
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).
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.
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).
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.
