64 bits et C++

**Jean-Marc.Bourguet** · 11/01/2006, 14h19

Envoyé par BainE

et y a pas un rapport avec le nombre d'instruction que le pross peux gerer ???

avant sur les ancetres des pc en 8bits il n'existait que 256 instructions, maintenant 2^32.

Le format des instructions n'a guere de rapport avec la taille des registres d'usage general (et cette taille est la seule maniere sensee de definir ce qu'est un processeur 64 bits). Les processeurs 8 bits avaient des instructions sur plus d'un byte, certains processeurs 32 bits ont toujours des instructions sur un byte.

et je suis pas d'accord avec voider, sur une machine 64bits avec compilo 64bits un int devrait valoir 64bits.

Si j'ai bonne memoire, les premiers Alpha utilisaient un mode ILP64, mais ils sont passe rapidement a du LP64 qui est la norme en dehors de Windows (qui utilise du LLP64 si j'ai bien suivi).

Le probleme du ILP64 c'est qu'il n'y a pas de type 32 bits (ou pas de type 16 bits si on fait short de 32 bits) et on utilise donc encore plus de memoire. Car un probleme du 64 bits, c'est qu'en general il faut plus de memoire, et ce probleme etait encore plus cruxial au debut.

**Zitux** · 14/01/2006, 00h23

les perfs vont augmenter vu qu'a chaque accès mémoire c'est plus 32 mais 64 bits qu'on va récupérer, du coup a chaque cycle d'horloge on récupère le double (dans le cas de la SDRAM) quand on connait l'ordre de vitesse du CPU et de la RAM ca fait une sacré différence...
Tout ca en plus de permettre d'adresser une étendue d'adresse en mémoire gigantesque pour ne pas dire teratesque

(il me semble que ca dépasse le To <=> 1 milliards de Go)

**Jean-Marc.Bourguet** · 14/01/2006, 08h21

Envoyé par Zitux

les perfs vont augmenter vu qu'a chaque accès mémoire c'est plus 32 mais 64 bits qu'on va récupérer, du coup a chaque cycle d'horloge on récupère le double (dans le cas de la SDRAM) quand on connait l'ordre de vitesse du CPU et de la RAM ca fait une sacré différence...

La largeur du bus par lequel on accède à la mémoire principale n'a guère de rapport avec la largeur des registres d'usage général. De toute manière les processeurs ne voient plus que les caches...

En pratique le code 64 bits est plus lent que le code 32 bits. Un des facteurs qui entre en compte est que quasiment tous les objets grandissent et donc il y a une moins bonne utilisation des caches.

Tout ca en plus de permettre d'adresser une étendue d'adresse en mémoire gigantesque pour ne pas dire teratesque

(il me semble que ca dépasse le To <=> 1 milliards de Go)

10 bits ça fait en gros un facteur mille. Pour adresser un To, il faut 40 bits, si tu considères 64 bits, cela fait 16 millions de To :-)

**Zitux** · 14/01/2006, 12h01

oui c'est vrai que dans le même temps ils n'ont pas augmenté la taille du cache, d'ou en gros 2 fois moins de place dans le cache ce qui entraine un doublement des caches miss

mouais je sais que trop penser des 64 bits

**Jean-Marc.Bourguet** · 14/01/2006, 12h09

Envoyé par Zitux

je sais que trop penser des 64 bits

L'augmentation de l'espace d'adresse est l'unique raison pour laquelle nous fournissons nos soft avec des versions 64 bits. C'est aussi l'unique raison pour laquelle j'en utilise certains dans la version 64 bits.

**Gandalf** · 19/01/2006, 16h18

Certain programmes faisant des calculs sur de grand entiers (crypto) pourraient tirer parti du 64 bits.

**Manu35** · 31/01/2006, 14h11

Je me trompe peut être, mais cela fait bien longtemps que les bus de données et tailles des registres correspondant sont en 64bits (cf premier pentium).

Lorsque l'on parle en ce moment de processeurs et d'os 64 bits on parle du bus d'adresses uniquement donc la seul chose qui va changer sera la taille des pointeurs et donc les accès mémoires.

Les perfs de calculs et la gestion des types de bases n'en seront pas changés pour autant. La seul chose qui peut éventuellement changer c les performances des accès mémoires et le cast de pointeur en entier 32bits qui ne marcheras plus !

Mais comme je dis je peux me tromper

**Matthieu Brucher** · 01/02/2006, 16h47

