32 bits ou 64 bits

Version imprimable

06/12/2013, 14h01
r0d

32 bits ou 64 bits

Bonjour,

pour beaucoup, l'avènement du 64 bits, avec donc des processeurs 64 bits et des compilateurs/interpréteurs qui les gèrent, est une petite révolution dans le monde du développement logiciel.

Pour d'autres, ce n'est qu'un effet d'annonce et seulement 0.01% des logiciels auraient un avantage à exploiter le 64 bits, et parmi ces 0.01%, seul 1% le font.

Dans cette histoire, nous avons maintenant un peu de recul. Certains d'entre nous peuvent donc avoir des expériences significatives.

Moi par exemple, mes employeurs et mes clients me demandent impérativement du 64 bits alors que clairement, sur le type d'application que je développe, ça ne sert à rien. Du coup, nous rencontrons régulièrement des problèmes car, même si la tendance est clairement à la baisse, il existe encore de nombreux ordinateurs qui tournent en 32 bits, et une application compilée en 64 bits ne fonctionne pas sur un système 32 bits.

D'un autre côté, étant donné que le 64 bits permet d'adresser de plus grandes tailles en mémoire, il y a au moins une application que j'utilise régulièrement qui profite clairement du 64 bits: minecraft.

:arrow: Quels sont les avantages concrets du 64 bit sur le 32 bits?

:arrow: Puisque les applications 32 bits fonctionnent sur les OS 64 bits, et pas l'inverse, ne vaudrait-il pas mieux continuer à compiler en 32 bits?
06/12/2013, 14h43
sevyc64

Citation:

Envoyé par r0d

Pour d'autres, ce n'est qu'un effet d'annonce et seulement 0.01% des logiciels auraient un avantage à exploiter le 64 bits, et parmi ces 0.01%, seul 1% le font.

Il en va de même pour le 32 bits. La totalité des logiciels actuels, tout au moins sous Windows, sont en 32 bits et pourtant plus de la moitié n'en retire aucun intérêt particulier et pourrait se contenter de 16 bits (voire même 8 pour certains)

Citation:

Envoyé par r0d

D'un autre côté, étant donné que le 64 bits permet d'adresser de plus grandes tailles en mémoire, il y a au moins une application que j'utilise régulièrement qui profite clairement du 64 bits: minecraft.

:arrow: Quels sont les avantages concrets du 64 bit sur le 32 bits?

La notion de quantité mémoire est effectivement le principal avantage. L'autre principal est aussi des calculs plus simple et plus rapide sur des nombres de très grande taille, mais ça ne concerne pas la majorité des logiciels.
Et comme tu le dis, peu de logiciels n'en retire un avantage car peu de logiciels sont conçu spécifiquement pour du 64 bits. Au pire ils sont en 32 bits pour des raisons de compatibilité, au mieux ils existent dans les 2 versions, mais à partir du même code source compilé sur les 2 plateformes.

Citation:

Envoyé par r0d

:arrow: Puisque les applications 32 bits fonctionnent sur les OS 64 bits, et pas l'inverse, ne vaudrait-il pas mieux continuer à compiler en 32 bits?

A ce moment là, il n'y a aucun intérêt à avoir des OS 64 bits (et les machines qui vont avec).
Il faut savoir que sous Windows 64 bits, les applications 32 bits ne fonctionnent pas en natif mais sont virtualisées (comme s'il existait une seconde machine 32 bits sur la 64 bits).
C'est très peu sensible sur la majorité des logiciels dans une utilisation normale, mais peut se mesurer sur des logiciels nécessitant de grosses ressources mémoire et processeur, en fait ça introduit un petit supplément de temps de traitements (un exemple parmi d'autre, de la CAO 3D). Donc sur certains logiciels lourds, ils seront moins performant en 32 bits sur un os 64 bits, qu'en 32 bits sur un os 32 bits (et seront bien souvent largement plus performant en 64 bits sur un os 64 bits car pour ce genre de logiciel lorsqu'une version 64 bits existe, elle est généralement optimisée).
07/12/2013, 12h47
souviron34

