64 bits : kézako?

Arnaud de la Grandière |
Nous nous sommes longuement penchés sur deux des nouvelles technologies annoncées pour Snow Leopard, à savoir Grand Central et OpenCL, afin de vous aider à mieux comprendre leurs apports et leur fonctionnement. Mais il en est une autre qui pourrait vous laisser perplexe : le support du 64 bits.

Commençons par le commencement : un "bit" est la plus petite unité de mesure de l'information en informatique, les fameux 0 ou 1. Un octet est composé de 8 bits (d'où le nom). Les processeurs traitent les données différemment selon que leur architecture est en 8, 16, 32 ou 64 bits. Il en découle de nombreux effets, le premier d'entre eux est le nombre de données que le processeur est susceptible de traiter à chaque cycle de calcul : 1 octet sur un processeur 8 bits, 8 octets sur un processeur 64 bits. Un processeur 64 bits est donc à même de traiter beaucoup plus de données par cycle, mais cet avantage peut devenir un inconvénient pour les (nombreuses) données encodées en 8 bits, qu'il faut alors compléter avec des octets vides.

Le deuxième effet direct repose sur les valeurs maximales que le processeur est à même de traiter. Comme chaque bit peut avoir deux valeurs différentes (0 ou 1, donc), un processeur 32 bit peut donc traiter 232 valeurs différentes, soit 4 294 967 296 en tout. Concrètement, ça signifie qu'un processeur 32 bits est capable de "compter" de -2147483648 jusqu'à 2147483647 pour ce qui concerne les nombres entiers. Pour un processeur 64 bits, le nombre de valeurs différentes se monte à… 18.446.744.073.709.551.616! (dix huit trillions, quatre cent quarante six billiards, sept cent quarante quatre billions, soixante-treize milliards, sept cent neuf millions, cinq cent cinquante et un mille, six cent seize, rien que ça).

La conséquence directe d'une telle capacité se retrouve dans l'adressage mémoire du processeur. Les processeurs 32 bits pouvaient exploiter jusqu'à 4 giga-octets de mémoire vive (232), de même, les processeurs 64 bits peuvent, théoriquement du moins, utiliser jusqu'à 16 exa-octets (soit 16,8 millions de tera-octets, ou encore 17,2 milliards de giga-octets, ou encore dix milliards de fois plus que le seuil maximal de mémoire des processeurs 32 bits!)… de quoi voir venir avant d'atteindre de telles capacités.

Ces chiffres peuvent certes donner le tournis, mais surtout qui lèvent bien des contraintes. De nos jours, avec l'avènement de la vidéo numérique, il n'est plus si rare d'utiliser de très gros fichiers, gourmands en adressage mémoire. Les larges bases de données ainsi que le calcul scientifique s'en verront grandement améliorés. De manière général les gros fichiers seront plus faciles à manier (voir notre article Cocoa et 64 bits au menu de Photoshop CS5). L'architecture 64 bits règle également un certain nombre de problèmes de sécurité inhérents à l'adressage mémoire, qui reste encore le talon d'Achille de Leopard.