Je crois bien que les registres généraux sont encore en 32 bits quand on est en mode 32 bits. En revanche, pour ce qui est des registres non généraux...

**Mast3rMind** · 02/02/2006, 15h34

Envoyé par Gandalf

Certain programmes faisant des calculs sur de grand entiers (crypto) pourraient tirer parti du 64 bits.

En effet, les cryptographes doivent se réjouir de la venue du 64 bits... tout comme les hackers, qui pourront casser certains algorythmes de crypto plus "facilement". (Je mets "facilement" entre guillements car en crypto on a souvent des surprises.)

**Rafy** · 02/02/2006, 21h41

Envoyé par BainE

et y a pas un rapport avec le nombre d'instruction que le pross peux gerer ???

avant sur les ancetres des pc en 8bits il n'existait que 256 instructions, maintenant 2^32.

et je suis pas d'accord avec voider, sur une machine 64bits avec compilo 64bits un int devrait valoir 64bits.

Il y a une constante qui est sur et certaine. J'ai déjà du le dire. Cette affirmation sera vrai à tout jamais, car elle définie le 1 en C++ (et peut-être même en C)
sizeof(char) vaudra toujours 1.

**Gandalf** · 03/02/2006, 11h32

Envoyé par Manu35

Je me trompe peut être, mais cela fait bien longtemps que les bus de données et tailles des registres correspondant sont en 64bits (cf premier pentium).

Lorsque l'on parle en ce moment de processeurs et d'os 64 bits on parle du bus d'adresses uniquement donc la seul chose qui va changer sera la taille des pointeurs et donc les accès mémoires.

Les perfs de calculs et la gestion des types de bases n'en seront pas changés pour autant. La seul chose qui peut éventuellement changer c les performances des accès mémoires et le cast de pointeur en entier 32bits qui ne marcheras plus !

Mais comme je dis je peux me tromper

Il existe d'autres mondes que celui du x86 ...

Parmis ceux-ci certains sont déjà en 64 bits depuis des années...

**Manu35** · 03/02/2006, 11h46

Envoyé par Gandalf

Il existe d'autres mondes que celui du x86 ...

Noooon 8)

Envoyé par Gandalf

Parmis ceux-ci certains sont déjà en 64 bits depuis des années...

exemples ?

Sinon, dans le cas spécifique du x86 quelqu'un a t il l'info sur la dimension des différents registres en bus en fonction du processeur (Pentium et athlon toutes versions) ?

**Jean-Marc.Bourguet** · 03/02/2006, 14h38

Envoyé par Manu35

Envoyé par Gandalf

Parmis ceux-ci certains sont déjà en 64 bits depuis des années...

exemples ?

Je ne saurais mettre de dates, mais le passage au 64 bits pour les Alpha, Mips, Sparc, POWER c'est les annees 90. (l'ordre est celui dans lequel je pense le 64 bits a ete disponible).

J'ai une sparc 64 bits sur mon bureau depuis pas mal de temps. Suffisamment longtemps pour que je ne puisse pas mettre de date.

**Sivrît** · 20/02/2006, 15h05

Pour faire du mauvais esprit je dirais que les x86 sont dans les derniers à virer au 64bits.

Sinon, dans le cas spécifique du x86 quelqu'un a t il l'info sur la dimension des différents registres en bus en fonction du processeur (Pentium et athlon toutes versions) ?

http://www.intel.com/ et http://www.amd.com/us-en/

En ce qui concerne les performances je n'ai que des liens qui datent. Par exemple :
http://www.x86-secret.com/popups/art...dow.php?id=118
Personellement je retiens surtout le gain non négligeable sur Povray