Citation:

Envoyé par r0d

:arrow: Quels sont les avantages concrets du 64 bit sur le 32 bits?

Concrétement, le seul avantage - par nature - est la valeur maximale possible d'un entier, et par conséquent le nombre de possibilités d'indices dans un tableau ou d'adresses mémoires.

32 bits (Wiki)

Citation:

A 32-bit register can store 2^32 different values. The signed range of integer values that can be stored in 32 bits is -2147483648 through 2147483647 (unsigned: 0 through 4,294,967,295). Hence, a processor with 32-bit memory addresses can directly access 4 GiB of byte-addressable memory.

Avec des nombres réels, en double-précision (donc 64 bits effectifs), on atteint une limite de +/- 1.10^308 (à un chouia près)

En adressage, en entier donc, on peut avoir des tableaux de 1 GB éléments.

C'est en ça qe je dis souvent que le 64 bits est inutile dans l'écrasante majorité des cas, et le 32 (comme le dit sevyc) n'est réellement nécessaire que dans les gros prohrammes sceintifiques, et les traitements d'images en vraies couleurs (RGB chacun sur 8 bits, à traiter simultanément)

Alors maintenant, avec les recherches sur le Web, les énormes capacités disques ou mémoire, on veut pouvoir adresser ces espaces directement.

Mais dans le fond, j'y reviens, c'est le serpent qui se mord la queue. On fait des choses énormes, du coup on a besoin de 64 bits pour les adresser, mais les fonctionalités de la majeure partie des softs n'en a cure.

En dehors de l'adressage PHYSIQUE, le besoin APPLICATIF est pratiquement inexistant... sauf dans certains cas très particuliers..

**

Citation:

Envoyé par r0d

:arrow: Puisque les applications 32 bits fonctionnent sur les OS 64 bits, et pas l'inverse, ne vaudrait-il pas mieux continuer à compiler en 32 bits?

Comme le dit Servyc..

C'est une course sans fin.. Mais on pouvait penser que le 32-bits était un step suffisant (voir justement les images en vraies couleurs) pour être stable, et qu'avec les double ça suffisait largement même pour les besoins scientifiques sauf les plus extrêmes, qui, eux, requièrent de toutes façons des ordis dédiés (les NEC etc).

Là, si tu veux, c'est comme si tout le monde ne disposait et ne pouvait plus acheter que - une Ferrari.

Alors moi je veux bien mais c'est exactement ce que j'appelle la surconsommation... Totalement décorrélé du besoin réel, et bien évidemment appelant à renouveler le parc, qu'il soit matériel ou logiciel.. Bref, une fuite en avant pour refaire en permanence la même chose... purement mercantile à de très rares exceptions près...

** : et, j'y reviens, l'énormité des nombres possibles à ces nombres de bits, et la mauvaise compréhension des ordres de grandeur, préciisons, incertitudes, etc, font que de plus en plus d"informaticiens confondent nombre de bits et signification du chiffre ou nombre ou de ses décimales, se disent qu'il faut utoliser des "biblothèques de grands nombres", etc, et c'est déséspérant d'absurdité.......
11/12/2013, 19h54
wiztricks
Salut,

Citation:

Envoyé par r0d

:arrow: Quels sont les avantages concrets du 64 bit sur le 32 bits?

Il y en a plein cote "infrastructure" mais ils sont peu effectifs cote "dev".
Cote "infra", c'est quand même pas mal de pouvoir avoir 128GB ou + pour :
- des serveurs de base de donnees ou fichiers,
- les hyperviseurs (plein de VM),
- ....
Avec 8GB et 8 cœurs, on a un portable qui permet de tourner pas mal de VM aussi. Ce qui aide un peu les développeurs.

