passage 32 bits vers 64 bits : mem virtuelle facteur 2
7 réponses
Karim
Bonjour
Je viens de passer un soft sur du 64 bits et je constate que la memoire
virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il
y a peut etre un flag a mettre au niveau de gcc (types, longueur des
pointeurs) ?
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
Christophe de Vienne
Bonjour
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Un flag pour faire quoi ?
A+
Christophe
Bonjour
Je viens de passer un soft sur du 64 bits et je constate que la memoire
virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il
y a peut etre un flag a mettre au niveau de gcc (types, longueur des
pointeurs) ?
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Un flag pour faire quoi ?
A+
Christophe
Olivier Miakinen
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ
Si tous les entiers qui étaient sur 32 bits se retrouvent occuper 64 bits, ça ne me surprend pas outre mesure.
(mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Si qq un a une idee ...
Je passe.
Je viens de passer un soft sur du 64 bits et je constate que la memoire
virtuelle a augmente d un facteur 2 environ
Si tous les entiers qui étaient sur 32 bits se retrouvent occuper 64
bits, ça ne me surprend pas outre mesure.
(mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau
de gcc (types, longueur des pointeurs) ?
Si tous les entiers qui étaient sur 32 bits se retrouvent occuper 64 bits, ça ne me surprend pas outre mesure.
et les taille des pointeurs passe de 4 a 8 octets ...
Eh oui. Tu as donc la réponse à ta question ?
-- Olivier Miakinen
kanze
Karim wrote:
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64 bits sur un Sparc, je ne constate pas d'énormes différences dans mes programmes. Ce qui change, c'est la taille des pointeurs et des longs, rien d'autre. Si ton application utilise d'énormes tableaux des long ou des pointeurs, son utilisation de la mémoire virtuelle augmentera notablement ; sinon, non.
Mais ça, c'est une évolution qui reste sur la même architecture, avec (à peu près) les mêmes instructions. Si tu passes d'un 32 bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas identiques. Je pense ici surtout à l'implémentation de malloc/free. Il existe beaucoup de façons à gérer la mémoire dynamique, et les plus rapides gaspillent souvent beaucoup de mémoire. Il se peut bien donc que pour les 32 bits, les auteurs en ont choisi un qui est assez rapide, mais qui ne gaspille pas trop non plus, tandis que pour les 64 bits, ils se sont dit, qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le 32 bits, tu perds 8 octets à chaque allocation, tandis que sur le 64 bits, ton allocation (plus les 8 octets nécessaires pour sa gestion) est arrondi à la puissance de deux supérieur -- tu alloues 1024 octets, le système y ajoute les 8 qu'il lui faut, pour faire 1032, et puis arrondit à la puissance de 2 supérieur, c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque essaie d'aligner certaines choses sur des frontières des pages ; si la taille des pages n'est pas pareille (chose forte probable), ça pourrait aussi avoir un effet sur l'utilisation de la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement dans ton cas, on peut pas dire sans avoir fait des expériences, et de connaître ton application.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Karim wrote:
Je viens de passer un soft sur du 64 bits et je constate que
la memoire virtuelle a augmente d un facteur 2 environ (mais
gain en temps CPU). Il y a peut etre un flag a mettre au
niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64
bits sur un Sparc, je ne constate pas d'énormes différences dans
mes programmes. Ce qui change, c'est la taille des pointeurs et
des longs, rien d'autre. Si ton application utilise d'énormes
tableaux des long ou des pointeurs, son utilisation de la
mémoire virtuelle augmentera notablement ; sinon, non.
Mais ça, c'est une évolution qui reste sur la même architecture,
avec (à peu près) les mêmes instructions. Si tu passes d'un 32
bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les
autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas
identiques. Je pense ici surtout à l'implémentation de
malloc/free. Il existe beaucoup de façons à gérer la mémoire
dynamique, et les plus rapides gaspillent souvent beaucoup de
mémoire. Il se peut bien donc que pour les 32 bits, les auteurs
en ont choisi un qui est assez rapide, mais qui ne gaspille pas
trop non plus, tandis que pour les 64 bits, ils se sont dit,
qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le
32 bits, tu perds 8 octets à chaque allocation, tandis que sur
le 64 bits, ton allocation (plus les 8 octets nécessaires pour
sa gestion) est arrondi à la puissance de deux supérieur -- tu
alloues 1024 octets, le système y ajoute les 8 qu'il lui faut,
pour faire 1032, et puis arrondit à la puissance de 2 supérieur,
c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans
ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque
essaie d'aligner certaines choses sur des frontières des
pages ; si la taille des pages n'est pas pareille (chose forte
probable), ça pourrait aussi avoir un effet sur l'utilisation de
la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement
dans ton cas, on peut pas dire sans avoir fait des expériences,
et de connaître ton application.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64 bits sur un Sparc, je ne constate pas d'énormes différences dans mes programmes. Ce qui change, c'est la taille des pointeurs et des longs, rien d'autre. Si ton application utilise d'énormes tableaux des long ou des pointeurs, son utilisation de la mémoire virtuelle augmentera notablement ; sinon, non.
Mais ça, c'est une évolution qui reste sur la même architecture, avec (à peu près) les mêmes instructions. Si tu passes d'un 32 bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas identiques. Je pense ici surtout à l'implémentation de malloc/free. Il existe beaucoup de façons à gérer la mémoire dynamique, et les plus rapides gaspillent souvent beaucoup de mémoire. Il se peut bien donc que pour les 32 bits, les auteurs en ont choisi un qui est assez rapide, mais qui ne gaspille pas trop non plus, tandis que pour les 64 bits, ils se sont dit, qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le 32 bits, tu perds 8 octets à chaque allocation, tandis que sur le 64 bits, ton allocation (plus les 8 octets nécessaires pour sa gestion) est arrondi à la puissance de deux supérieur -- tu alloues 1024 octets, le système y ajoute les 8 qu'il lui faut, pour faire 1032, et puis arrondit à la puissance de 2 supérieur, c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque essaie d'aligner certaines choses sur des frontières des pages ; si la taille des pages n'est pas pareille (chose forte probable), ça pourrait aussi avoir un effet sur l'utilisation de la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement dans ton cas, on peut pas dire sans avoir fait des expériences, et de connaître ton application.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Karim
kanze wrote:
Karim wrote:
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64 bits sur un Sparc, je ne constate pas d'énormes différences dans mes programmes. Ce qui change, c'est la taille des pointeurs et des longs, rien d'autre. Si ton application utilise d'énormes tableaux des long ou des pointeurs, son utilisation de la mémoire virtuelle augmentera notablement ; sinon, non.
tout d abord merci pour toutes ces precisions
en fait on utilise enormement les pointeurs, le "pb" doit venir de la. On a gagne 30 % en temps CPU (logique) mais la taille de la memoire virtuelle utilisee a considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux 64 b
Mais ça, c'est une évolution qui reste sur la même architecture, avec (à peu près) les mêmes instructions. Si tu passes d'un 32 bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas identiques. Je pense ici surtout à l'implémentation de malloc/free. Il existe beaucoup de façons à gérer la mémoire dynamique, et les plus rapides gaspillent souvent beaucoup de mémoire. Il se peut bien donc que pour les 32 bits, les auteurs en ont choisi un qui est assez rapide, mais qui ne gaspille pas trop non plus, tandis que pour les 64 bits, ils se sont dit, qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le 32 bits, tu perds 8 octets à chaque allocation, tandis que sur le 64 bits, ton allocation (plus les 8 octets nécessaires pour sa gestion) est arrondi à la puissance de deux supérieur -- tu alloues 1024 octets, le système y ajoute les 8 qu'il lui faut, pour faire 1032, et puis arrondit à la puissance de 2 supérieur, c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque essaie d'aligner certaines choses sur des frontières des pages ; si la taille des pages n'est pas pareille (chose forte probable), ça pourrait aussi avoir un effet sur l'utilisation de la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement dans ton cas, on peut pas dire sans avoir fait des expériences, et de connaître ton application.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze wrote:
Karim wrote:
Je viens de passer un soft sur du 64 bits et je constate que
la memoire virtuelle a augmente d un facteur 2 environ (mais
gain en temps CPU). Il y a peut etre un flag a mettre au
niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64
bits sur un Sparc, je ne constate pas d'énormes différences dans
mes programmes. Ce qui change, c'est la taille des pointeurs et
des longs, rien d'autre. Si ton application utilise d'énormes
tableaux des long ou des pointeurs, son utilisation de la
mémoire virtuelle augmentera notablement ; sinon, non.
tout d abord merci pour toutes ces precisions
en fait on utilise enormement les pointeurs, le "pb" doit venir de la.
On a gagne 30 % en temps CPU (logique) mais la taille de la memoire
virtuelle utilisee a considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux 64 b
Mais ça, c'est une évolution qui reste sur la même architecture,
avec (à peu près) les mêmes instructions. Si tu passes d'un 32
bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les
autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas
identiques. Je pense ici surtout à l'implémentation de
malloc/free. Il existe beaucoup de façons à gérer la mémoire
dynamique, et les plus rapides gaspillent souvent beaucoup de
mémoire. Il se peut bien donc que pour les 32 bits, les auteurs
en ont choisi un qui est assez rapide, mais qui ne gaspille pas
trop non plus, tandis que pour les 64 bits, ils se sont dit,
qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le
32 bits, tu perds 8 octets à chaque allocation, tandis que sur
le 64 bits, ton allocation (plus les 8 octets nécessaires pour
sa gestion) est arrondi à la puissance de deux supérieur -- tu
alloues 1024 octets, le système y ajoute les 8 qu'il lui faut,
pour faire 1032, et puis arrondit à la puissance de 2 supérieur,
c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans
ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque
essaie d'aligner certaines choses sur des frontières des
pages ; si la taille des pages n'est pas pareille (chose forte
probable), ça pourrait aussi avoir un effet sur l'utilisation de
la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement
dans ton cas, on peut pas dire sans avoir fait des expériences,
et de connaître ton application.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Je viens de passer un soft sur du 64 bits et je constate que la memoire virtuelle a augmente d un facteur 2 environ (mais gain en temps CPU). Il y a peut etre un flag a mettre au niveau de gcc (types, longueur des pointeurs) ?
Quel 32 bits ? Quel 64 bits ? Quand je passe de 32 bits à 64 bits sur un Sparc, je ne constate pas d'énormes différences dans mes programmes. Ce qui change, c'est la taille des pointeurs et des longs, rien d'autre. Si ton application utilise d'énormes tableaux des long ou des pointeurs, son utilisation de la mémoire virtuelle augmentera notablement ; sinon, non.
tout d abord merci pour toutes ces precisions
en fait on utilise enormement les pointeurs, le "pb" doit venir de la. On a gagne 30 % en temps CPU (logique) mais la taille de la memoire virtuelle utilisee a considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux 64 b
Mais ça, c'est une évolution qui reste sur la même architecture, avec (à peu près) les mêmes instructions. Si tu passes d'un 32 bits CICS (genre Intel) à un 64 bits RISC (prèsque tous les autres), la taille de l'exécutable risque d'augmenter aussi.
Finalement, il se peut que les bibliothèques ne soient pas identiques. Je pense ici surtout à l'implémentation de malloc/free. Il existe beaucoup de façons à gérer la mémoire dynamique, et les plus rapides gaspillent souvent beaucoup de mémoire. Il se peut bien donc que pour les 32 bits, les auteurs en ont choisi un qui est assez rapide, mais qui ne gaspille pas trop non plus, tandis que pour les 64 bits, ils se sont dit, qu'importe le gaspillage, on va pour la vitesse. Du coup, sur le 32 bits, tu perds 8 octets à chaque allocation, tandis que sur le 64 bits, ton allocation (plus les 8 octets nécessaires pour sa gestion) est arrondi à la puissance de deux supérieur -- tu alloues 1024 octets, le système y ajoute les 8 qu'il lui faut, pour faire 1032, et puis arrondit à la puissance de 2 supérieur, c-à-d 2048. Et ainsi en gaspille 1016, qui sont présentent dans ton espace virtuel, mais qui ne sont pas utilisé.
On pourrait imaginer aussi que le complateur ou la bibliothèque essaie d'aligner certaines choses sur des frontières des pages ; si la taille des pages n'est pas pareille (chose forte probable), ça pourrait aussi avoir un effet sur l'utilisation de la mémoire virtuelle.
Enfin, ce sont des possibilités. Pour ce qu'il en est réelement dans ton cas, on peut pas dire sans avoir fait des expériences, et de connaître ton application.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Karim wrote:
[Concernant le passage en 64 bits...]
On a gagne 30 % en temps CPU (logique)
Méfie-toi. J'ai vu pas mal des cas où le passage en 64 bits sur Sparc donnait des programmes plus lents. En fait, on perdait un peu de la localité, et rien d'autre (sauf, évidemment, la possibilité de traiter des jeux de données plus grandes).
mais la taille de la memoire virtuelle utilisee a considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux 64 b
Ou en 32 bits, le compilateur se limite au jeu d'instructions Intel, tandis qu'en 64 bits, il n'hésite pas à se servir des instructions supplémentaires AMD. Je soupçonne que la différence en performances vient surtout des instructions et des régistres supplémentaires, et non de la différence 32 bits/64 bits proprement parlé.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Karim wrote:
[Concernant le passage en 64 bits...]
On a gagne 30 % en temps CPU (logique)
Méfie-toi. J'ai vu pas mal des cas où le passage en 64 bits sur
Sparc donnait des programmes plus lents. En fait, on perdait un
peu de la localité, et rien d'autre (sauf, évidemment, la
possibilité de traiter des jeux de données plus grandes).
mais la taille de la memoire virtuelle utilisee a
considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux
64 b
Ou en 32 bits, le compilateur se limite au jeu d'instructions
Intel, tandis qu'en 64 bits, il n'hésite pas à se servir des
instructions supplémentaires AMD. Je soupçonne que la différence
en performances vient surtout des instructions et des régistres
supplémentaires, et non de la différence 32 bits/64 bits
proprement parlé.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Méfie-toi. J'ai vu pas mal des cas où le passage en 64 bits sur Sparc donnait des programmes plus lents. En fait, on perdait un peu de la localité, et rien d'autre (sauf, évidemment, la possibilité de traiter des jeux de données plus grandes).
mais la taille de la memoire virtuelle utilisee a considerablement augmente (donc logique aussi)
On utilise un gcc/g++ version 4 sur des opterons avec OS linux 64 b
Ou en 32 bits, le compilateur se limite au jeu d'instructions Intel, tandis qu'en 64 bits, il n'hésite pas à se servir des instructions supplémentaires AMD. Je soupçonne que la différence en performances vient surtout des instructions et des régistres supplémentaires, et non de la différence 32 bits/64 bits proprement parlé.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
