Les Google Pixel 7 et 7 Pro sont officiellement les premiers smartphones Android à ne supporter exclusivement que les applications 64 bits.
A quand le 128 Bits ARM et pourquoi pas les X86 Intel et AMD ?
Je sais que c’est inutile pour l’adressage mais çà devrait bien apporter un plus niveau performance. La preuve (à vérifier quand même 
) avec ces pixels qui font des promesses de gain en Ram et en performance.
Je me souviens des premiers AMD Athlon 64 qui étaient totalement inutiles sous Windows XP mais avec un OS 64 bits, il y avait un gain non négligeable. Et encore c’était les balbutiements.
On a eu un Motorola en x86 sous android
1 « J'aime »
Non, au contraire, ça dégraderait les performances. Tout comme le 64 bits dégrade les performances dans les applications qui n’en ont pas l’utilité.
Parce que manipuler des pointeurs deux fois plus long, ça implique des binaires plus volumineux, plus de transferts avec la RAM, etc…
Dans les faits, en x86 le 64 bits est plus rapide que le 32 bits, mais uniquement par effet de bord, pas directement à cause du 64 bits : l’archi AMD64 n’a pas apporté que le 64 bits, elle a aussi doublé le nombre de registres, ce qui permet de réduire les accès mémoire et de gagner en performances.
Du coup, dans le cas général, ça n’a aucun intérêt de passer à des processeurs 128 bits : ces processeurs seraient plus lent la plupart du temps et seulement plus rapides lorsqu’on doit faire des calculs sur des nombres de plus de 64 bits.
Et pour les cas où il faut manipuler des grands, il n’est en fait pas nécessaire d’avoir des CPU avec plus de bits : on peut ajouter aux CPU des instructions spécifiques pour le traitement des grands nombres. Ce qui se fait depuis longtemps. Par exemple, dès le 8086 (16 bits), Intel proposait une extension du x86, le x87, qui permettait des calculs flottants en 80 bits (64 bits de mantisse, 16 d’exposant), initialement sous forme de co-processeur, puis intégré au CPU à partir du 486DX. Ensuite il y a eu le MMX pour faire du 64 bits sur des entiers, le SSE2 qui a permis de le travailler sur des entiers 128 bits (SSE1 avait des registres 128 bits, mais ils servaient à stocker deux valeurs 64 bits, pas une seule de 128 bits), etc…
2 « J'aime »
Donc ça serait utile d’avoir du 128 bits natif au lieu de multiplier les jeux d’instructions spécifiques.
Comme AMD à l’époque, il faut multiplier le registre et ensuite créer le jeu d’instruction qui va bien.
Quid des calculs d’IA, et autres joyeusetés que l’on fait avec nos GPU car les CPU sont trop lents.
Un encodage vidéo en 128 bits par exemple.
Un rendu mathématique à la vitesse de l’éclair, un cryptage natif 128 bits de nos données.
Je n’y vois que des avantages au final.
S’il n’y avait vraiment aucun intérêt, on serait encore en 8 bits ou en 16 bits !!!???
Non. Puisque ça ralentirait l’exécution dans l’écrasante majorité des cas (tous les cas où on n’a pas besoin de plus de 64 bits) tout en n’étant pas fondamentalement plus rapide que des instructions spécifiques dans les cas où il y en a besoin.
C’est pas une question de plus de bits là, c’est une question de BEAUCOUP plus d’unités de calcul en parallèle.
En gros, un CPU est très bon pour faire des calculs diversifiés, parce qu’il a peu d’unités de calcul, mais qui sont totalement indépendantes les unes des autres, alors qu’un GPU est très bon pour faire strictement le même calcul sur plein de données en même temps, parce qu’il a énormément d’unités de calcul, mais liées entre elles.
Et il ne travaille pas sur des données plus grosses que celles d’un CPU, au contraire même : les unités « tensor » dédié à l’IA sur les RTX par exemple, c’est même pas du 32 bits, c’est du 16 bits (FP16, donc un entier 10 bits pour la mantisse, 5 bits pour l’exposant et 1 bit pour le signe). Et sur les shaders, c’est du 16/32 bits et les performances des GPU s’écroulent littéralement en 64 bits : une RTX 4090 qui envoie du 70-80 TFLOPS en 16 ou 32 bits tombe à 1.1-1.2 TFLOPS en 64 bits…
En fait, pour du calcul 64 bits, un gros CPU est plus rapide que le meilleur des GPU : en FP64 un Rocket Lake fait 32 FLOPS par core et par cycle, donc sur un 8 cœurs à 5 GHz il arrive à 1.3 TFLOPS, 10% de mieux qu’une RTX4090. Par contre en FP32 il ne va « que » doubler, à 2.6 TFLOPS, et va alors se retrouver 60x plus lent qu’une RTX4090.
À quel moment tu as besoin de 128 bits dans un encodage vidéo ? Et pour l’encodage vidéo, il y a des circuits spécialisés, qui resteront bien plus efficaces qu’un CPU.
Et t’en fait souvent des « rendus mathématiques » ?
Tous les CPU modernes ont déjà une unité dédié au chiffrement, capable de faire du chiffrement avec des clés beaucoup plus grosses que 128 bits…
De plus, un chiffrement avec une clé de x bits n’implique pas nécessairement des calculs sur x bits pour le chiffrement… Par exemple en blowfish (très utilisé de nos jours pour du chiffrement, avec notamment GPG, ou pour du hashage, par exemple avec bcrypt), même si la clé peut faire jusqu’à 448 bits, le chiffrement ne travaille que sur des blocs de 64 bits.
Ben non, parce qu’avec des pointeurs 8 bits ou 16 bits on aurait des espaces d’adressage virtuel (ie la mémoire qu’un processus peut adresser, indépendamment de la quantité de mémoire physique) respectivement limités à 256 octets et 64 Kio… Et à des calculs entiers sur des nombres compris entre 0 et 65535 ou -32768 et 32767… Ça serait un chouilla limitant quand même 
En 32 bits, on atteint une plage d’entiers qui couvre le très gros des besoins (même sur un CPU 64 bits, beaucoup de programmes continuent à utiliser des int 32 bits, parce que ça suffit…) et l’espace d’adressage atteint 4 Gio (2 Gio en pratique sous Windows, la moitié haute étant réservée au noyau). C’est mieux, mais ça peut quand même encore être insuffisant pour des gros programmes.
En 64 bits, l’espace d’adressage virtuel théorique atteint 16 Eio (environ 16 millions de Tio). C’est plus que suffisant pour les besoins présents et à venir… Même si en pratique l’espace réel est moindre parce qu’on utilise une partie des bits du pointeur pour autre chose que l’adresse, on n’a vraiment pas besoin de plus, ni aujourd’hui, ni demain.
Cette augmentation de l’espace d’adressage est la principale motivation du passage du 32 au 64 bits, si ce n’est la seule d’ailleurs… En dehors de ça, et sans les registres supplémentaires (qui auraient aussi pu être ajoutés en restant en 32 bits, c’est totalement indépendant), le passage au 64 bits fait globalement perdre en performances.
C’est d’ailleurs aussi pour ça que les mobiles sont passés au 64 bits bien plus tard que les PC. Le besoin d’un espace d’adressage plus grand y est arrivé beaucoup plus tardivement… Si un CPU 64 bits était globalement plus efficace qu’un CPU 32 bits, ils n’auraient pas attendu aussi longtemps pour passer à 64 bits.
3 « J'aime »
Oui, deux fois plus de registres, XMM plus large puis SSE et co etc.
Autre exemple sur les 8086/88 : on pouvait faire des additions 32 bits en utilisant un add (sur les 16 bits bas) suivi d’un adc (sur les bits hauts), ce dernier portant la retenue si présente.
Non, ces calculs se font au contraire sur des nombres les plus petits possibles (Float16, et maintenant souvent int8) afin de stocker plus de poids des connexions dans moins de mémoire. Et un CPU ne permet pas d’exécuter un nombre de calcul suffisant, ils sont très loin de la puissance de calcul des GPUs et de leurs unités de shader.
Pas vraiment intéressant, les channels de couleur étant sur 8 bits en général, rarement sur 10 bits. Les SSE et co sont bien plus intéressant ici, permettant de calculer plusieurs channels/plusieurs pixels en même temps. En très gros, ça revient bien à utiliser 128 bits ou plus (ce qui rejoint ton idée), mais séparés en un vecteur de registres calculés en même temps.
Et les GPUs restent un meilleur choix 
1 « J'aime »
Alors çà c’est marrant. Tous les programmes « optimisés » 64 bits sont plus rapide que ceux 32 bits.
L’utilisation de registres plus grand a toujours été bénéfique. Les SSE…AVX512 en sont l’exemple parfait.
Plus le registre est grand et plus çà va vite. Regarde les benchs d’utilisation des registres jusqu’à AVX512.
Donc forcément, un système 128 bits ira plus vite qu’un système 64 bits. CQFD
Tous les jours. Mes calculs excel sont fait de mathématiques.
Tous les programmes informatiques sont fait de calculs plus ou moins compliqués
Compression/décompression MP3, algorithme Zip/Rar, etc…
Même la suite office 64 bits est plus rapide qu’en 32 bits. Elle le serait encore plus en 128 bits.
Evidemment, le programme est naturellement optimisé pour travailler avec un registre limité à 64 bits donc il découpe chaque séquence en multiple de 64 et travaille ainsi.
S’il pouvait découper en 128, il irait plus vite à traiter les données puisqu’il y aurait des opérations en moins à faire et un traitement hautement parallélisé ensuite (la multiplication des coeurs)
Et non, tout faux. C’est juste que plus le registre est grand et plus il est complexe de faire un processeur. C’est vrai que l’on n’a pas besoin d’adressage supplémentaires pour l’instant. On est assez loin de saturer ce qu’on peut faire avec du 64 bits.
Mais en terme d’efficacité énergétique, de rapidité d’exécution des données complexes, un plus grand registre a toujours aidé.
Décortique le jeu d’instruction AVX512 => c’est découper en 8 une séquence de 512 bits à traiter.
C’est à dire, faire travailler 8 coeurs (physiques ou logiques) avec chacun un morceau de 64 bits.
Oh pinaise (comme dirait Homer Simpson) : 8x64 = 512
Cà tombe plutôt bien non.
On tombe dans la multiplication des coeurs pour être encore plus efficient et rapide. Les registres sont de plus en plus adaptés pour permettre de ne travailler que sur des moitié, quart ou huitième de registre 64 bits.
Mais il y a aussi des jeu d’instruction pour faire l’inverse : découper les informations à traiter pour que chaque processeur s’occupe d’une partie du problème à résoudre.
C’est magnifique.
Rien à voir avec les couleurs en 8 ou 10 bits.
Analyse un programme d’encodage vidéo ou juste un compresseur type H265.
Tu verras si tu comprend le code pourquoi un registre plus grand est bénéfique pour les performances.
Mais oui, actuellement çà ne sert qu’à découper une instruction en fragments pour traiter chaque fragment en parallèle et recomposer ensuite le résultat.
64 bits x 8 processeurs (logique ou physique) = 512
Un bon registre 512 traité en unité de 64.
Sans compter sur l’optimisation de l’AVX-512 qui n’est pas réellement linéaire mais contient un découpage hétérogène de registre virtuel (voir wikipedia par exemple)
Tu confonds tout…
- quand on parle de processeur 8/16/32/64/… bits, on parle de la taille des registres entiers (ax, bx…) et des instructions les traitant (et aussi en général de leur largeur d’adressage mémoire, mais il y a des exceptions). Pas des floats, doubles ou registres vectorisés.
- les floats double (64 bits) ont été supportés avant d’avoir des CPUs 64 bits.
- les registres vectorisés SSE et AVX auraient très bien pu être ajoutés à un CPU 32 bits.
Exemple, le Pentium MMX était bien un CPU 32 bits alors qu’il avait des registres MMX 128 bits. Wiki CpuWorld.
Et c’est bien ce que l’on t’expliquait : l’accélération au passage à des CPUs 64 bits étaient due aux registres additionnels et aux instructions vectorielles, et plus de cache, pas au fait d’avoir des registres génériques 64 bits et des pointeurs mémoire plus large.
Oui. Mais dans la plupart des cas, pas grâce au passage à 64 bits. Ils le sont grâce au doublement du nombre de registres en passant de x86-32 à x86-64 ou de ARMv7 à ARMv8.
Et c’est pas un hasard si ces deux architectures ont toutes les deux doublé le nombre de registres en passant du 32 au 64 bits : c’est tout simplement pour compenser la perte de performances du au doublement de la taille des pointeurs…
Parce que doubler la taille des pointeurs, ça implique que, pour une même tâche, tu fais plus d’échanges de données entre la mémoire et le CPU. Or les accès mémoire, c’est LE point faible d’un CPU, c’est le moment où il perd énormément de temps à attendre que les données arrivent.
Donc pour compenser le fait qu’on augmente les accès d’un côté, on augmente le nombre de registres de l’autre côté pour réduire la fréquence des accès.
L’utilisation de registres plus grand est bénéfique UNIQUEMENT quand on travaille sur des nombres plus grand que la taille initiale. Si tu travailles sur des entiers de 32 bits, avoir des registres de 64 bits n’apporte strictement aucun gain de performances (en fait, en pratique, même sur un CPU 64 bits, quand tu travailles sur des entiers 32 bits, tu continues à le faire avec des registres 32 bits… sinon c’est même un peu plus lent, non pas parce que le calcul est plus long, mais parce que tu dois du coup gérer à la main les éventuels overflow).
Ils sont justement l’exemple parfait qu’il n’est pas utile de tout passer en 128 bits ou plus : on utilise les instructions SSE ou AVX là où elles sont utiles, et on obtient un gain de performances là où plus de 64 bits sont utiles…
Les benchs d’AVX512 se font uniquement sur des cas particuliers qui tirent bénéfice d’AVX512. Ça ne se fait pas sur des applications qui sont entièrement en 512 bits, applications qui seraient beaucoup plus lentes que des applications 64 bits avec juste quelques portions en 512 bits.
De plus l’AVX-512 ne s’utilise le plus souvent pas comme un moyen de faire des calculs 512 bits, mais plutôt comme un moyen de faire plusieurs calculs 32 ou 64 bits identiques en parallèle. Va voir la liste des instructions AVX-512, tu verras que la plupart sont des instructions vectorielles (c’est d’ailleurs dans le nom du jeu d’instructions). Je suis pas sûr qu’il y ait dans AVX-512 une instruction pour faire par exemple une simple addition ou multiplication 512 bits.
EDIT : après vérification, je confirme AVX ne travaille que sur des opérandes de 64 bits maximum, à part sur quelques instructions de logique binaire basiques (il peut faire par exemple un AND bit à bit sur 512 bits). Sans doute qu’Intel a jugé inutile d’implémenter des opérations arithmétiques sur plus que les 256 bits permis par le SSE… Sans doute à raison, car les cas où il y a besoin d’une telle précision sont anecdotiques, surtout chez les grand public…
D’ailleurs, même les 64 bits, en pratique ils ne sont que rarement nécessaire, au point que quand AMD à défini l’AMD64, il a choisi de conserver 32 bits comme taille d’opérande par défaut. Seules les pointeurs sont passés à 64 bits par défaut.
Excel ne gère ni les entiers sur plus de 64 bits ni les flottants sur plus de 64 bits. Donc si tu peux te contenter d’Excel pour tes « rendus mathématiques », tu n’auras strictement aucun gain en passant à du 128 bits.
En fait sur les entiers la précision d’Excel n’est même pas de 64 bits mais d’à peine une cinquantaine (sans doute parce qu’il stocke même les entiers sous forme de float). C’est facile à vérifier, tu te fait une série avec les puissances de 2 en partant de 2 en A1 puis en copiant dans toutes les cellules d’en dessous une formule qui fait x2 par rapport à la cellule d’au-dessus, et tu verras qu’à partir de la ligne 50 le calcul n’est plus juste (à la ligne 49, on a un nombre se terminant par 2, le doubler doit donc donner un nombre se terminant par 4, Excel donne un nombre se terminant par 0).
Donc si dans ton travail la « faible » précision d’Excel n’est pas un problème, tu n’aurais strictement RIEN à gagner à avoir un Excel 128 bits : un Excel 128 bits ne serait pas plus rapide, il serait juste plus précis. Ce dont tu n’as visiblement pas besoin, sinon tu utiliserais déjà autre chose qu’Excel.
Calcul compliqué != calcul nécessitant plus de 64 bits de précision
Grâce aux registres supplémentaires. Pas grâce aux 64 bits.
Lol. Non, rien à voir… Blowfish est un algorithme qui a été écrit au début des années 90, il n’y avait pas de CPU 64 bits à l’époque, donc non, il n’a pas été optimisé pour des registres de 64 bits…
Tu dis n’importe quoi… Une instruction s’exécute toujours sur un seul cœur à la fois, chaque cœur de CPU a son propre pipeline d’instructions et à aucun moment une instruction traitée par un cœur ne va aller squatter le pipeline des autres cœurs…
Oui, une instruction AVX-512 est découpée en plusieurs… Mais parce que c’est justement le besoin auquel elle répond : elle est pas là pour faire des calculs sur des opérandes 512 bits mais pour faire un même calcul sur plusieurs opérandes plus petites. Parce que c’est en fait un usage bien plus courant que de calculer sur 512 bits…
Et non, ces plusieurs morceaux ne sont pas exécutés sur plusieurs cœurs, ils vont s’exécuter en parallèle sur le même cœur : aujourd’hui, un cœur n’a plus une seule ALU et une seule FPU, chaque cœur a plusieurs ALU et plusieurs FPU et peut donc traiter plusieurs opérations en simultané (par exemple un cœur Rocket Lake peut faire l’équivalent de jusqu’à 32 opérations sur des FP64 en un seul cycle et sur chaque cœur).
1 « J'aime »
Pour compléter, voilà un papier sur le sujet de l’impact du 64 bits sur les performances : Performance Characterization of the 64-bit x86 Architecture from Compiler Optimizations’ Perspective | SpringerLink
Les conclusions de ces tests, c’est que si on se limite à l’impact du 64 bits, en empêchant l’utilisation des nouveaux registres, le fait de doubler la taille des pointeurs fait perdre 2% de performances en moyenne sur les tests de SPEC2000, avec jusqu’à 20% de perte sur certains tests.
Par contre, utiliser les registres supplémentaires donne un gain de 13%.
Ce n’est donc pas le passage à 64 bits qui fait le gain de performances, mais bien le fait d’avoir plus de registres.
Étude réalisée par deux chercheurs de chez Intel, donc des gens qui savent un minimum de quoi ils parlent…
C’est bien ça, un processeur 128 bits aurait aussi des registres additionnels, plus de cache et des pointeurs plus large.
Exactement, donc un processeur 128 bits aurait les mêmes faiblesses et les mêmes forces
On double encore les registres et au final ça moulinera encore plus vite.
C’est mathématique, tu en fais même la démonstration entre 32 et 64 bits
Et pourtant on programme encore sur INT8, FLOAT16 ou en 32 bits alors que nos processeurs sobt 64 bits.
Pas de problème à ma connaissance.
C’est exactement ce que je disais. On découpe pour paralleliser entre plusieurs Thread pour « gaver » nos CPU multi-coeurs.
Je ne sais pas comment ça mouline en interne.
Juste que mes calculs sont plus rapides dans la version 64 bits, qu’il y a plus de colonnes et plus de lignes possible pour mes tableurs croisés dynamiques.
Ça va de paire, on ne peux pas avoir l’un sans l’autre. C’est toi qui l’a dit et je suis d’accord.
C’est déjà ce qui a été fait entre 8, 16, 32 et 64 bits
Je ne comprends pas pourquoi on a inventé des CPU à 12 coeurs logiques et 24 Thread si c’est pas pour donner à manger à chacun !?
Dans les faits, les logiciels ou le driver ou l’OS découpe bien quelque chose puisque mes algorithmes AVX-512 d’encodage vidéo sont utilisés par les 24 coeurs de mon CPU. Aurais-je mal interprété ce que je vois dans le gestionnaire des tâches.
Le même rendu CPU prend 20 fois plus de temps si je force le rendu sur un seul coeur qui certes tourne plus vite mais galère à traiter toutes les informations.
Et à la fin, j’ai bien un résultat donc les données sont bien recompilées par quelque chose.
Ça on le savait déjà
Les pointeurs plus larges, oui, par définition (la taille des pointeurs étant le point communément admis comme définissant le nombre de bits d’un CPU). C’est tout.
Le reste n’est absolument pas lié au nombre de bits. On peut ajouter du cache et ajouter des registres sans augmenter le nombre de bits… De fait, les processeurs x86-64 actuels ont plus de registres et souvent plus de cache que les x86-64 de première génération, pourtant c’est resté du 64 bits… Et inversement, on peut augmenter le nombre de bits sans augmenter le cache et le nombre de registres.
Oui, justement, on travaille sur des types plus petits pour minimiser autant que possible l’empreinte mémoire et donc les volumes échangés avec la mémoire.
Mais il y a un élément sur lequel on ne peut pas travailler avec une taille plus petite que celle prévue par l’architecture : les pointeurs.
Or passer les pointeurs en 128 bits, c’est inutile (de notre vivant, on n’aura JAMAIS besoin de gérer un espace d’adresse aussi grand) et c’est délétère pour les performances (on double l’empreinte mémoire de tous les pointeurs).
Et quand je dit jamais, c’est vraiment jamais : l’espace mémoire virtuel 64 bits, c’est 17 milliards de Go ! Et le « de notre vivant » n’est qu’une précaution, je pense que même au delà, le grand public n’aura jamais besoin d’une telle capacité mémoire… Capacité que de toute façon la physique rendra compliquée à avoir : même à raison d’un pouvait se contenter seul transistor par bit de mémoire, une puce mémoire de 2^64 octets serait composée de 147 milliards de milliards de transistors, ce qui, avec les records de densités actuels (atteints en labo, pas encore en production de masse) donnerait une puce de 443 milliards de mm², soit 443m²…
Même si on parvenait à continuer à doubler la densité tous les 18 mois, ce qui n’arrivera sans doute pas vu les limites physiques qui arrivent, il faudrait 30 ans pour caser ça dans une puce mémoire.
Non, tu mélanges tout. Les threads sont des flux d’instructions indépendants. Une instruction AVX-512, même si elle fait plusieurs calculs en parallèle, elle est dans UN thread à la fois.
Tes calculs sont plus rapides sur la version 64 bits parce que justement Excel travaille avec des float 64 bits. Donc forcément sur un CPU 32 bits, c’était plus lent. Sur un CPU 128 bits, ça ne sera pas plus rapide par contre. Ça sera au mieux très légèrement plus lent, avec une précision accrue (mais tu n’as PAS besoin de cette précision, sinon tu n’utiliserais déjà plus Excel), au pire plus lent avec une précision accrue, et, le plus vraisemblablement, très légèrement plus lent avec la même précision parce que Microsoft resterait en FP64…
Quand au fait qu’il y a plus de lignes de colonnes possibles, c’est grâce au plus grand espace mémoire. Passer en 128 bits n’améliorerait rien à ce niveau, puisque pour l’instant Excel est très loin des limites mémoire du 64 bits.
Non, je n’ai jamais dit qu’on ne peut pas avoir l’un sans l’autre. Le nombre de registres est totalement indépendant du nombre de bits de l’architecture.
Ça va souvent ensemble parce que ajouter des registres est un changement important, qui se fait souvent à l’occasion d’une refonte importante de l’architecture. Mais c’est tout de même indépendant, et dans l’histoire du x86 par exemple on trouve des changements de taille sans changement du nombre de registres (pas d’ajout de registres lors du passage de 16 à 32 bits) et inversement des ajouts de registres sans changement de taille (avec le x87, avec le MMX, avec le SSE, etc…).
Et si demain Intel ou AMD a envie d’ajouter 50 ou 100 registres supplémentaires, il peut le faire. Tout en restant en 64 bits.
Pour exécuter plusieurs threads. Mais au sein d’un thread, chaque instruction s’exécute uniquement sur un seul et même cœur logique.
Oui, les développeurs des logiciels les écrivent de telle sorte que les tâches qu’effectue le logiciel soient découpées en sous-tâches qui vont être affectées chacune à un CPU logique différents.
Mais ce découpage se fait au niveau du flux d’instructions, en envoyant un flux d’instructions (c’est ça un thread) à chaque CPU logique, le découpage ne s’effectue pas au niveau des instructions elles mêmes, qui sont intégralement traitées par le cœur logique qui les a reçues.
Si tu envoies un flux d’instructions AVX-512 qui chacune un traitement en parallèle sur 8 FP64, ça va occuper un seul cœur logique de ton CPU, pas 8. Si tu veux en occuper 8, il faut envoyer 24 flux d’instructions.
C’est pourtant ce que tu nies depuis le début en prétendant que passer à 128 bits ferait gagner en performances…
Cet article montre l’exact inverse : augmenter le nombre de bits fait perdre en performances. Les gains qui sont observés en pratique ne viennent pas de l’augmentation du nombre de bits, mais d’autres changements qui ont été fait en même temps sur la micro-architecture.
Non pas besoin d’un CPU 128 bits pour cela. On peut avoir plus de registres et/ou des registres vectoriels plus larges sur un CPU 64 bits.
Rien à voir avec un passage 32 à 64 ou 64 à 128 bits.
Heu non, il démontre au contraire que le speed-up ne vient pas du tout du passage au 64 ou 128 bits…
Non pas des threads, les MMX SSE et co n’ont rien à voir avec avoir plus de coeurs exécutant plus de threads. C’est une approche plus similaire aux GPU. Et toujours rien à voir avec un CPU 64 ou 128 bits.
C’est juste parce que ton ordi a maintenant plus de mémoire… 
On va le savoir à force. Et pourtant c’est la base
Sans déconner, les processeurs évoluent au fil du temps. Mazette, ils sont fous ces fondeurs
Je met une pièce sur … les prochaines générations auront encore plus de registres, de cache que les générations actuelles. Alors parie tenue !!!
Argh, Zut, je suis plus tireur que pointeur. Cà fonctionne pas alors !
Et un téléphone avec 1To de mémoire de stockage, on en parle du grand public et des besoins !!!
Et en plus ces gens qui ont déjà payé un rein, toute leur moelle épinière et un poumon veulent pourvoir ajouter une carte micro SD en plus. C’est des malades ces gens…
Alors 17 Milliards de Go, bah c’est juste la norme d’après demain. Avec 72Ko de mémoire de stockage et 4 Ko de Ram, on a visité la lune il y a 50 ans.
Ma première clef USB faisait 8Mo en 2001 et la dernière actuellement fait 512Go et est rapide comme l’éclair.
En partant du postulat que sur 21 ans, la capacité de ma clef USB a été multiplié par 64000
En prenant ces valeurs, j’estime que les enfants de mes enfants de mes enfants seront tous mort avant de voir arriver les 17 milliards de Go mais çà va encore s’accélérer et ce sont nos habitudes qui créent le besoin et non l’inverse.
On se contente de quelque chose aujourd’hui mais demain tout peux changer.
P’têt bein que ouais, p’têt bein que non. Qui sait ?
Moi je sais que je ne sais pas car je ne cherche pas à savoir si le savoir de cette information m’est ou me sera utile maintenant, demain ou jamais.
A mon niveau, gestionnaire des tâches. Tous les coeurs sont à fond la caisse, l’encodage va vite et bien et c’est AVX-512 qui travaille derrière le codec d’encodage.
Le reste, aucune utilité
J’ai lu récemment que l’émulateur de la PS3 : RPCS3 utilisait massivement AVX-512 et que les performances avait fait un bon non négligeable et depuis çà utilise vachement mieux tous les coeurs. Coincidence ? Théorie du complot ? Mauvaise documentation d’Intel à ce sujet ?
Pourtant les développeurs ont l’air de connaitre
Kamoulox, j’ai gagné
??? oh très certainement ??? Rien compris et ne m’explique pas, j’exécute le logiciel et je constate le résultat. Entre les deux, c’est pour les NERDs. J’ai pas besoin de savoir ce qu’il s’y passe, comment et pourquoi.
C’est juste magique, çà occupe tous les coeurs, que tu en ai 2, 8, 24, ou plus, le découpage est automatique. C’est vachement bien fait quand même.
Je ne prétends rien, j’en suis certain. J’ai connu des gens qui m’ont tenu exactement le même discours quand on est passé de 32 à 64 bits lors de la sortie de Windows XP 64 bits.
Oui, çà sert à rien, au mieux on va perdre en performance, il faut tout recoder ou à minima recompiler, c’est ridicule, les gens n’ont pas besoin de çà… Et gnagnagna !!
Détend toi, ouvre les yeux lentement, regarde plus loin. Ne te laisse pas dicté une pensée unique stigmatisante de ce que tu connais ou pense connaitre.
Ne vois tu pas la lumière au bout du tunnel, cette magie toute puissance, cette chaleur !!!
Ahhhh, Ohhhh, Tada, magie… Oui et ??? ne me dis pas la suite, pas de spoiler
Bah non, même PC, même OS, test en 32 bits du logiciel et test du même logiciel mais 64 bits.
Oh bizarre, le logiciel 64 bits est plus rapide, plus performant, plus sécurisé, plus réactif.
On m’aurait menti alors.
Mais moi j’ai de moins en moins de mémoire par contre.
C’est cadeau. Dans quelques années, si je suis encore là, il y aura le même test entre 64 et 128 bits et on dira, mince pourquoi on l’a pas fait avant.
Bah non, pas magie : le Pentium MMX, 32-bits, avait bien des registres vectorisés MMX 64 bits. Les CPU 64 bits avec SSE et SSE2 ont des registres vectorisés 128 bits depuis le Pentium 4.
Oui clairement. Bon pas la peine de continuer, tu ne sais pas de quoi tu parles.
Le PC 64 bits a 8gb de ram (même s’il limite à 4gb dans la plupart des tests), celui sous 32 bits n’a que… 2^32 - la réserve du bios ~ environ 3,5gb d’accessible! Tu le fais exprès ou quoi?!? Et comme dit dans les commentaires, la plus grande différnece de perf est dans des benchs qui font des tests en 64 bits même sur le CPU 32 bits.
C’est pas moi qui prétendait que c’est lié hein, c’est toi… Alors tu peux faire le malin maintenant genre « c’est une évidence », mais ça se voit que tu fais juste une pirouette pour faire croire que tu le savais depuis le début…
Non, c’est l’inverse. La croissance des besoin pour le grand public diminue avec le temps. Regarde depuis combien de temps on a des machines avec 8 Go de RAM, qui sont toujours la norme aujourd’hui… Tiens, petit exemple avec les Mac (parce que c’est bien documenté et facile de retrouver l’évolution de leurs specs), voici l’évolution de la RAM sur la gamme de portables disponibles au 1er janvier :
- 1992 : 2-8 Mo
- 1993 : 2-24 Mo
- 1994 : 4-32 Mo
- 1995 : 4-36 Mo
- 1996 : 4-56 Mo → x2-x7 en 5 ans
- 1997 : 4-56 Mo
- 1998 : 32-160 Mo
- 1999 : 32-512 Mo
- 2000 : 64-512 Mo
- 2001 : 64 Mo-1 Go => x8-x18 en 5ans, x32-x128 en 10 ans
- 2002 : 128 Mo-1 Go
- 2003 : 256 Mo-1 Go
- 2004 : 256 Mo-2 Go
- 2005 : 256 Mo-2 Go
- 2006 : 512 Mo-2 Go => x8-x2 en 5 ans, x128-x36 en 10 ans
- 2007 : 512 Mo-4 Go
- 2008 : 1 Go-4 Go
- 2009 : 1 Go-8 Go
- 2010 : 2 Go-8 Go
- 2011 : 2 Go-16 Go → x4-x8 en 5 ans, x32-x16 en 10 ans
- 2012 : 2 Go-16 Go
- 2013 : 4 Go-16 Go
- 2014 : 4 Go-16 Go
- 2015 : 4 Go-16 Go
- 2016 : 8 Go-32 Go → x4-x2 en 5 ans, x16-x16 en 10 ans
… - 2020 : 8 Go-24 Go → x1-x0.75 en 5 ans, x16-x12 en 10 ans
… - 2022 : 8 Go-24 Go → x1-x1 en 5 ans, x4-x1.5 en 10 ans…
Et grosso modo, x4000 en 30 ans… Alors même si on continuait au même rythme sans tenir compte tu ralentissement de ces dernières années, les x17 milliards, c’est vraiment pas pour tout de suite…
On voit bien le coup d’arrêt sur les quantités de RAM depuis quelques années… Donc croire que la croissance des besoins va s’accélérer dans les années à venir, c’est vraiment aller à contre courant des faits…
Tout simplement parce que passé un certain stade, on n’a pas besoin de plus, parce que ça n’apporte plus rien : on n’a rien à stocker dans de tels volumes… On va pas s’amuser à faire des photos à 10 Gigapixel et à tout filmer en 1024K juste pour le plaisir de bouffer des ressources… Et même comme ça, on serait encore loin d’avoir des besoins de RAM en milliards de Go…
Pourtant plus haut tu avais bien l’air convaincu de savoir, y a que tfpsly et moi qui constations que tu ne savais pas de quoi tu parles…
Alors pourquoi t’être lancé dans une discussion technique sur l’intérêt d’un CPU 128 bits par rapport à un CPU 64 bits si tu n’y comprends rien et pire, n’a même pas envie d’essayer d’y comprendre quelque chose ?
J’avoue, là c’est très fort : reconnaitre à la fois que tu n’y comprends rien, mais que tu es certain de tes convictions, fallait l’oser…
N’oublie pas qu’on est sur des échelles exponentielles…
En 32 bits, la taille limite de l’espace d’adressage était de 4 Go seulement (et même 2/3 Go en pratique sous Windows avec les adresses réservées au noyau). Quelqu’un qui au milieu de la décennie 2000 ne comprenait pas que cette limite allait être problématique à court terme, alors que les capacités de disques durs dépassaient déjà largement ce chiffre (d’un facteur + de 100) et qu’on approchait du Go de RAM, c’est un âne.
Aujourd’hui, la situation n’a rien à voir : la limite de l’espace d’adressage 64 bits c’est 17 milliards de Go. Même sur les disques durs, on en est très loin hein… Cette fois l’âne n’est pas celui qui croit que cette limite ne va pas être problématique à court terme. C’est celui qui croit qu’elle va l’être.
D’ailleurs, on est tellement loin d’avoir besoin de 64 bits d’adresse qu’en réalité les CPU 64 bits actuels ne gèrent même pas réellement les adresse sur 64 bits, ni en physique, ni en virtuel : les pointeurs sont bien sur 64 bits, mais en fait les bits de poids le plus fort ne sont pas utilisés, les implémentations actuelles du x86-64 n’utilisent que 48 bits significatifs, et sous Windows c’est même limité à 44 (ce qui laisse respectivement de quoi adresser 256 To et 16 To, bien assez avant très longtemps…).
D’ailleurs, à ce sujet, et pour illustrer à quel point des pointeurs plus grands seraient inutiles et causeraient une perte de performances : même ces 16/20 bits inutiles dans les pointeurs, certains trouvent déjà que c’est trop et en profitent pour les détourner pour économiser ces quelques bits ailleurs et gagner ainsi en performances.
Un exemple, le moteur Javascript V8 de Google : les bits forts des pointeurs sont utilisés pour stocker des tags indiquant notamment le type de la valeur pointée, ainsi en un seul accès mémoire on a à la fois l’adresse et le type au lieu de faire deux accès… À noter que si ils font ça, c’est justement aussi parce qu’ils savent qu’il s’écoulera BEAUCOUP de temps avant que ces 16 bits deviennent utilisés pour le pointeur… Car le jour où ça arrivera, faudra qu’ils réécrivent tout.
Mais dans l’écrasante majorité des cas, ces gains n’ont RIEN à voir avec le fait que c’est du 64 bits. Encore une fois, ça vient d’autres facteurs, comme l’augmentation du nombre de registres. C’est rigolo, parce que juste au-dessus tu fais comme si tu savais que ça n’a rien à voir. Mais tu continues de faire comme si c’était lié…
En plus on peut voir dans son test qu’il y a visiblement des différences entre les machines qui peuvent expliquer une partie du résultat : clairement celle en 32 bits a un problème de refroidissement… Parce que le CPU qui prend 7°de plus au repos, c’est clairement pas normal… Et qui dit CPU qui chauffe plus dit CPU qui monte moins haut en fréquence…
Quand à l’écart de performances dans le bench de CPU-Z, c’est sans doute soit que le bench inclus des traitements sur des grands nombres, soit qu’il a une portion avec beaucoup d’accès mémoire, qui du coup bénéficie grandement des registres en plus. Dans les deux cas, ce n’est pas représentatif du cas général (on a rarement besoin de travailler sur des grands nombres, et c’est encore plus rare de dépasser les 64 bits).
Mais bon, si tu préfères croire le premier YouTubeur venu plutôt que des chercheurs de chez Intel…
Je t’assures que je ne savais pas mais tu l’as écris tellement de fois que je te crois.
Seulement 8Go !! Mon PC portable du boulot en a 32Go et celui de la maison 64Go depuis 3 ans.
Bon OK, j’en ai grand besoin pour mes bases de données et ma passion de post production et d’encodage
Tellement vrai. Si seulement les imbécilles de Smartphone à 1To avec capteur 108 mega pixel pour jouer à KIKALAPLUSGROSSE pouvait te lire.
Je te confirme que je n’y connais pas grand chose.
Je ne fais que répondre poliement à tous les messages. Et je réponds toujours.
A mon âge, on peut dire que je ne change jamais d’avis et que je suis un vieux C**