64 bits : pourquoi les OS sont-ils toujours 32 bits ?

Mais lol... l'atom est EMT64 einh...

Très bonne analyse. D'autant plus que des applis 64 bits utilisent plus de mémoire que les applis 32 bits (à cause de tout les pointeurs). Donc au final ça va être intéressant de passer sur du 64 bits le jour ou le PC de monsieur tout le monde aura de base 4 Go à 6 Go de ram d'installée.

Non.
Seule l'Atom 230 et le 330 le sont, pas les N270 ni les Z.

Je suis vraiment surpris car ayant un iMac, j'ai toujours cru que leopard tournait en 64 bit !!! je vais vérifier mes sources.

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.

Est-il utile de parler des anciens processeurs qui ne sont pas compatibles 64 bits ? Le fait est qu'un OS qui sort aujourd'hui est plutôt ciblé vers les processeurs actuels qui, hors Atom, sont compatibles 64 bits.
Les arguments sur les applications et sur les entreprises sont plutôt pertinents, par contre.

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.

houla, ça c'est de l'analyse de coin de bar.

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/ [...] ort64.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

c'est clair que la différence en 32 et 64 bits ne se limite pas à la capacité d'accès à la mémoire, ça c'est bon pour l'utilisateur lambda, comme croire que la différence entre xp/vista/seven se limite à l'apparence du bureau. codez directement en assembleur, et vous verrez tout de suite la différence entre 32 et 64 bits, bien plus importante que lors du passage de 16 au 32 bits!
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.), entre autre par le biais d'outils de sécurité (bac à sable?), dans les navigateurs web, etc, 4Go vont certainement très bientôt être le minimum, d'autant que le prix des modules mémoire laissent à penser que l'écart de pris entre 2Go et 4Go ou entre 4Go et 8Go n'est plus "dissuasif" et des contrôleurs mémoire sur 3 (voir 4) lignes (nehalem) seront "gadgets" si c'est pour accueillir des barrettes de 512Mo...
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 ???

Heu, a ma connaissance ce ne sont pas les core2 duo qui on lancé le 64bits mais plutot l'AMD64 qui est sorti très peu de temps après les Opterons en 2003, le Core2 duo lui est venu bien après.

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/47 [...] 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.

Question de profane : On ne pourrait pas imaginer que les fabricants d'OS diffusent massivement et par défaut une version 64 bits de leur OS, et qu'ils permettent par virtualisation de leurs anciens systèmes (ou émulation, je ne sais pas trop la différence) de faire tourner les applications 16 et 32 bits ?

Je voudrais ajouter à tout ça que l'intérêt est plus que limité pour l'utilisateur lambda tout simplement parce que les applications n'en ont pas besoin. Je veux dire par là que word, msn et ie n'ont pas besoin de 64 bits.

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)

Il me semblait que les unités x87 tournaient en 80 bit, 64+16 bit de parités ?

Compiler en 64bit ne pose aucun problème lorsque tes librairies sont en 64bit. Si t'a des erreurs c'est que le code de départ était déjà mal fichu.

Le passage des OS et appli. en 64 bits ne me semble pas être une priorité, le gain est à peine perceptibles. Seuls les traitements en mémoire bénéficient de l'augmentation de taille des mots. Le gain est nul sur les E/S. Sans conter les tracasseries que vous évoquez dans les faits.

L'intérêt maintenant pour les éditeurs(et consommateurs) est d'optimiser leurs applis. pour les processeurs multi-core. C'est un travail de long halène... A commencer par former une nouvelle génération de développeurs.

excusé moi,mais le core 2 duo a absolument rien a f**tre ici.

C'est l'athlon 64 qui a lancé le 64bit,peux de temps après l'opteron.

A croire que intel vous donne des cachets.........

Rohhh, mais faut lire : antre un A64 qui a eu au mieux 15 % de pdm et un Core 2 Duo qui a genre 60/65 % du marché, cest qui qui lance quoi ?

Je dis pas que c'est le premier 64 bits, je dis que le 64 bits a été réellement utilisé après le lancement du Core 2 Duo...

J'aime bien la petite phrase "prevoyons les barbus qui vont casser les bonbons"




Ce qui veut dire qu'avant 2 ou 3 ans, on considerera que 4 go est le standard. La frontiere des 4 go est tres tres proches, en fait...

Petite question bête : à moins d'avoir un processeur 4 cores overclocké et une CG à plus de 200€ est-ce que ça à un intérêt significatif pour les joueurs de passer de 4Go de ram (avec 3.3 de reconnus) à disons 8Go ? ou même pour le démarage du système, à moins d'avoir un super ssd ou deux HDD en raid0, ça accélère le système une augmentation de la ram? (désolé de vous faire redescendre de vos débats hautement intéressants mais hors de ma portée avec cette question bassement materielle et concernant deus jeux en plus ^^')

on va faire simple : j'ai 6 Go de RAM et ça me sert. Vraiment. Genre quand je dois utiliser deux OS, quand je lance bcp de programmes, etc.

Personne n'en parle mais commercialement MS ne vas pas s'empecher de vendre des OS pour installaion sur des vieilles machines. Plus ils en vendent et plus ils font des dollards. Donc faire une version 32 bit est tout a fait logique pour eux (et rentable).

Windows est 64bits depuis Windows NT 4 version Alpha. Totalement 64bits, avec des outils de developpement 64bits et une emulation x86 16 & 32bits pour les applications non-64bits.

Ca fait maintenant 13ans que Windows a ete porte en 64bits, et non 5ans ou moins comme indique dans l'article. Un petit effort de documentation serait bienvenu :-)

à iapx1977 : je pense qu'ils calculent pour les éditions plus grand public (à partir de la version dérivée de server 2003 64 bits donc) et ta date est bizarre (je précise je n'y connait rien hein, ne le prends pas mal si je dis une connerie) vu que ça voudrait dire que il existe un Windows entièrement 64bits depuis 1996, soit 7 ans avant la sortie des optérons compatibles 64 bits qui, d'après l'article encore, serait le premier processeur 'grand public' à l'être.

NT4 ne tournais pas que sur des machines X86. Il y avais aussi le PowerPC, MIPS et l'Alpha

Par contre, que NT4 soit totalement 64 bits sur cette dernière ça me paraît bizarre