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 ?
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... }
Pour une locale, c'est une erreur. Il n'y a probablement pas meilleur type
que int ou unsigned int. Les autres prennent autant ou plus de mémoire et obligent à une conversion.
-- -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', "DomiPi" <akuj0006@tiscali.be> wrote:
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...
}
Pour une locale, c'est une erreur. Il n'y a probablement pas meilleur type
que int ou unsigned int. Les autres prennent autant ou plus de mémoire et
obligent à une conversion.
--
-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/
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... }
Pour une locale, c'est une erreur. Il n'y a probablement pas meilleur type
que int ou unsigned int. Les autres prennent autant ou plus de mémoire et obligent à une conversion.
-- -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', "DomiPi" wrote:
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... }
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Il n'y a probablement pas meilleur type que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', "DomiPi" <akuj0006@tiscali.be> wrote:
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...
}
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Il n'y a probablement pas meilleur type
que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
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... }
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Il n'y a probablement pas meilleur type que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', "DomiPi" wrote:
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... }
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Je précise : "C'est une erreur de croire qu'on va gagner de la place en définissant une variable locale de type char".
Il n'y a probablement pas meilleur type que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
-- -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', "DomiPi" <akuj0006@tiscali.be> wrote:
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...
}
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Je précise : "C'est une erreur de croire qu'on va gagner de la place en
définissant une variable locale de type char".
Il n'y a probablement pas meilleur type
que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une
conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
--
-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/
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... }
Pour une locale, c'est une erreur.
Ha bon ? Chez moi, cela reste conforme.
Je précise : "C'est une erreur de croire qu'on va gagner de la place en définissant une variable locale de type char".
Il n'y a probablement pas meilleur type que int ou unsigned int.
Yes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
-- -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/
Dominique Baldo
DomiPi nous disait
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les variables les plus petites possibles.
Qu'en est il de l'optimisation sur les PC 32 bits actuels? ... est ce que la vitesse d'exécution n'est pas pénalisée ?
De manière générale optimisation en taille mémoire et optimisation en vitesse ont tendance à s'opposer.
DomiPi nous disait
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les
variables les plus petites possibles.
Qu'en est il de l'optimisation sur les PC 32 bits actuels?
... est ce que la vitesse d'exécution n'est pas pénalisée ?
De manière générale optimisation en taille mémoire et optimisation en
vitesse ont tendance à s'opposer.
Pour optimiser la place en mémoire, j'ai toujours l'habitude de choisir les variables les plus petites possibles.
Qu'en est il de l'optimisation sur les PC 32 bits actuels? ... est ce que la vitesse d'exécution n'est pas pénalisée ?
De manière générale optimisation en taille mémoire et optimisation en vitesse ont tendance à s'opposer.
Alexandre Bacquart
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire, quitte à étendre sa valeur à 32 bits dans ses registres (sans surcoût de conversion ou de RAM). Si ma mémoire ne me joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser et réduire la place prise par certaines adresses dans pas mal de contextes.
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Les autres prennent autant ou plus de mémoire et obligent à une
conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien
lire un octet en mémoire, quitte à étendre sa valeur à 32 bits dans ses
registres (sans surcoût de conversion ou de RAM). Si ma mémoire ne me
joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser
et réduire la place prise par certaines adresses dans pas mal de contextes.
Les autres prennent autant ou plus de mémoire et obligent à une conversion.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire, quitte à étendre sa valeur à 32 bits dans ses registres (sans surcoût de conversion ou de RAM). Si ma mémoire ne me joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser et réduire la place prise par certaines adresses dans pas mal de contextes.
-- Tek
Emmanuel Delahaye
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire,
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
quitte à étendre sa valeur à 32 bits dans ses registres (sans surcoût de conversion ou de RAM).
L'extension a un coût.
Si ma mémoire ne me joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser
Je ne connais pas l'assembleur 68k suffisament pour te répondre là dessus. Je me suis contenté de le suivre pas à pas l'émulateur lors de séances de debuggages mémorables...
et réduire la place prise par certaines adresses dans pas mal de contextes.
Quand on définit une variable locale 'de petite taille, pour optimiser', on ne s'attentend pas à ce qu'elle soit en mémoire avec une accession via un pointeur...
Alors que si c'est un int ou unsigned int, se sera plus facilement un registre.
-- -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:
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien
lire un octet en mémoire,
En mémoire, oui, mais au prix d'une réduction de la performance pour les
adresses impaires.
quitte à étendre sa valeur à 32 bits dans ses
registres (sans surcoût de conversion ou de RAM).
L'extension a un coût.
Si ma mémoire ne me
joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser
Je ne connais pas l'assembleur 68k suffisament pour te répondre là dessus. Je
me suis contenté de le suivre pas à pas l'émulateur lors de séances de
debuggages mémorables...
et réduire la place prise par certaines adresses dans pas mal de contextes.
Quand on définit une variable locale 'de petite taille, pour optimiser', on
ne s'attentend pas à ce qu'elle soit en mémoire avec une accession via un
pointeur...
Alors que si c'est un int ou unsigned int, se sera plus facilement un
registre.
--
-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/
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire,
En mémoire, oui, mais au prix d'une réduction de la performance pour les adresses impaires.
quitte à étendre sa valeur à 32 bits dans ses registres (sans surcoût de conversion ou de RAM).
L'extension a un coût.
Si ma mémoire ne me joue pas des tours, il se sert même d'op-codes spéciaux pour optimiser
Je ne connais pas l'assembleur 68k suffisament pour te répondre là dessus. Je me suis contenté de le suivre pas à pas l'émulateur lors de séances de debuggages mémorables...
et réduire la place prise par certaines adresses dans pas mal de contextes.
Quand on définit une variable locale 'de petite taille, pour optimiser', on ne s'attentend pas à ce qu'elle soit en mémoire avec une accession via un pointeur...
Alors que si c'est un int ou unsigned int, se sera plus facilement un registre.
-- -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/
cedric
Dominique Baldo wrote:
De manière générale optimisation en taille mémoire et optimisation en vitesse ont tendance à s'opposer.
C'est pourquoi les programmes, qui de nos jours sont si gros, vont si vite.
Dominique Baldo wrote:
De manière générale optimisation en taille mémoire et optimisation en
vitesse ont tendance à s'opposer.
C'est pourquoi les programmes, qui de nos jours sont si gros,
vont si vite.
De manière générale optimisation en taille mémoire et optimisation en vitesse ont tendance à s'opposer.
C'est pourquoi les programmes, qui de nos jours sont si gros, vont si vite.
cedric
DomiPi wrote:
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... }
Mauvais exemple.
Le type normalement le plus performant pour ce genre de chose est le type int puisqu'il est censé correspondre à la taille du mot "naturel" sur l'architecture donnée.
Là ou ca se justifierait, c'est si tu avais fait :
char i[1000];
au lieu de
int i[1000];
Dans ce cas tu aurais effectivement économisé de la mémoire sur certaines architectures (dont les i386 pur tous les compilos que je connais).
DomiPi wrote:
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...
}
Mauvais exemple.
Le type normalement le plus performant pour ce genre de chose est le
type int puisqu'il est censé correspondre à la taille du mot "naturel"
sur l'architecture donnée.
Là ou ca se justifierait, c'est si tu avais fait :
char i[1000];
au lieu de
int i[1000];
Dans ce cas tu aurais effectivement économisé de la mémoire sur
certaines architectures (dont les i386 pur tous les compilos que je
connais).
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... }
Mauvais exemple.
Le type normalement le plus performant pour ce genre de chose est le type int puisqu'il est censé correspondre à la taille du mot "naturel" sur l'architecture donnée.
Là ou ca se justifierait, c'est si tu avais fait :
char i[1000];
au lieu de
int i[1000];
Dans ce cas tu aurais effectivement économisé de la mémoire sur certaines architectures (dont les i386 pur tous les compilos que je connais).
Alexandre Bacquart
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart wrote:
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire,
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, le temps d'accès est au pire égal à celui d'un int.
-- Tek
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Alexandre Bacquart <tek512@hotmail.com> wrote:
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien
lire un octet en mémoire,
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,
le temps d'accès est au pire égal à celui d'un int.
Si tu considères un registre comme de la mémoire, oui.
Un 68k n'a pas de registres 8-bit (ni 16-bit, d'ailleurs)
C'est bien ce à quoi je faisais allusion. Mais un 68k peut très bien lire un octet en mémoire,
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, le temps d'accès est au pire égal à celui d'un int.
-- 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.
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
-- -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.
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
--
-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.
le temps d'accès est au pire égal à celui d'un int.
Pas sûr...
-- -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/
