Bonsoir à tous,
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles.
par exemple
char i;
for(i=0;i<100;i++) {
etc...
}
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Est ce que i n'occupe réellement que un octet ?
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma mémoire me jouait des tours...
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits (plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
Ben maintenant encore plus, si :)
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
En mémoire, oui, mais au prix d'une réduction de la performance pour les
adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int
faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma
mémoire me jouait des tours...
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès
à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits
(plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma mémoire me jouait des tours...
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits (plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
Ben maintenant encore plus, si :)
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma mémoire me jouait des tours...
En fait, sur certains compilateurs (Microtec/ Mentor Graphics), c'est réglable (c'est pratique...) 16 ou 32. Comme ça tout le monde est content!
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits (plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
Ben maintenant encore plus, si :)
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
En mémoire, oui, mais au prix d'une réduction de la performance pour les
adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int
faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma
mémoire me jouait des tours...
En fait, sur certains compilateurs (Microtec/ Mentor Graphics), c'est
réglable (c'est pratique...) 16 ou 32. Comme ça tout le monde est content!
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès
à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits
(plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
Ben maintenant encore plus, si :)
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Bizarre, j'ai commencé le C sur Atari ST et j'étais sûr que les int faisaient 16 bits... peut-être en x86 alors... l'avais dis que ma mémoire me jouait des tours...
En fait, sur certains compilateurs (Microtec/ Mentor Graphics), c'est réglable (c'est pratique...) 16 ou 32. Comme ça tout le monde est content!
De toute facon, cela ne fait que renforcer mon argument, puisque l'accès à un 32 bits sur 68000 sera strictement 2 fois plus lent qu'un 8 bits (plus lent qu'un 16 bits sur adresse paire seulement).
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
Ben maintenant encore plus, si :)
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Alexandre Bacquart
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits. Ta remarque n'est vraie que dans le cas des registres 32 bits.
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits.
Ta remarque n'est vraie que dans le cas des registres 32 bits.
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits. Ta remarque n'est vraie que dans le cas des registres 32 bits.
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits.
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Ta remarque n'est vraie que dans le cas des registres 32 bits.
Ah, ok.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32
bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits.
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit,
mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Ta remarque n'est vraie que dans le cas des registres 32 bits.
Ah, ok.
--
-ed- get my email here: http://marreduspam.com/ad672570
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Un acces 32 bits n'est pas plus lent qu'autre chose sur une machine 32 bits.
Enfin, revenons au C...
Oui, mais je ne peux pas te laisser dire ça. Un 68000 a un bus 16 bits.
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Ta remarque n'est vraie que dans le cas des registres 32 bits.
Ah, ok.
-- -ed- get my email here: http://marreduspam.com/ad672570 The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html C-reference: http://www.dinkumware.com/manuals/reader.aspx?libÉ9 FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Alexandre Bacquart
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit,
mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
Oups, j'avais oublié ce détail... Ok, le bus de données externe est 16-bit, mais il y a un bus interne 32-bits entre l'ALU et les registres, non?
Oui heureusement :) On dit aussi que le 68000 est un 16/32 bits.
-- Tek
Manhattan
"DomiPi" a écrit dans le message de news:40f5666e$0$62356$
Bonsoir à tous, Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles. par exemple
char i; for(i=0;i<100;i++) { etc... }
Qu'en est il de l'optimisation sur les PC 32 bits actuels? Est ce que i n'occupe réellement que un octet ? Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Merci de vos réflexions
Dominique
Pour ce qui est de la vitesse sur PC 32 bits, Intel recommande d'utiliser le type entier sur 32 bits ou 8 bits, et déconseille les entiers sur 16 bits. Une instruction manipulant une donnée sur 16 bits prend un octet de plus que la même instruction travaillant sur 8 ou 32 bits. Elle est décodée moins efficacement. Il vaut mieux utiliser des entiers sur 32 bits. En interne, le processeur travaille sur des registres de 32 bits, même si l'instruction manipule seulement 8 bits d'un registre.
Du point de vue de l'accès mémoire, accéder à 8 ou 32 bits est équivalent. Dans les deux cas, le processeur lira dans le cache si la donnée s'y trouve, ou chargera une ligne complète si elle n'y est pas.
Je dirais donc que pour les variables comme les compteurs ou autres, il vaut mieux travailler sur 32 bits. Pour les grandes tables, il vaut mieux utiliser le plus petit type pour optimiser le cache.
"DomiPi" <akuj0006@tiscali.be> a écrit dans le message de
news:40f5666e$0$62356$5fc3050@dreader2.news.tiscali.nl...
Bonsoir à tous,
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir
les
variables les plus petites possibles.
par exemple
char i;
for(i=0;i<100;i++) {
etc...
}
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Est ce que i n'occupe réellement que un octet ?
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Merci de vos réflexions
Dominique
Pour ce qui est de la vitesse sur PC 32 bits, Intel recommande d'utiliser le
type entier sur 32 bits ou 8 bits, et déconseille les entiers sur 16 bits.
Une instruction manipulant une donnée sur 16 bits prend un octet de plus que
la même instruction travaillant sur 8 ou 32 bits. Elle est décodée moins
efficacement. Il vaut mieux utiliser des entiers sur 32 bits. En interne, le
processeur travaille sur des registres de 32 bits, même si l'instruction
manipule seulement 8 bits d'un registre.
Du point de vue de l'accès mémoire, accéder à 8 ou 32 bits est équivalent.
Dans les deux cas, le processeur lira dans le cache si la donnée s'y trouve,
ou chargera une ligne complète si elle n'y est pas.
Je dirais donc que pour les variables comme les compteurs ou autres, il vaut
mieux travailler sur 32 bits. Pour les grandes tables, il vaut mieux
utiliser le plus petit type pour optimiser le cache.
"DomiPi" a écrit dans le message de news:40f5666e$0$62356$
Bonsoir à tous, Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles. par exemple
char i; for(i=0;i<100;i++) { etc... }
Qu'en est il de l'optimisation sur les PC 32 bits actuels? Est ce que i n'occupe réellement que un octet ? Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Merci de vos réflexions
Dominique
Pour ce qui est de la vitesse sur PC 32 bits, Intel recommande d'utiliser le type entier sur 32 bits ou 8 bits, et déconseille les entiers sur 16 bits. Une instruction manipulant une donnée sur 16 bits prend un octet de plus que la même instruction travaillant sur 8 ou 32 bits. Elle est décodée moins efficacement. Il vaut mieux utiliser des entiers sur 32 bits. En interne, le processeur travaille sur des registres de 32 bits, même si l'instruction manipule seulement 8 bits d'un registre.
Du point de vue de l'accès mémoire, accéder à 8 ou 32 bits est équivalent. Dans les deux cas, le processeur lira dans le cache si la donnée s'y trouve, ou chargera une ligne complète si elle n'y est pas.
Je dirais donc que pour les variables comme les compteurs ou autres, il vaut mieux travailler sur 32 bits. Pour les grandes tables, il vaut mieux utiliser le plus petit type pour optimiser le cache.
DomiPi
Merci à tous j'y vois un peu plus clair Dominique
"DomiPi" a écrit dans le message de news:40f5666e$0$62356$
Bonsoir à tous, Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles. par exemple
char i; for(i=0;i<100;i++) { etc... }
Qu'en est il de l'optimisation sur les PC 32 bits actuels? Est ce que i n'occupe réellement que un octet ? Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Merci de vos réflexions
Dominique
Merci à tous
j'y vois un peu plus clair
Dominique
"DomiPi" <akuj0006@tiscali.be> a écrit dans le message de
news:40f5666e$0$62356$5fc3050@dreader2.news.tiscali.nl...
Bonsoir à tous,
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir
les
variables les plus petites possibles.
par exemple
char i;
for(i=0;i<100;i++) {
etc...
}
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Est ce que i n'occupe réellement que un octet ?
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
"DomiPi" a écrit dans le message de news:40f5666e$0$62356$
Bonsoir à tous, Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles. par exemple
char i; for(i=0;i<100;i++) { etc... }
Qu'en est il de l'optimisation sur les PC 32 bits actuels? Est ce que i n'occupe réellement que un octet ? Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Merci de vos réflexions
Dominique
Antoine Leca
En , Emmanuel Delahaye va escriure:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits (taille des int). Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien sûr, cela économisait de la place en mémoire centrale, important en 1980.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16 bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7 étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k sont des compilos 32 bits.
Antoine
En Xns9526CBAB59175hsnoservernet@212.27.42.71, Emmanuel Delahaye va
escriure:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
En mémoire, oui, mais au prix d'une réduction de la performance
pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la
place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits
(taille des int). Le jeu d'instructions sait manipuler de la même manière
des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus
alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage
(indexation etc.): dans les versions initiales (<68020), il n'étaient pas
tous les disponible en version 32 bits, donc il était intéressant d'avoir
des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien
sûr, cela économisait de la place en mémoire centrale, important en 1980.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je
crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16
bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7
étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k
sont des compilos 32 bits.
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
Equivalent à la lecture de 16 bits (int sur 68k). On économise la place,
Non. En 68000, les int font 32 bits. Les short font 16-bits.
Non. Il y a deux "modèles" de processeur avec le 680x0: 16 bits ou 32 bits (taille des int). Le jeu d'instructions sait manipuler de la même manière des quantités sur 16 ou 32 bits (sauf peut-être les instructions les plus alambiquées genre CAS2). Mais ce n'était pas vrai pour les modes d'adressage (indexation etc.): dans les versions initiales (<68020), il n'étaient pas tous les disponible en version 32 bits, donc il était intéressant d'avoir des int sur 16 bits pour par exemple indexer les tableaux. De plus, bien sûr, cela économisait de la place en mémoire centrale, important en 1980.
Au niveau des pointeurs, le plus souvent ils étaient sur 32 bits, mais je crois bien qu'il y eut des compilos pour 680x0 avec des pointeurs sur 16 bits, dans un espace mémoire limité à 64 K (et les parties hautes de A0-A7 étaient forcées à 0).
Évidement, tout ceci est historique: aujourd'hui tous les compilos pour 68k sont des compilos 32 bits.
Antoine
Antoine Leca
En 40f5666e$0$62356$, DomiPi va escriure:
char i; for(i=0;i<100;i++) { etc... }
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Quelle optimisation ? il n'y a aucun code ici... Il faudrait regarder ce qu'il y a dans "etc..."
Est ce que i n'occupe réellement que un octet ?
Pas forcément. Normalement, les variables sont alignés en mémoire (en l'occurence, probablement sur une frontière de 32 bits, ou 128). Cette nécessité d'alignement fait qu'une simple variable i va "utiliser" tout l'espace entre deux frontières, donc 32 ou 128 bits. D'un autre côté, si tu as une autre variable j, celle-ci va venir dans le trou, et en fait elle n'occupera aucun espace.
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Elle peut.
En l'occurence, il n'y a pas de souci, car l'architecture Intel te donne toutes les possibilités (comparaison avec constante, incrémentation) en version 8 ou 32 bits, pour le même coût.
Mais si dans «etc...» tu fais la moindre opération, les choses peuvent changer. Par exemple, si tu as le code
a = a + i;
En version int, tu aurais
MOV EXX, i ADD a, EXX
Et en version char, tu vas avoir
MOVsX EXX, i ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus (qui à leur tour "coûte" du cache, empêchent certains Jcc de tenir sur 2 octets, ... Les analyses de AMD montrent que cet effet est sensible en temps d'exécution.)
Antoine
En 40f5666e$0$62356$5fc3050@dreader2.news.tiscali.nl, DomiPi va escriure:
char i;
for(i=0;i<100;i++) {
etc...
}
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Quelle optimisation ? il n'y a aucun code ici... Il faudrait regarder ce
qu'il y a dans "etc..."
Est ce que i n'occupe réellement que un octet ?
Pas forcément. Normalement, les variables sont alignés en mémoire (en
l'occurence, probablement sur une frontière de 32 bits, ou 128). Cette
nécessité d'alignement fait qu'une simple variable i va "utiliser" tout
l'espace entre deux frontières, donc 32 ou 128 bits.
D'un autre côté, si tu as une autre variable j, celle-ci va venir dans le
trou, et en fait elle n'occupera aucun espace.
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Elle peut.
En l'occurence, il n'y a pas de souci, car l'architecture Intel te donne
toutes les possibilités (comparaison avec constante, incrémentation) en
version 8 ou 32 bits, pour le même coût.
Mais si dans «etc...» tu fais la moindre opération, les choses peuvent
changer. Par exemple, si tu as le code
a = a + i;
En version int, tu aurais
MOV EXX, i
ADD a, EXX
Et en version char, tu vas avoir
MOVsX EXX, i
ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1
ou 2 octets de code en plus (qui à leur tour "coûte" du cache, empêchent
certains Jcc de tenir sur 2 octets, ... Les analyses de AMD montrent que cet
effet est sensible en temps d'exécution.)
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
Quelle optimisation ? il n'y a aucun code ici... Il faudrait regarder ce qu'il y a dans "etc..."
Est ce que i n'occupe réellement que un octet ?
Pas forcément. Normalement, les variables sont alignés en mémoire (en l'occurence, probablement sur une frontière de 32 bits, ou 128). Cette nécessité d'alignement fait qu'une simple variable i va "utiliser" tout l'espace entre deux frontières, donc 32 ou 128 bits. D'un autre côté, si tu as une autre variable j, celle-ci va venir dans le trou, et en fait elle n'occupera aucun espace.
Et si oui est ce que la vitesse d'exécution n'est pas pénalisée ?
Elle peut.
En l'occurence, il n'y a pas de souci, car l'architecture Intel te donne toutes les possibilités (comparaison avec constante, incrémentation) en version 8 ou 32 bits, pour le même coût.
Mais si dans «etc...» tu fais la moindre opération, les choses peuvent changer. Par exemple, si tu as le code
a = a + i;
En version int, tu aurais
MOV EXX, i ADD a, EXX
Et en version char, tu vas avoir
MOVsX EXX, i ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus (qui à leur tour "coûte" du cache, empêchent certains Jcc de tenir sur 2 octets, ... Les analyses de AMD montrent que cet effet est sensible en temps d'exécution.)
Antoine
cedric
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1 ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8 bits de l'intel ?
La misère de voir 32 beaux bits gachés alors qu'avec un code plus compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
Antoine Leca wrote:
Et en version char, tu vas avoir
MOVsX EXX, i
ADD a, EXX
MOVSX/MOVZX est plus cher qu'un simple MOV (dépend processeur), et coûte 1
ou 2 octets de code en plus
Comment ? Pas un seul compilo encore capable d'utiliser les registres 8
bits de l'intel ?
La misère de voir 32 beaux bits gachés alors qu'avec un code plus
compact, on aurait pu utiliser AL *et* AH, BL *et* BH, etc...
