Moi, je partage ton point de vue depuis longtemps. Passer de 32 à 64 est très différent de passer de 16 à 32. Ce qu'il faut prendre en considération, c'est :
- A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.
- Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
- 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.
Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.
- Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.
Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.
important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.
- Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.
Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.
A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.
Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.
- Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.
- Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.
Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.
[^] # Re: Explications sur 64 bits
Posté par Obsidian . En réponse au journal x86_64 en général et sur Mdv en particulier. Évalué à 7.
- A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.
- Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.
- 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.
Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.
- Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.
Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.
important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.
- Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.
Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.
A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.
Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.
- Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.
- Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.
C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.
Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.