C'est domage de ne rien avoir de plus récent mais la situation n'a peut-être pas trop évolué depuis (Windows 64bits n'est pas vraiment denenu la norme).

Il faudra que je me décide à installer un Linux 64bits pour voir.

**outs** · 06/04/2006, 00h52

Envoyé par Sivrît

Pour faire du mauvais esprit je dirais que les x86 sont dans les derniers à virer au 64bits.

D'un autre coté on en avait pas vraiment besoin avant vu que ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable.

Le gros problème étant évidement de passer windows en 64 bits, ca va merder de partout

**Jean-Marc.Bourguet** · 06/04/2006, 09h35

Envoyé par outs

D'un autre coté on en avait pas vraiment besoin avant vu que ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable.

L'utilisation du 64 bits n'est pas particulierement du cote des particuliers -- ou la je ne vois gere que le montage video comme application ayant besoin de tant de memoire.

Et cela fait un certain temps deja qu'on peut acheter des systemes a base de x86 avec plus de 4GiB de memoire meme si les processus sont limites a 4GiB architecturellement et souvent moins car les OS generalement en utilisent une partie.

--
Jean-Marc

**outs** · 06/04/2006, 12h38

Oui on pouvait rajouter plus de 4Go, mais c'est quand même une grosse limitation de ne pas pouvoir avoir un processus qui en utilise plus. Cela obligerai d'introduire des processus pour une raison qui me parait artificielle (si on a besoin de + de 4Go pour ses données).

Je suis aussi très dubitatif sur l'intéret du 64bits, d'un autre coté l'évolution technique des x86 n'a jamais été raisonnaible ... mais plus marketing. Et si on me dit que je peut acheter un 64 pour le prix d'un 32. Pourquoi pas ?

**Jean-Marc.Bourguet** · 06/04/2006, 13h54

Envoyé par outs

Oui on pouvait rajouter plus de 4Go, mais c'est quand même une grosse limitation de ne pas pouvoir avoir un processus qui en utilise plus.

D'accord, mais je repondais a l'affirmation

ce n'est que récement que l'on peut acheter plus de 4Go de mémoire pour un prix raisonnable

cela fait longtemps qu'il y a des machines avec plus de 4 GiB de memoire physique. Depuis l'invention de la memoire virtuelle, jouer sur la difference entre memoire physique et memoire mappee a toujours ete le moyen de s'en sortir tant qu'on ne voulait/pouvait pas augmenter l'espace d'adressage et qu'on avait besoin de plus de memoire physique.

Cela obligerai d'introduire des processus pour une raison qui me parait artificielle (si on a besoin de + de 4Go pour ses données).

On peut aussi jouer avec le mapping (mapper des fichiers en memoire et les demapper en esperant -- en demandant si possible -- que l'OS ne fasse pas de transfert vers les disques, c'est apres tout ce qu'on fait deja -- mais l'OS s'occupe de tout -- avec la memoire virtuelle).

Je suis aussi très dubitatif sur l'intéret du 64bits,

Pour qui? Nos clients sont bien heureux de pouvoir lancer des versions 64 bits de nos outils, meme s'ils preferent les versions 32 bits car plus rapides (ce qui nous pousse a gerer la memoire d'une maniere impossible avec un GC d'ailleurs -- je suis pour l'introduction d'un GC optionnel en C++, mais je m'opposerais a ce qu'on le rende obligatoire, mais bon personne n'y pense -- pour augmenter la taille traitable en 32 bits).

d'un autre coté l'évolution technique des x86 n'a jamais été raisonnaible ... mais plus marketing. Et si on me dit que je peut acheter un 64 pour le prix d'un 32. Pourquoi pas?

Mon prochain ordi perso (date d'achat vraissemblable: vers Noel cette annee ou l'anne prochaine) sera 64 bits pour la raison que ce ne vaudra pas la peine de chercher a rester en 32 bits. Mais il est vraissemblable aussi que le fait que ce soit du 64 bits ne me servira que pour verifier que mes programmes perso ne dependent pas de cela... pas important du tout.

**outs** · 06/04/2006, 15h22

Envoyé par Jean-Marc.Bourguet

Je suis aussi très dubitatif sur l'intéret du 64bits,

Pour qui? Nos clients sont bien heureux de pouvoir lancer des versions 64 bits de nos outils, meme s'ils preferent les versions 32 bits car plus rapides

C'est vrai je parlais surtout d'un point de vue personnel j'aurais du le préciser. D'un autre coté il existe déjà des 64bits et souvent avec une conception du processeur plus intéressante. Mais maintenant que le rouleau compresseur du marché x86 est en marche vers le 64bits, je ne donne pas cher des familles alternatives de processeurs en 64bits. Qui étaient déjà pas mal moribond il est vrai.

Envoyé par Jean-Marc.Bourguet

Mon prochain ordi perso (date d'achat vraissemblable: vers Noel cette annee ou l'anne prochaine) sera 64 bits pour la raison que ce ne vaudra pas la peine de chercher a rester en 32 bits. Mais il est vraissemblable aussi que le fait que ce soit du 64 bits ne me servira que pour verifier que mes programmes perso ne dependent pas de cela... pas important du tout.

C'est vrai que c'est sympa. Mais tant que l'os et les drivers ne supporte pas a fond les novueau proc ca risque pas d'aller bcp plus vite.