Une question est souvent entendue actuellement, pourquoi les OS (surtout Windows) ne sont-ils pas encore majoritairement 64 bits ? Corollaire de cette interrogation, pourquoi Windows 7 va-t-il sortir en version 32 bits (tout comme Snow Leopard, Mac OS X 10.6) ? Plusieurs raisons expliquent la relative lenteur de l'adoption de ces versions. Faisons le point.
Un peu d'historique
Premièrement, rappelons qu'un passage de ce type a déjà eu lieu sur nos PC : celui du 16 au 32 bits. En 1985, Intel annonce le 80386, premier processeur x86 32 bits, qui faisait suite aux 80286 et au 8086 (le 186 a été très peu utilisé dans les PC), deux CPU 16 bits. Les premiers Windows étaient 16 bits et même si Windows 3.11 pouvait utiliser du code 32 bits avec certaines extensions (comme pour l'éditeur de niveau de Warcraft II), il restait codé en 16 bits. Windows 95 fut le premier Windows à nécessiter un processeur 32 bits mais il contenait encore beaucoup de codes 16 bits. En pratique, le premier Windows grand public qui ne contenait pas de code 16 bits fut Windows XP (ni NT 4.0 ni Windows 2000 ne sont considérés comme des OS grand public). Il a donc fallu attendre 14 ans pour abandonner le 16 bits dans l'OS. En pratique, Windows XP exécute d'ailleurs toujours les programmes 16 bits, seules les versions 64 bits de Windows ne le permettent plus. Comme on le voit, la tâche est longue.
L'apparition du 64 bits
Le 64 bits dans les processeurs x86 reste une technologie relativement jeune : le premier processeur compatible date d'avril 2003 et était destiné au marché professionnel (l'Opteron) et l'arrivée massive des processeurs 64 bits dans le grand public ne date que de la mi-2006 (n'en déplaise aux amateurs d'AMD, c'est le Core 2 Duo d'Intel qui a réellement lancé le 64 bits). Pour les OS 64 bits, l'arrivée de Windows en version 64 bits date d'avril 2005, avec un Windows XP destiné avant tout aux professionnels (basé sur le code de la version 2003 serveur). Il a fallu attendre Windows Vista (début 2007) pour un véritable Windows 64 bits grand public, soit quatre ans après le premier processeur compatible, ce qui est déjà rapide.
Pourquoi le 64 bits ne s'impose pas en 2009
Windows 7 et Mac OS X 10.6 sont prévus en version 32 bits. Pourquoi les versions 64 bits ne sont-elles pas les seules du marché ? La première raison est simple : il y a encore énormément de processeurs 32 bits sur le marché. Même si les Pentium 4 et les Core 2 sont 64 bits depuis environ 3 ans (tout comme les K8 et K10 chez AMD), il reste beaucoup de processeurs 32 bits : les K7, certains Sempron, certains Pentium 4, certains Celeron, tous les Pentium-M et tous les Core Duo. De plus, un des processeurs populaires de 2008, l'Atom N270, est uniquement 32 bits. La deuxième raison vient de l'intérêt du 64 bits : peu de programmes existent en 64 bits et les performances ne sont pas significativement meilleures. De plus, jusqu'il y a peu, 4 Go étaient un luxe. Enfin, sans OS 64 bits, personne ne développe en 64 bits, ce qui fait que personne n'achète d'OS 64 bits. La troisième raison vient des pilotes : un Windows 64 bits nécessite des pilotes spécifiques. Pour le matériel récent (disons moins de trois ans), on trouve généralement un pilote 64 bits pour Vista et parfois un pilote 64 bits pour XP. Pour les périphériques plus anciens, le pilote n'existe pas toujours. Le fait que Windows 7 utilise les mêmes pilotes que Windows Vista est un avantage : on ne devra pas attendre une réécriture complète. Enfin, la dernière raison est liée à l'industrie, parfois lente : Windows 64 bits ne prend plus en charge le code 16 bits, ce qui peut poser des problèmes avec d'anciennes applications.
Dans les faits, et même si Windows 7 va accélérer le passage au 64 bits, le code 32 bits risque de rester encore pendant très longtemps la norme pour les programmes et il n'est même pas totalement certain que le successeur de Windows 7 sera disponible uniquement en 64 bits.
Notons que cette analyse se limite à Windows, qui est un système bien plus dépendant du marché que Mac OS X et Linux. Pour Mac OS X, Snow Leopard sera le premier OS 64 bits de la firme (avec une version 32 bits pour les Core Duo) mais son successeur sera a priori totalement 64 bits, alors que Linux a été le premier OS x86 compatible 64 bits et que les distributions majeures existent toutes en 64 bits depuis un moment (ce qui pose dans la pratique moins de problèmes que sous Windows).
Non.
Seule l'Atom 230 et le 330 le sont, pas les N270 ni les Z.
Mais bon quelle différence entre 32 bit et 64 bit à part une plage d'adresse plus importante oui les pc(s) exploiteront les 4go de mémoire qu'il y a présent et on pourra aller plus loins.
Les arguments sur les applications et sur les entreprises sont plutôt pertinents, par contre.
Mais bon quelle différence entre 32 bit et 64 bit à part une plage d'adresse plus importante oui les pc(s) exploiteront les 4go de mémoire qu'il y a présent et on pourra aller plus loins.
Non non, Leopard peut utiliser des applis 64 bits mais reste 32 bits à la base.
Le 64 bits offre plus de registre (donc ça va parfois plus vite) et le code x87 est généralement remplacé par du SSE2, nettement plus efficace.
c'est EM64T, mais tout le monde avait compris ce dont tu voulais parler
Premier OS d'Apple à noyau 64 bits, mais le Leopard actuel fait déjà tourner des applis 64 bits (et peut utiliser plus de 4 Go de ram) car Cocoa et la couche Unix sont en 64 bits:
http://images.appleinsider.com/leopard-081028.gif
Bref, la transition a déjà commencée en douceur, depuis un petit bout de temps.
Mais pour la petite histoire NextStep qui a été repris en partie dans OS X était 64 bits depuis des lustres. Malheureusement l'architecture i386 de l'époque suivait pas...
Comme je te disais, et c'est sur le graphique du dessus, l'actuel Leopard est un hybride 32/64.
Concernant les registres, la plupart des applis sont en C (et dérivés, C++, Objective C, ...), langage qui se prête bien au stockage de variables dans des registres. Et plus il y en a mieux c'est car ça évite de nombreux accès mémoires.
Pour les pointeurs je veux bien qu'ils occupent 8 octets au lieu de 4, m'enfin ça fait pas grand chose en conso mémoire. C'est contrebalancé par la légèreté d'un code où l'on fait beaucoup appel aux registres.
Un programme mal optimisé, mal compilé par un un compilateur mal fait peut en effet donner un code moins rapide en 64 bits qu'en 32.
lors du passage 16-32, les programmes anticipaient le passage. L'OS restait 16 bits, un extender permettait de fair tourner du 32 bits. Freecell par exemple et les jeux dos touraient en 32 bits.
Pour le 64 bits, c'est le contraire, l'OS serait 64 bits avant les programme et on parle alors d'émulateur pour le 32 bits.
Complètement faux LVM. En moyenne jusqu'à 30% de plus pour la taille du binaire généré. Sans compter qu'il y a aussi du padding de tes types pour des raisons de performances. (voir ici http://www.ibm.com/developerworks/library/l-port64.html)
Le nombre de cache miss est donc plus important et donc tire les perfs vers le bas. Ce phénomène est plus ou moins compensé par les performances de gagnées grace aux registres supplémentaires.
Le code n'est pas plus "léger" en tout cas, si l'on parle de taille du binaire équivalent.
Que neni les registres sont plus longs il n'y en a pas plus
pour info, les processeurs x86 sont depuis longtemps capables de manipuler des données en 64 bits, via le x87 ou les extensions SSE/3DNOW!. maintenant que c'est le x86 lui-même qui est capable de manipuler directement des données 64 bits, les extensions sont passées, elles, au 128 bits.
non, ce qui a clairement retarder l'arrivée des applis 64 bits, c'est que cela nécessite une ré-écriture quasi complète du code, même avec un langage de haut niveau comme le c/c++. pour vous en convaincre, compilez en 64 bits un vieux bout de code et vous verrez le nombre d'erreurs et de warnings générés! bien sur toutes les nouvelles appli sont écrites de manière a pouvoir être directement compilées en 64 bits, et donc aussi en 32 bits. petit à petit, les appli 32 bits vont totalement disparaitre, c'est clair.
En parlant d'émulation... Bien que ça n'ai rien à voir, je croies, cela me fait penser à la virtualisation... Si celle-ci se "grandpublic-ise" (oui, oui, parfois j'invente des mots.
Donc, en dehors de l'aspect purement technique, du code, n'est-on pas aussi (surtout?) à untournant commercial... Comment vendre "plus" (de puissance, de possibilité) sans passer au 64bits ?
la course à la fréquence des processeurs est finie, et comment envisager de passer à 8, puis 16 coeurs, hypertradés, et resté à 3.3 Go de mémoire ???
je pense donc que, commercialement, le passage au 64 bits se fera maintenant rapidement, ou sinon, quelle raison aura-t-on de changer de machine ???
Complètement Faux.
On passe de 8 à 16 pour les GPR (general purpose registers). Pareil pour les registres SIMD.
(source : http://www.hardware.fr/articles/478-3/amd-athlon-64-athlon-64-fx.html)
Et aussi contrairement à ce que dit zorro, le x87 ne permet pas de traiter du 64 bits pour des entiers mais uniquement des floattant en simple et double précision.
Autant le passage de 16 à 32 était nécessaire : 65536 (2^16) ça fait pas beaucoup et ça limite. (64Ko de mémoire c'est en effet pas beaucoup). Mais 32 bits ça fait 4 Go, et avec les systèmes actuels passer au 64 bits ne profitable que pour augmenter sa mémoire vive. Et il me semble que 3 Go de mémoire c'est actuellement largement suffisant pour une utilisation normale.
De plus passer à un OS 64 bits( par rapport à un OS 32 bits, sur un c2d par exemple) diminue plutôt les perfs (comme il a été dit plus haut) puisque forcement au niveau matériel c'est plus compliqué eta ctuellement moins optimisé.
Le seul problème que je vois actuellement avec le 32 bits, c'est quand 2038 (c'est pas pour tout de suite encore) il y aura un pb avec les dates (overflow, c'est à dire que la valeur représentant le temps va dépasser la capacité des registres 32 bits, elle passera de +2 millaird à -2 millaird en gros)