Pour les performances brutes d'une application X, il est vrai que ce n'est pas si simple:
- AMD64 a plus de registres: le code ira plus vite s'il fait des boucles assez petites avec un compilo qui sait en profiter.
- La quantité d'information qu'on fait passer sur les bus CPU <-> mémoire <-> IO est plus importante. Le débit sera un peu meilleurs mais il n'y aura de gains que pour les gourmands.
Citation:

Envoyé par r0d

:arrow: Puisque les applications 32 bits fonctionnent sur les OS 64 bits, et pas l'inverse, ne vaudrait-il pas mieux continuer à compiler en 32 bits?

L'application s'apuie aussi sur des DLL externes. Livrer les moutures 32 et 64 bits sera un effort one-shoot pour mettre en place "build" et "non-regression". Faire le mix & match des dépendances cote déploiement (chez le client qui utilisera d'autres applications) sera un effort récurrent.
Se faire pointer du doigt tous les trimestres par les équipes qui valident les évolution des stacks applicatives se traduira par des coups de grelots chez vos commerciaux qui mettront la pression sur les "dev"....

Citation:

Envoyé par souviron34

C'est en ça qe je dis souvent que le 64 bits est inutile dans l'écrasante majorité des cas, et le 32 (comme le dit sevyc) n'est réellement nécessaire que dans les gros prohrammes sceintifiques, et les traitements d'images en vraies couleurs (RGB chacun sur 8 bits, à traiter simultanément)

Les développeurs ne sont pas les seuls acteurs du "système d'information" - un nuage bien brumeux - a bénéficier (ou pas) des évolutions technologiques cote microprocesseurs.
Avoir du X86 partout est un avantage (avec tous les défauts de la mono-culture), comme a pu l’être la généralisation de TCP/IP cote réseau... On "standardise" les infrastructures... pas de gains évidents pour les performances de l'application X ou Y mais pleins d'avantages sur d'autres postes: plus de clients potentiels, moins d'environnements a tester,....

De toutes façons cote chips 64 bits est une façon comme une autre de profiter du budget "transistors" qui augmente avec la densité.
Comme c'est une question de "volumes" sortir une version 32 bit et/ou une version 64 bits sera plus coûteux que de tout fabriquer en 64 bits.

- W
13/12/2013, 11h53
souviron34

Citation:

Envoyé par wiztricks

Les développeurs ne sont pas les seuls acteurs du "système d'information" - un nuage bien brumeux - a bénéficier (ou pas) des évolutions technologiques cote microprocesseurs.

Très certainement...

Mais cependant je persiste à penser que la migration "forcée" est une absurdité de fond... Qui cache le plus souvent une incnompétence d'évaluation des problèmes et/ou besoins et/ou autres solutions..

Déjà r0d ne parlait pas de multi-coeurs mais de 32 ou 54 bits. Ensuite même pour le multi-coeur, la nécessité/utilité est (très.. voire beaucoup trop) souvent absolument pas évaluée... Les arguments que je vois/lis sont très nettement plus "ça va plus vite", ou "c'est ce qui se fait de mieux", au lieu de penser optimisation, réflexion sur le problème de fond, etc etc..

Je pense que ces usages proviennent très souvent d'une faiblesse de fond de l'analyse, de la compréhension interne des mécanismes, préciisons attendues ou significatives, , etc..
13/12/2013, 14h39
el_slapper

Le multi-coeur vient d'une autre problématique : on a atteint les limites de la loi de Moore. A défaut de pouvoir faire tourner des CPU à 25 GHz, on rajoute des coeurs. L'impact en termes de performances est bien plus limité, mais comme on a que ça... et ça a quand même des avantages. Quand j'ai mes macros EXCEL qui moulinent, je peux continuer à bosser sur autre chose.
13/12/2013, 20h55
wiztricks

Citation:

Envoyé par souviron34

Les arguments que je vois/lis sont très nettement plus "ça va plus vite", ou "c'est ce qui se fait de mieux", au lieu de penser optimisation, réflexion sur le problème de fond, etc etc..

Dans le cas particulier, nous sommes plutôt dans une logique de coûts/inconvénients de la standardisation comparée a la construction de solutions "sur mesure".
Dans la plupart des boites, vous avez un catalogue de serveur small, medium, large qui suffira pour répondre "assez bien" a 90%+ des besoins.
Les x% restants sont des configurations construites a la carte. Elles demanderont du temps et des expertises,... difficiles a justifier pour le choix de configurations "standards" qui, in fine, ne coûtent que quelques K.

La ou les "standards" ne s'appliquent pas et ou on fait encore gaffe calcule, c'est dans l'informatique industrielle ou embarquée. Essentiellement pour des économies d’énergies, pour s'adapter a la durée de vie des batteries.

C'est par pour rien qu'ARM équipe nos téléphones portables et qu'Intel rame pour se faire une place sur ce marche la. Et il y a d'autres chips encore plus "adaptes" qu'ARM.

Lorsque vous aurez des clients qui vous demanderont des binaires pour ARM, le coût de mise a jour de la chaîne de compilation pour construire les applis. sera bien plus important que pour simplement supporter 32/64 bits sur Intel.

Citation:

Envoyé par el_slapper

Le multi-coeur vient d'une autre problématique : on a atteint les limites de la loi de Moore. A défaut de pouvoir faire tourner des CPU à 25 GHz, on rajoute des coeurs.

La loi de Moore traite de l'augmentation de la densité des transistors.
Et donc le "budget" transistor par cm2.
Faire tourner un CPU a 25Ghz bute sur:
- l’énergie qu'il va falloir pour refroidir la bête,
- la possibilité d'alimenter le monstre i.e. de le charger et lui faire exécuter des instructions utiles.

Si on peut imaginer alimenter le monstre avec des blocks d'instructions qu'il triera, le faire travailler suppose augmenter la profondeur des pipelines. Cela complique les algorithmes de contrôle de l'ensemble avec deux effets:
- le contrôle bouffe une part significative du budget,
- le délai de propagation des signaux rend le contrôle "instable"

C'est ce qui rend plus raisonnable d'utiliser le budget transistor pour faire du multi-cores a un cadencement a 3-6Ghz avec une duree de vie raisonnable.
note: pour que ca ne chauffe pas trop on baisse le voltage, l'effet de bord est que le "chips" vieillit plus vite - les ions migrent mais la on est dans la physique quantique.

Le "multi-core" pousse au 64 bits: pour bosser efficacement, il faudra une certaine quantité de mémoire physique par CPU/Core.

Enfin tout cela est passablement complique, ce ne sont pas les journalistes qui pourront vous éclairer et les prises de positions "j'aime" / "j'aime pas" se comprennent mais sont un peu "short".
- W
05/02/2014, 01h41
ddoumeche

Citation:

Envoyé par sevyc64

Il en va de même pour le 32 bits. La totalité des logiciels actuels, tout au moins sous Windows, sont en 32 bits et pourtant plus de la moitié n'en retire aucun intérêt particulier et pourrait se contenter de 16 bits (voire même 8 pour certains)

Tout à fait mais les codes 16bits n'étaient pas réputés pour leur fiabilité, enfin la sous couche Windows 16 bits partageait sans doute certains tords dans cette histoire.

Citation:

Envoyé par sevyc64

La notion de quantité mémoire est effectivement le principal avantage. L'autre principal est aussi des calculs plus simple et plus rapide sur des nombres de très grande taille, mais ça ne concerne pas la majorité des logiciels.
Et comme tu le dis, peu de logiciels n'en retire un avantage car peu de logiciels sont conçu spécifiquement pour du 64 bits. Au pire ils sont en 32 bits pour des raisons de compatibilité, au mieux ils existent dans les 2 versions, mais à partir du même code source compilé sur les 2 plateformes.

Cela dépend du type de calcul, de l'implémentation des librairies, de multiples chose : SHA256 et le framework .Net sont nettement plus rapides en 64 bits, pour le reste des algorithmes le gain est moins net, voir on observe une dégradation des performances.

Le code 64 bits peut être ralenti parce que plus gros, encombrant le bus mémoire, et la mémoire cache : dans ce cas, le ralentissement peut être sensible
Voila pourquoi on a la compression des pointeurs en Java.

Citation:

Envoyé par sevyc64

A ce moment là, il n'y a aucun intérêt à avoir des OS 64 bits (et les machines qui vont avec).

Voyons. L’intérêt le plus évident des OS 64bits est d'adresser plus de 3.2Go de RAM.
06/12/2016, 12h08
sarnikoff

Parce que le partage est notre force, la connaissance sera notre victoire

Encore faudrait-il avoir la bonne connaissance !
Après avoir lu la pluspart de ces commentaires,
ces digressions, ces égarements ....
Je ne peux que rigoler.

Je n'ai rien lu de vraiment organisé !
Ex : Quand "on" parle de 32 ou 64 bits ... s'agit-il des données ou des adresses ?

J'ai donc l'impression, que depuis longtemps, "on" est plus dans le partage des taches, mais dans la division.

NB: Que se passait-il donc quand un processeur n'avait que 4 bits et pas de pile ?
06/12/2016, 18h32
sevyc64

Citation:

Envoyé par sarnikoff

Ex : Quand "on" parle de 32 ou 64 bits ... s'agit-il des données ou des adresses ?

On parle d'architecture de processeur et de son environnement, donc automatiquement d'adressage et de manipulation de données.

Citation:

Envoyé par sarnikoff

NB: Que se passait-il donc quand un processeur n'avait que 4 bits et pas de pile ?

Le code était adapté, optimisé, robuste. Mais il ne fonctionnait que spécifiquement sur ce processeur là. Tu changeais de processeur, tu étais obliger de reoptimiser le code, etc.
Mais ça permettait de faire entre-autres des sondes qui, 40 ans après, fonctionne toujours, sont sorties du système solaire et continuent leur vie tranquillement.
06/12/2016, 18h47
souviron34

Citation:

Envoyé par sarnikoff

NB: Que se passait-il donc quand un processeur n'avait que 4 bits et pas de pile ?

On mélangeait langage de haut niveau (Fortran, C,..) et assembleur, en connaissant intimement comment une machine marchait, et le principe de la fonctionnalité qu'on voulait...

J'ai fait des programmes de traitement d'images avec 64K de programme et 64K de data (3 lignes d'une image 512*512 + un switch de 10 commandes... Chaque commande dans un fichier séparé)

Et comme le dit sevyc64 robuste et qui marche plus que 1 an avant la nouvelle version :P

Un autre programme, un SIG, de 1996, marche toujours d'une machine avec 512 Mo de mémoire et 512 Mo de DD à ce qui se fait de mieux aujourd hui sans rien changer au prog sauf que la compil se fait en 3 secs et non en 10 min.. Mais bien entendu mon zoom panoramique me permet bien plus qu'avant.. Mais il tourne toujours sur mon portable de 1999 :P (et il est passé de 32 à 64 bits juste en changeant les flags de compil)

Donc avant de se fo:tre du manque de connaissances des autres, faut les avoir soi-même ;)

Mais je maintiens que 64 bits d'adressage est, dans l'écrasante majorité des cas, inutile, et que, en ce qui concerne la mémoire (en taille), beaucoup d'algos de ces dernières années se sont focalisés sur une complexité optimale en temps en négligeant la complexité spatiale, ce qui, justement à l'heure où maintenant on peut avoir besoin des 64 bits d'adressage, devient souvent prohibitf en terme de mémoire utilisée... (les arbres et arbres quaternaires en sont un des signes)
06/02/2017, 15h21
HAY

Citation:

Envoyé par r0d

:arrow: Puisque les applications 32 bits fonctionnent sur les OS 64 bits, et pas l'inverse, ne vaudrait-il pas mieux continuer à compiler en 32 bits?

Visiblement aujourd'hui tous les systèmes 64 bits (de chez Microsoft) permettent l'exécution d'applications 32 bits. Mais est-ce que l'on sait si cela va être le cas dans les prochaines versions ?
06/02/2017, 15h31
sevyc64

Citation:

Envoyé par HAY

Visiblement aujourd'hui tous les systèmes 64 bits (de chez Microsoft) permettent l'exécution d'applications 32 bits. Mais est-ce que l'on sait si cela va être le cas dans les prochaines versions ?

La question se pose effectivement.

La question s'est posée avec l'annonce de la sortie de Windows 10 ou des rumeurs disaient que le support du 32 bits n'existerait plus. Finalement W10 n'a rien changé.
Et comme W10 est censé être le dernier OS majeur, que désormais l'os se modifera par évolution continu, on peut supposer que le 32 bits sera encore supporté quelques temps.

Jusqu'à l'apparition du 128 bits ? Dans ce cas, on en a encore pour un bon nombre d'années.
07/02/2017, 17h18
HAY

Citation:

Envoyé par sevyc64

La question se pose effectivement.

La question s'est posée avec l'annonce de la sortie de Windows 10 ou des rumeurs disaient que le support du 32 bits n'existerait plus. Finalement W10 n'a rien changé.
Et comme W10 est censé être le dernier OS majeur, que désormais l'os se modifera par évolution continu, on peut supposer que le 32 bits sera encore supporté quelques temps.

Jusqu'à l'apparition du 128 bits ? Dans ce cas, on en a encore pour un bon nombre d'années.

Donc pour Windows Server on peut s'attendre à une fin assez proche du support du 32 bits ?
07/02/2017, 21h06
sevyc64

Précision : On parle bien ici de la famille de processeurs la plus courante à savoir i386 fonctionnant sous l'architecture x86 que ce soit en 32 bits (x86-32 couramment appelé x86), ou en 64 bits (x86-64 couramment appelée x64).

Citation:

Envoyé par HAY

Donc pour Windows Server on peut s'attendre à une fin assez proche du support du 32 bits ?

Je n'en sais rien, je ne me suis pas tenu au courant des dernières versions. Mais il me semble que la version 32bits n'est déjà plus distribuée. la version 64 bits est toujours, surement, compatible 32bits.

Si tu pense fin du 32 bits par l'avènement du 128 bits, rassure-toi, ce n'est pas pour demain. Le 64 bits, même sur les serveurs actuels, n'est pas encore pleinement exploité.
On en a encore pour quelques années à exploiter du 64bits, et probablement aussi du 32bits, tant que la plupart des logiciels sont encore compilé en 32bits.

Il existe peut-être quelques processeurs 128 bits (réels par virtuels) mais sur des machines bien spécifiques, et ils ne font surement pas tourner du Windows Serveur
08/02/2017, 00h23
dourouc05

Citation:

Envoyé par sevyc64

Si tu pense fin du 32 bits par l'avènement du 128 bits, rassure-toi, ce n'est pas pour demain. Le 64 bits, même sur les serveurs actuels, n'est pas encore pleinement exploité.

En effet. Quand on parle de la taille des adresses, un processeur haut de gamme récent (Xeon v4) n'utilise que 46 bits (c'est-à-dire au plus 1,5 To de RAM adressable, de mémoire). Exploiter les 64 bits, ça voudrait dire multiplier la quantité de mémoire par 2^18 (soit 262 144). Ce n'est effectivement pas pour demain — mais on disait la même chose pour le 16 bits, le 32 bits :aie:.