Cependant ces avancées ne se font pas sans contrepartie : les applications 64 bits utilisent plus de mémoire vive qu'en 32 bits. Sans parler du travail nécessaire de réécriture des logiciels pour exploiter cette architecture, bien peu de logiciels exploitent les processeurs 64 bits (voir notre article : Qui carbure au 64 bits?). Il faut également que le système d'exploitation puisse en tirer partie, et gère également les applications 32 bits. C'est ce qu'Apple avait déjà fait une première fois pour les processeurs G5, voilà donc qui sera de nouveau d'actualité pour Snow Leopard avec les processeurs Intel Core 2 Duo.
avatar bugman | 
@ Un Vrai Type : Ca fait longtemps que je n'ai pas fait d'assembleur et de C, mais un byte (un mot) a toujours pour moi fait 8 bits. C'est un long mot qui peut suivant l'architecture avoir une taille différente. ... Effectivement, pour ne pas dire de conneries, j'ai vérifié. Dans mon jeune temps on n'utilisait des processeurs 8 ou 16 bits (pour ma part des z80, ARM, et 68000). Ceci explique peut être cela. Etant autodidacte, je me suis peut être aussi mal renseigné. ... "Aujourd'hui on utilise plutôt le terme Octet pour désigner un mot de 8 bits." source : http://fr.wikipedia.org/wiki/Byte ...Comme je ne voulais pas mourir idiot j'ai également vérifier dans l'excellent "La référence du C norme ANSI/ISO de Claude Delannoy" (page 12) et... Là, j'apprend que : L'octet n'a pas spécialement une talle de 8 bits mais c'est cette taille qui est généralement utilisé [i](je suppose par le compilateur).[/i] Comme quoi... encore un mystère ! ;) Edition : [quote]Le Byte est la plus petite quantité utilisable en une opération.[/quote] On peut aussi utiliser directement un seul bit (flag) (mais effectivement en travaillant sur le "byte") avec ces langages (par opérations booléennes).
avatar Un Vrai Type | 
@ JayTouCon : toutes les applis ou toutes les nouveautés ? @ 6ix : J'imagine que nous n'avons pas fait beaucoup de recherche sur la taille des byte en France. L'utilisation juste est celle des anglais (puisque si un jour le Byte fait 10 bits sur 90% des processeurs, nous devrons changer le mot "octet" dans 99% des cas... ) De toute façon, la meilleure base de codage, c'est 3 et pas 2... A mort le bit ! Plus sérieusement, il y a tellement de piste actuellement pour faire un ordinateur d'un tout nouveau genre...
avatar JayTouCon | 
Ben ce qui engendre une restriction concernant les CG, ca serait bien de faire une liste des macs compatibles sur toute la gamme avec grand central et open CL, je crois que c'est la question que se pose le plus grand nombre. Tout le monde à compris que SL fonctionnerait sur les macs intel. voilou
avatar Un Vrai Type | 
@ bugman : Le C est justement un langage qui permet d'avoir des Byte qui ne font pas 8 bits... Enfin, C... ses compilateurs surtout. Pour la phrase citée, c'est clairement une erreur. Un octet FAIT toujours 8 bits (comme un alexandrin fait 12 pieds). Mais en C, le byte peut faire plus que 8 bits (de mémoire, il ne peut pas faire moins). La longueur du byte ne dépend pas du langage, mais du processeur... Les langages ne fonctionnent pas avec tous les processeurs (au niveau assembleur : 1 langage = 1 famille de processeur) Enfin on peut très bien avoir un adressage 64 bits pour la mémoire avec un processeur 32 bits... Cela demande juste 2 cycles pour charger l'information (tout comme dans le G4, on avait une unité vectorielle 128bits réels dans un processeur 32 bits. Enfin, est-ce qu'un OS peut se targuer d'être 64 bits lorsqu'il se contente d'appliquer le modèle 32 bits sur 64 ? @ JayTouCon : Je vais répondre bizarrement (mais je ne suis rédacteur sur Macgeneration, je pense qu'ils ont le temps de faire un petit article avec cette liste...) : Sur mes différents macs, aucun ne profitera pleinement de SL, mais tous en profiterons un peu.
avatar marc_os | 
[quote=Nihao] En fait le systeme prend 2Go pour lui et peut donner 2Go par process [/quote]@Nihao : Pourrais-tu stp citer tes sources pour étayer cette affirmation en général et en particulier pour Mac OS X ? Merci d'avance. PS : Comment ça se passe selon toi pour les ordis ayant seulement 2Go de RAM, voir moins ? PS 2 : +1 avec [b]Un Vrai Type[/b] au sujet de la définition du byte : 1 octet = 8 bits 1 byte = 8 bits [b]minimum[/b], en fonction du processeur
avatar Cactaceae | 
Moi je dis « chapeau ! » au rédacteur qui a poussé le courage d'écrire ce nombre titanesque (2^64) en toute lettre. Je crois que c'est la première fois que je vois un nombre aussi grand écrit, et je serais bien incapable de pouvoir le lire !
avatar tibet | 
@ 6ix [24/06/2009 10:46] @tibet: Avant de corriger les autres, assure-toi de ne pas dire n'importe quoi ! ;-) Si le byte est justement à tort pris comme l'équivalent de l'octet, car faisant le plus souvent 8 bits, ce n'est pas toujours le cas. C'est d'ailleurs bien la 1e fois que je vois l'explication du « binary eight » ! « octet » indique comme son nom l'indique un groupe de 8 bits, et est tout à fait valable en anglais. Simplement, par habitude j'imagine (je ne saurais pas dire exactement pourquoi), les anglais parlent de byte alors que nous parlons d'octet. Et on s'en assure où ? Chez wiki chose ? :) J'ai 'eu' bossé sur des machines de 4, 5, 6 ou 7 bits, si si des machins vraiment ésotériques, genre machine comptable phillips et autres joyeuseté chez NCR ou je ne sais plus trop qui (pour 5 j'imagine que j'ai du faire un cauchemar), mais il y a quelques décennies maintenant (disons 3, depuis 1974) et AVANT de bosser sur des machines 8 bits, je n'avais jamais entendu le mot Byte, ni pour désigner une bouchée, ni pour désigner 8 bits ce qui eut été sans objet ! C'est à l'arrivée de l'ASCII étendu et des machines 8 bits que j'ai appris aussi le mot Byte, l'explication que l'on nous a donné à l'époque, de Binary Eight n'a semblé ni erronée ni saugrenue à personne ! Auparavant, en programmation assembleur, on parlais de 'mot machine' pour désigner la taille des registres en général. Et cette expression Mot machine, on l'utilisait quel que soit le proc et on a continué ainsi, pour moi, jusqu'au 68030/68040. pas de byte à l'horizon avant le 8 bits ! Jamais rencontrer personne qui ai travaillé sur un byte qui n'ai pas fait 8 bits. que 'phonologiquement' parlant on puisse faire la relation avec une 'bouchée', pourquoi pas, c'est peut-être ce qui a assit l'orthographe, il existe ou existait (avant micromou en tout cas) une tradition d'humour en informatique.
avatar tibet | 
Et dernière chose, j'ai bossé avec quelques Anglais et s'ils connaissaient effectivement le mot octet (facile avec le calcul en octal qui était fréquement utilisé), je ne me souviens pas en avoir entendu un utiliser autre chose que le mot Byte. D'ailleurs en programmation on utilisait plutôt byte pour parler de taille par exemple de registre, mais ensuite si on faisait référence au 'poids'' des objets on utilisait plus facilement octet. Octet aussi quand on parlait par la suite de octet de poids fort ou faible dans les machines à 16 trucs. Et voilou et voilà, et de toute façon c'est pas ça qui va changer le monde ! nb : le fait d'entendre une chose pour la première fois ne la rend pas plus suspecte pour autant ! Non ? :))
avatar bugman | 
Bon, j'ai bien envie de dire +1 pour l'explication de tibet. Maintenant on ne va pas se faire la guerre pour savoir qui a le plus gros byte. ;) J'ai appris quand même quelque chose aujourd'hui: Qu'un byte n'est pas obligatoirement un octet. C'est déjà pas mal. Enfin, je crois... :/ Si il y a bien trois choses qui m'ont posés problèmes en programmation c'est bien ça, l'utilité des pointeurs et la POO (avant la découverte miraculeuse du "moule à gâteaux"). C'était le bon temps. En tout cas, merci à tous pour vos éclaircissement.
avatar tibet | 
@bugman [24/06/2009 15:28] Bon, j'ai bien envie de dire +1 pour l'explication de tibet. Maintenant on ne va pas se faire la guerre pour savoir qui a le plus gros byte. ;) J'ai appris quand même quelque chose aujourd'hui: Qu'un byte n'est pas obligatoirement un octet. C'est déjà pas mal. Enfin, je crois... :/ tibet: Moi je crois toujours pas, la bouchée ne passe pas :) Si il y a bien deux choses qui m'ont posés problèmes en programmation c'est bien ça et la POO (avant la découverte miraculeuse du "moule à gâteaux"). tibet: par contre je regrette de n'avoir jamais appris la POO, j'essaye bien de me mettre à O-C, j'ai même souscris un contrat développeur Apple - premier niveau -, mais je n'arrive pas à y consacrer le temps nécessaire ! hélas !
avatar bugman | 
[quote]tibet: par contre je regrette de n'avoir jamais appris la POO, j'essaye bien de me mettre à O-C, j'ai même souscris un contrat développeur Apple - premier niveau -, mais je n'arrive pas à y consacrer le temps nécessaire ! hélas ![/quote] Oui. J'ai laissé tomber après Le CPC et l'Amiga (bien plus accessible que le PC sous Win à mon avis et ses drivers). J'y suis revenu après sur consoles (Net Yaroze et DS). Aujourd'hui je suis passé à autre chose (plutôt réseau). Mais bon, on s'éloigne, là de la news, je crois. Merci en tout cas pour ce retour dans ma jeunesse.
avatar neckaros | 
Eh bien il y a une belle richesse dans tous ces commentaires! Juste un petit ajout: Pour la plupart des logiciels un simple switch dans XCode permet un passage en 64Bits si le logiciel utilise les API Cocoa. Seul les vieilles applis Carbon ne sont pas compatible. Par exemple mon appli ne peut pas passer en 64Bits pour l'instant car je dois extraire des metadata d'un fichier Quicktime et l'API et Carbon. Mais Quicktime X va résoudre tout ça. Par contre VLC 64Bits il est invivable!
avatar Psylo | 
@neckaros Par contre VLC 64Bits il est invivable! (minitroll)Peut-être sous OSX, mais sous Linux ou FreeBSD, VLC 64 bits tourne nickel.
avatar Hindifarai | 
La POO on peut en faire et on en fait sur des procs 8bits(appelez ça comme vous voulez dans ma boîte on parle en bits c'est plus simple et ça porte pas à confusion). Java était fait pour les machines à laver, à l'époque il n'y avait pas de i386 ou autre horreur de x86_64 dans vos Brandt...hé bien devinez quoi c'est toujours le cas, et votre téléphone portable n'a pas non plus de proc atroce et pourtant il fait tourner des applis en midpi(belle horreur de sun que tout le monde utilise au passage). Arretez de penser qu'il faut autant de bits pour coder avec un langage dit évolué. Proc 8bits n'est pas forcément synonyme d'assembleur, il suffit d'avoir un compilo performant et de se le faire a mano si besoin est. Quand vous comprendrez que vous vous faîtes avoir avec l'archi x86 les choses iront certainement mieux mais je suis sur qu'Intel a le temps de bien pourrir l'archi pendant une dizaine d'année avant que vous n'ouvriez les yeux, toute personne ayant eu à faire un compilo x86 et un compilo sparc ou ppc me comprendra. Pour vlc 64 bits sur osx voyez plutôt du coté de Qt...je dis ça je ne dis rien.
avatar Ali Baba | 
De toute façon on n'aura jamais besoin de plus de 256 bits. Parce que 256 bits, ça permet de compter jusque 10^77, soit à peu près le nombre d'atomes dans l'Univers... Même en miniaturisant la mémoire un million de fois plus efficacement qu'aujourd'hui, on n'en aura jamais autant que le nombre d'atomes de l'Univers ^^
avatar ispeed | 
Bon le 64 bites va nous apporter quoi ? Une opportunité pour les développeurs de nous faire payer une MAJ Merci Mr Apple charge de revanche :)))
avatar Un Vrai Type | 
@ tibet : Comment on respirait avant d'avoir découvert l'air ? Franchement le byte existe depuis 1956.... 1956... 1956 .... 1956. C'est pas parce que tu ne l'as découvert qu'après qu'on est tous menteurs, qu'on est tous menteurs,qu'on est tous menteurs. Compris ? Compris ? Compris ? Je stoppe les explications, si vous voulez en savoir plus sur la question demandez à Tibet. @ Hindifarai : Pour le x86 vs PPC et autre, c'est en effet l'impression que j'ai. Pourquoi les gens veulent du x86, sont-ils tous débiles ? (ha non ils n'ont plus le choix :( )
avatar jpvz74 | 
[b]NOS BESOINS SONT EXPONENTIELS : une simple étape ![/b] [b]Besoins : [/b] Identifier + qualifier + rendre instantanément utilisables de façon unique tous les objets/entités de l'Univers. [b]Solutions : [/b] - Atteindre et dépasser les limites de la taille de l'atome (actuellement vers des gravures au nanomètre), - Dépasser le système binaire (2 états seulement de la matière) pour en manipuler 4, 8, ..., 64, ... dimensions, - etc ... (en dépassant les limites de la vitesse de la lumière ?) [b]Réflexions :[/b] 1• Par analogie, nous en sommes encore à la technologie de l'âge de pierre ... en matière de traitement de l'information. 2• Le développement scientifique enregistré durant la deuxième moitié du 20ème siècle a été aussi important que celui réalisé depuis le début de l'humanité et on estime qu'il y a un doublement des connaissances scientifiques tous les dix ans.
avatar Hindifarai | 
@jpvz74 "Besoins : Identifier + qualifier + rendre instantanément utilisables de façon unique tous les objets/entités de l'Univers." C'est de l'humour non? Il faut arrêter de dire des conneries. Si tu veux faire du 256 bits émulé pour donner un identifiant unique à tous les atomes et que ça te chatouille à des endroits non nommables c'est faisable, inutile d'attendre que le grand Intel ne te fasse un proc sur mesure. Tu te fais une structure assez simple de 8 entiers comme identifiant, un protocole ad hoc et rulez! "- Atteindre et dépasser les limites de la taille de l'atome (actuellement vers des gravures au nanomètre)," Oui des processeurs avec des gravures de la taille d'un quark c'est un minimum! Il pourrait se manier à la sortir mon démineur est super lent chez moi. "- Dépasser le système binaire (2 états seulement de la matière) pour en manipuler 4, 8, ..., 64, ... dimensions" Ca rentre légèrement en contradiction avec la notion d'électronique mais bon...on n'est plus à une connerie près. "etc ... (en dépassant les limites de la vitesse de la lumière ?)" C'est celà oui... "Par analogie, nous en sommes encore à la technologie de l'âge de pierre ... en matière de traitement de l'information." Oui grand gourou montre nous la voie! "Le développement scientifique enregistré durant la deuxième moitié du 20ème siècle a été aussi important que celui réalisé depuis le début de l'humanité et on estime qu'il y a un doublement des connaissances scientifiques tous les dix ans." Et vous participez énormément à ce progrès et c'est pourquoi vous nous éclairez de votre lumière comment dire...blafârde?
avatar Nihao | 
@marc_os Explication du partage des 4Go par process (en fait 2) et du mode 3go sur XP par microsoft : [url]http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx[/url] De manière générale je parle d'expérience personnelle (je suis développeur pour un soft de CAO = type de logiciels très gourmand en mémoire), la mémoire adressable par process sur les OS 32 bits sur lesquels le logiciel tourne ( Windows, HP-UX, IRIX, Solaris et AIX) est généralement 2Go certains vont à 3Go (OS X c'est 2 je crois). Pour la consommation mémoire, ça va assez vite dans ce genre de problème allez un petit exemple tu prends un capot d'une bagnole disons 1 mètre par 1 mètre tu veux controler tous les 0.25 mm un problème de reflet (ça fait intervenir toutes les dérivées de la surface jusqu'à l'ordre 3 (je suis gentil) tu échantillonne donc 4000*4000 = 16 millions de lieu, chaque lieu à 3 coordonnées pour le points(=3 double, chaque double fait 8 octet), * 2 dérivées premières,+ 3 dérivées secondes + 4 dérivées 3e=> (1+2+3+4)*3*8*16 millions~3,8 Go... vive le 64 bits ! car sinon ton appli plante vers 1,8 Go sur Windows (car les 2go c'est théorique) ...
avatar bxlt | 
"Travail de réécriture en 64 bits". Effectivement, le jeu d'instruction intel n'est pas le même en 32 ou en 64 bits ! Quelle bêtise et quelle perte de temps ! Sachez que le jeu d'instruction du pauvre Motorola 68000, processeur 16 bits (du premier macintosh !) comportait déjà des instructions 32 bits et lorsque son successeur 32 bits (le 68030) est apparu, il n'a pas été nécessaire de recompiler quoi que ce soit pour faire tourner le code en 32 bits. Idem pour les processeurs PPC, initialement en 32 bits. Pas de recompilation pour faire tourner un code en 64 bits sur un G5 ! Le choix d'Intel par Apple est évidemment un choix économique, on l'a compris. Mais tout de même quel dommage !

Pages

CONNEXION UTILISATEUR