Journal x86_64 en général et sur Mdv en particulier

Posté par .
Tags : aucun
0
21
jan.
2008
Je viens de terminer une install de Mandriva2008 PowerPack sur un portable neuf - pas le mien mille fois hélas ;-) - et j'ai été fort surprise de voir :
1 - qu'il n'y avait qu'un seul DVD commun aux versions 32 et 64 bits (alors que dans les revues on trouve un DVD pour chaque architecture)
2 - qu'il ne soit pas proposé d'option permettant de choisir à l'installation une des 2 versions

Aussi dès que l'installation de base fut terminée l'une des toutes premières choses que je fis, fut de vérifier la nature des paquets installés.

Comme je m'en doutais le système d'installation a privilégié l'option x86_64. Mais pas uniquement... en effet les RPM i586 se retrouvent en nombre, comme le pluginFlash - normal je crois vu qu'il n'existe qu'en 32bits.

J'ai besoin de votre avis sur quelques points :
1/ Cette installation est elle réellement propre et normale ?
2/ Ne serait il pas plus sage d'envisager - comme il me semble avoir lu ici ou là - de refaire une installation intégralement en 32 bits (i586) ?
3/ Et dans ce cas comment s'y prendre avec le DVD officiel ?

Une autre chose m'intrigue - en fait cela provient de mon ignorance de Windows - il y a en plus de la partition Windows (disque C:) deux autres partitions (E: et F:) qui n'étaient pas visibles avant l'installation de Linux. Sur une DD de 160Go dont j'ai redimentionné la taille initialement dévolue à NTFS il y ainsi dans l'ordre d'entrée de Grub :
- /dev/sda1 (/mnt/win) de 118Mo en FAT
- /dev/sda2 (/mnt/win_c) qui se trouve être la partition NTFS de Windows
- /dev/sda4 (/mnt/win_2) de 3.3Go en FAT
- /dev/sda6 (/mnt/win_3) de 2.5 Go en FAT

La création de sda1, sda4 et sda6 ne sont pas de mon fait;
j'ai certes partitionné le DD afin d'avoir
- XP systeme et appli en NTFS (sda2)
- une partition réservée aux données sous Win en FAT (sda5)
- ainsi que celles résevées à Linux, swap comprise ( de sda7 à sda11)
mais pas plus !
Je suis à l'écoute de toute info qui éclairera ma lanterne.

L'autre point que je trouve surprenant c'est la dénomination /dev/sdax pour un disque IDE
  • # 32/64

    Posté par (page perso) . Évalué à 4.

    Les partitions FAT en plus ça ne serait pas des partitions permettant le réinstallation de Windows ? ça se fait beaucoup sur les laptops. Les constructeurs font ça pour ne pas avoir a donner un CD de réinstallation.

    Ensuite pour le débat 32/64 bits si ton laptop marche bien il n'y a pas de raison de vouloir tout réinstaller en 32 bits. Ce n'est que si tu constates des incompatibilités diverses et variées avec des softs que tu utilises qu'il faudra y penser.
    • [^] # Re: 32/64

      Posté par (page perso) . Évalué à 4.

      Pour les différentes partitions j'ai peut-être une explication :
      - C: partition de boot normal de windows
      - E: partition de 'Restauration système'
      - F: partition de Média Center (boot sur un windows minimal quand tu appui sur la touche 'DVD')

      Mon portable était à l'origine partitionné comme cela.
    • [^] # 32/64

      Posté par . Évalué à 2.

      merci à vous deux
  • # Option d'installation

    Posté par (page perso) . Évalué à 5.

    Le DVD choisit tout seul 32 ou 64 bits suivant ton processeur. Il y a une option au démarrage pour forcer l'installation en 32 ou 64 bits : http://wiki.mandriva.com/fr/Installer_Mandriva_Powerpack#D.C(...)

    En l'installant sur mon macbook j'avais aussi eu cette surprise. J'ai donc recommencé l'installation en 32 bits parce que le wifi ne machait pas sinon.

    Pour i586 et x86_64 proposés par le gestionnaire de paquet, je trouve aussi que c'est très déroutant. Un débutant à qui on a installé tout seul en 64 bits ne saura pas quel paquet choisir... surtout qu'on ne lui a pas demandé à l'installation quelle était son architecture. Il serait à mon avis plus judicieux de mettre 32 bits par défaut et laisser le choix 64 bits à ceux qui savent ce que c'est et assument leur choix :-)
    • [^] # Re: Option d'installation

      Posté par (page perso) . Évalué à 2.

      Un débutant prendra un des deux au hasard et ça marchera, où est le problème? Le libre laisse toujours beaucoup de choix à l'utilisateur...

      Exemple vécu, sur x86_64, TORCS ne fonctionnait pas en x86_64. Qu'à cela ne tienne, j'installe la version i586 et ça roule!

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Option d'installation

        Posté par (page perso) . Évalué à 5.

        Le choix, c'est bien quand on sait ce que ça signifie. Donner le choix i586 et x86_64 je trouve que ça devrait plus se donner à l'installation du système (là on peut, mais c'est en option, l'installeur ne demande pas en mode normal) qu'a l'installation de chaque paquet. Pour une distribution qui se tourne vers les débutants je trouve que c'est une drôle de façon de faire.

        Personnellement, sans être un expert linux, j'estime ne pas être trop débutant (j'ai commencé avec une Red Hat 5.1), mais je ne sais pas trop à quoi va ressembler mon système si je mélange au petit bonheur la chance des versions i586 et x86_64.
  • # A propos des disques vu comme /dev/sd*

    Posté par (page perso) . Évalué à 4.

    Ca va dépendre de ton chipset. En effet, les gars du kernel ont viré l'ancienne couche de gestion des disques IDE pour la remplacer par celle qui avait été écrite spécialement pour l'arrivé du SATA (libata remplace le support des disques de type ATA/ATAPI/MFM/RLL). Au final, ça fait moins de code à maintenir et du coup, il est plus testé, moins buggé et de meilleur qualité.

    Mais comme se sont également des gars pragmatique, ils ont laissé l'ancienne couche pour garder les vieux chipset supportés.
  • # Explications sur 64 bits

    Posté par . Évalué à 3.

    Est-ce que quelqu'un peut nous dire à quoi sert exactement le 64 bits ? Et si le mode PAE n'est-il pas suffisant ?
    • [^] # Re: Explications sur 64 bits

      Posté par . Évalué à 1.

      C'est une blague ?

      "La première sécurité est la liberté"

      • [^] # Re: Explications sur 64 bits

        Posté par . Évalué à 3.

        non c'est sérieux
        • [^] # Re: Explications sur 64 bits

          Posté par . Évalué à 5.

          Pour info :

          http://f-cpu.seul.org/~nico/amd64.html

          En résumé, l'archi x86_64 est en moyenne 20% plus rapide grâce au doublement des registres disponibles. Cela permet aussi d'utiliser plus de 2 à 4 Go par processus.

          Les bits PAE servaient pour des gros serveurs intel pour avoir jusqu'à 64 Go de RAM. Mais chaque processus ne pouvaient voir que 4 Go à la fois.

          "La première sécurité est la liberté"

          • [^] # Re: Explications sur 64 bits

            Posté par . Évalué à 5.

            D'après http://doc.ubuntu-fr.org/ubuntu_64bits, il semble que les performances 64bits ne soient pas transcendantes.

            D'après ce que moi j'ai compris du 64 bits, il ne sert que si l'on a plus de 4 Go de mémoire. Et encore, avec le mode PAE, on peut faire reconnaître à son système d'exploitation (n'importe lequel) plus de 4Go de mémoire. Sauf que une application ne pourra pas utiliser plus de 4Go (et encore, j'ai l'impression qu'il existe des bidouilles pour).

            Donc, si l'on a pas plus de 4Go de mémoire, et si l'on a pas d'application qui utilise plus de 4Go de mémoire, le 64bits n'est pas nécessaire.

            Il a eu des commentaires sur le 64 bits et la mémoire il n'y a pas longtemps, mais je ne retrouve pas.
            • [^] # Re: Explications sur 64 bits

              Posté par . Évalué à 1.

              Si tu lisais l'article tu en saurais plus niveau perf...

              "La première sécurité est la liberté"

              • [^] # Re: Explications sur 64 bits

                Posté par . Évalué à 2.

                J'ai bien compris que ton article disait que le 64bits est 20% plus rapide que le 32 bits.

                Par contre, tu fais des tests sur des applications spécifiques que l'utilisateur lambda n'utilise pas tous les jours (il n'y a que les utilisateurs avancés pour compiler leur kernel).

                Il y a deux choses intéressantes à savoir (du moins qui m'intéresse) :

                - dans l'utilisation de tous les jours (messagerie, traitement de texte et navigation), est-ce que le 64 bits est mieux ?

                - concrètement pourquoi le 64 bits serait-il plus rapide ?
                • [^] # Re: Explications sur 64 bits

                  Posté par . Évalué à 3.

                  Pour ton utilisation à toi, cela ne te concerna pas tous les jours. Je me suis concentré sur des tâches couteuses en temps cpu.

                  Dans le cadre bureautique, suffisamment de RAM et un disque dure rapide auront bien plus d'effets !

                  Par contre, ne me dis pas que tu n'utilises jamais de player video ou de compression mp3... La compilation est un des benchs sur un nombre assez important...

                  "La première sécurité est la liberté"

                  • [^] # Re: Explications sur 64 bits

                    Posté par . Évalué à 1.

                    Bah si je vais te le dire : je n'utilises pas de player video (sauf pour lire des vidéos de 15 secondes sur le net), et je ne compresse pas mes musiques en mp3.


                    Dans le cadre bureautique, suffisamment de RAM et un disque dure rapide auront bien plus d'effets !


                    Et dans le cadre d'un serveur ? (fichier, dns, ldap...)

                    Et quid de Windows XP 32/64 ?
                    • [^] # Re: Explications sur 64 bits

                      Posté par . Évalué à 6.

                      Et dans le cadre d'un serveur ? (fichier, dns, ldap...)

                      Vu que c'est un benchmark de desktop...


                      Et quid de Windows XP 32/64 ?

                      Sur Linuxfr, tu penses bien que l'on a un peu rien à foutre. Le seul truc qui est à peu prêt sûr, c'est que tu trouvera beaucoup de drivers ou du programme qui ne marche pas sous un windows 64 bits.

                      "La première sécurité est la liberté"

                      • [^] # Re: Explications sur 64 bits

                        Posté par . Évalué à -8.

                        si tu n'as rien à dire, ne dis rien !
                        • [^] # Re: Explications sur 64 bits

                          Posté par . Évalué à 1.

                          Vous pouvez toujours me moinsser, sauf que la discussion intéressante est en dessous, et pas au dessus !
                          • [^] # Re: Explications sur 64 bits

                            Posté par (page perso) . Évalué à 3.

                            bon ben un début de réponse alors

                            Sous windows, il peut être très très intéressant de passer au 64 bits _avant_ 4Go tout simplement parce que si tu colles 4Go dans un vista (je sais pas pour les autres) tu en vois ... 3.5Go ...

                            et là on dit merci microsoft !
                            • [^] # Re: Explications sur 64 bits

                              Posté par (page perso) . Évalué à 1.

                              C'est une limitation du x86 qui n'a aucun rapport avec Microsoft :


                              [ 0.000000] 3200MB HIGHMEM available.
                              [ 0.000000] 896MB LOWMEM available.



                              % free
                              total used free shared buffers cached
                              Mem: 3032 2443 588 0 50 1726
                              -/+ buffers/cache: 666 2366
                              • [^] # Re: Explications sur 64 bits

                                Posté par . Évalué à 2.

                                Et on a le même soucis avec Linux, qui doit laisser de l'adressage mémoire au noyau. Avant il y avait un split 1g/3go puis 2/2 puis 3/1 puis 3.5/0.5 il y a même eu un 4/4 avec un hack.

                                "La première sécurité est la liberté"

                • [^] # Re: Explications sur 64 bits

                  Posté par (page perso) . Évalué à 2.

                  Il m'arrive en ce moment d'encoder des dvds de séries en divx (pour usage perso) avec dvdrip, qui derrière bosse avec mplayer, lame, ffmpeg, etc. Opensuse 10.3.

                  Sur un Core2Duo à 2.66GHz, un rip en grande taille, redim HQ, une passe, en xvid+mp3 192kbits qui faisait 27-30 fps en 32 bits, fait 38-40 fps en 64 bits.

                  Alors certes tout le monde ne rippe pas de dvds, mais sur un montage video ou une transformation finale de dv vers dvd ou divx, c'est un gain de temps énorme. Je suppose que le traitement d'image se trouve aussi accéléré.

                  Pour le reste, pour la bureautique ou du web, la différence n'est pas visible. J'ai aussi testé pour m'amuser un superpi optimisé 64bits, je suis passé de 17 secondes à 11.

                  My 2 cents.
            • [^] # Re: Explications sur 64 bits

              Posté par (page perso) . Évalué à 5.

              PAE n'est qu'un vilain hack qui est décrié par beaucoup de monde.
              En ce qui concerne les x86_64 le gros avantage de l'archi c'est qu'on passe de 8 à 16 registres.
              • [^] # Re: Explications sur 64 bits

                Posté par . Évalué à 5.

                Un autre avantage est dus x86_64, c'est qu'on repart avec une nouvelle base commune du jeu d'instruction incluant SSE2.
                • [^] # Re: Explications sur 64 bits

                  Posté par (page perso) . Évalué à 3.

                  Exact, cela signifie que les logiciels compilés en x86_64 dans votre distribution viennent avec les optimisations MMX, SSE, 3DNOW et SSE2. En x86, les distributions compilent le plus souvent sans ces instructions afin d'être le plus compatible possible (Debian c'est i486, Mandriva c'est i586 par exemple).

                  ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: Explications sur 64 bits

      Posté par . Évalué à 2.

      Bon j'ai retrouvé le un fil intéressant sur le 64 bits : https://linuxfr.org//~IsNotGood/25908.html#892915

      Je cite notre cher ami IsNotGood
      Ben oui, il n'y a aucun raisons "évidentes" de passer à 64 bits. Je n'ai jamais dit le contraire.
      Le 64 bits se justifie si on a un gros besoin de mémoire (plus de 4 Go (ou 2 ?) par processus ou plus de 64 Go pour le système (i686 a le mode PAE)).


      Il faut noter que cette réflexion est pas dépendante du système d'exploitation vu que l'on parle au niveau hardware.

      Ma réflexion est : On nous parle tout le temps du 64 bits. On nous fait croire que le 64 bits c'est carrément mieux que le 32 bits. Est-ce vrai ? est-ce que ça vaut le coup de passer en 64 bits ?
      • [^] # Re: Explications sur 64 bits

        Posté par (page perso) . Évalué à 5.

        > On nous fait croire que le 64 bits c'est carrément mieux que le 32 bits.
        > Est-ce vrai ? est-ce que ça vaut le coup de passer en 64 bits ?

        Si tu te poses ces questions, la réponse est non. Passer en 64 bits est utile à ceux qui (au choix) :

        - Sont prêts à essayer un truc moins courant juste pour voir.
        - Sont intéressés par un gain de performance sur de longs calculs.
        - Ont assez d'espace RAM et disque dans leur machine pour ne pas être pénalisés pour une occupation mémoire supérieure.
        - N'ont pas peur de devoir se passer de logiciels propriétaires (ou bidouiller pour les utiliser).
        - Peuvent se passer de quelques logiciels ou pilotes non encore portés en x86_64. Ce dernier point ne peut cependant s'améliorer que si le nombre d'utilisateurs x86_64 est suffisant.

        ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Explications sur 64 bits

        Posté par . Évalué à 7.

        Moi, je partage ton point de vue depuis longtemps. Passer de 32 à 64 est très différent de passer de 16 à 32. Ce qu'il faut prendre en considération, c'est :

        - A prix égal et, surtout, si le système est compatible 32, cela ne vaut pas le coup de se priver. Ca permet de voir venir les nouveautés, et de se familiariser avec la programmation des nouveaux jeux d'instructions et la nouvelle architecture, ce qui est toujours très intéressant ...pour peu que l'on programme encore un minimum en assembleur ! Si c'est pour tout demander à gcc et faire de la compatibilité ascendente en nivelant par le bas, ça n'a aucun intérêt.

        - Un nouveau jeu d'instruction et surtout des registres supplémentaires permettent d'être très efficace. Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.

        - 64 bits, ça permet de dépasser 4 Go d'adressage direct et on en aura forcément besoin à terme. 512 Mo de RAM tend à devenir la norme et même les portables "conçus pour le jeu" chez Dell, par exemple, déjà sont livrés avec 2048 Mo.

        Maintenant, je ne suis pas sûr que ce soit une bonne chose en soi que laisser cet état de fait devenir la norme. Dépasser 4Go, ce n'est pas du tout la même chose que de dépasser 64Ko. Même en progressant, la consommation de RAM devrait croître de manière linéaire, pas exponentielle ! Pour la plupart des gens, ce ne sont que des chiffres, que se valent à différentes époques, à la manière des francs et euros constants.

        - Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique. Quand tu regardes des vidéos, certes (même si elles ne durent que 5 minutes, tu aspires quand même à ce qu'elles soient fluides dans l'intervalle, et qu'elles ne consomment pas trop de temps CPU, ni trop de bus), mais également quand tu travailles sous GIMP, ou même simplement lorsque tu déplaces une fenêtre ! Une fenêtre en 1280*768 et en 32 bits, mine de rien, ça fait beaucoup de mémoire ! Et comme, lorsque la résolution augmente, elle le fait dans les sens verticaux et horizontaux, cette quantité augmente au carré, encore une fois.

        Bref, à partir d'une certaine quantité de données, travailler en 64 bits peut soulager ton processeur et augmenter, même d'un point de vue uniquement théorique, la rapidité d'exécution d'un algorithme, et ce même en dessous de 4Go de RAM.

        important : Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits. Sinon, il y a conversion par des circuits externes et évidement, les perfs chutent.

        - Les "double" tiennent enfin, à nouveau, sur un seul registre. J'ai toujours considéré cela comme une faiblesse des formations en programmation. J'ai un float et un double. Le double a une mantisse beaucoup plus large pour le même prix. Alors, je choisis le double, au point que les nouveaux programmeurs ne savent même plus que float existe.

        Les tailles 32 et 64 bits des flottants sont ainsi parce qu'elles sont nomalisées, mais personne ne sait vraiment comment elles sont traitées en profondeur. Depuis qu'il y a un coprocesseur, les gens ne s'en soucient plus. Même les environnement de développement intégrés proposent des double par défaut. N'empêche que les accès bus et la mémoire consommée en demeurent effectivement doublés.

        A l'époque des 8 bits, on utilisait déjà les mêmes formats, et il fallait de toutes façons une boucle pour traiter l'un comme l'autre. Sur un 32 bits, un float tient dans un registre (tel que EAX), pas un double.

        Puisque le format de ces nombres est normalisé quelque soit l'architecture, on peut espérer des gains sur les programmes qui utilisent massivement le double. La plupart, pour ce que j'ai pu en voir.

        - Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.

        - Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.

        C'est inquiétant parce que la croissance exponentielle de la mémoire requise est due en grande partie aux dépendances entre les différentes couches d'abstraction. Si on continue à en ajouter, et si en plus les couches existantes consomment plus de mémoire sans même gagner une ligne de code, alors on va atteindre physiquement les limites de la mémoire adressable comme on a atteint celles de la finesse de la gravure, et ce avant même de passer aux 128 bits.




        Donc, faire des frais pour passer explicitement en 64 bits, ça ne sert à rien. Par contre, si c'est dans un plan prévu de remplacement de tes machines, ce n'est (presque) que des avantages.
        • [^] # Re: Explications sur 64 bits

          Posté par . Évalué à 3.

          Beaucoup de contre-vérités...

          Un registre supplémentaire, c'est autant d'accès bus en moins, et çà, ça fait une très grande différence sur un processeur de PC.

          Il n'y a pas d'accès bus externe puisque la pile locale reste presque toujours quelque part dans le cache L1. Je ne dis pas que l'amélioration est inexistante (un adressage de registre est toujours plus léger qu'un adressage indirect) mais c'est loin d'être "une très grande différence".

          Gros avantage, au niveau du traitement des blocs de données : Tu traites tes zones par blocs de 8 octets et plus 4 et donc à chaque fois que tu as une boucle, tu divises par deux l'overhead dû au traitement des invariants. Or, la copie de blocs de données est extrêmement fréquente en informatique.

          Faux, non seulement on pouvait déjà transférer des données sur 64 bits (en utilisant par exemple les registres MMX qui sont présents sur tous les CPU depuis dix ans), mais en plus les transferts mémoires sont limités par la bande passante externe du CPU, qui est minuscule par rapport à la puissance de traitement disponible au coeur du CPU.

          Tout ceci n'est réellement valable que si ton bus et ta mémoire sont eux-aussi en 64 bits

          C'est déjà le cas depuis le Pentium (depuis 1995 !).

          Les "double" tiennent enfin, à nouveau, sur un seul registre.

          Encore faux. Les "double" ont toujours tenu sur un seul registre, puisqu'ils ont toujours eu des registres dédiés au sein de l'unité de calcul à virgule flottante (en tout cas depuis que cette dernière existe, c'est-à-dire bien longtemps).

          Le double a une mantisse beaucoup plus large pour le même prix.

          Le même prix ? C'est vite dit. Il prend deux fois plus de place en mémoire, ce qui n'est pas très gênant certes, mais surtout les opérations effectuées sur les double sont plus lourdes que sur les float, ce qui fait que la plupart des CPU peuvent en exécuter moins par cycle.

          Le principal ennui, donc, en changeant d'architecture est que la taille des données d'un même programme double pratiquement, du simple fait d'être recompilé.

          Encore faux, seuls les pointeurs doublent de taille, les entiers selon les cas restent sur 32 bits (int) ou passent à 64 (long), quand aux flottants leur taille est inchangée comme expliqué plus haut.
          • [^] # Re: Explications sur 64 bits

            Posté par . Évalué à 1.

            Faux, non seulement on pouvait déjà transférer des données sur 64 bits (en utilisant par exemple les registres MMX qui sont présents sur tous les CPU depuis dix ans)
            Sans me prononcer sur la validité de ton message (qui me semble tout a fait correct au demeurant ;) , il me semble que les personnes plus haut on dis que le problème du x86 c'est justement que tu es limité pour la retro compatibilité, et que le x86_64 "disait" que tu étais mini en sse2", et donc que le compilo pouvait utiliser ce genre de registre
            non ?
            • [^] # Re: Explications sur 64 bits

              Posté par . Évalué à 2.

              Oui, il peut utiliser les registres xmm du SSE2. Mais les registres de la pile flottante ont toujours été sur 64 bits.

              "La première sécurité est la liberté"

          • [^] # Re: Explications sur 64 bits

            Posté par . Évalué à 2.

            C'est grosso-modo ce que j'explique au-dessus (mais je conçois que mon commentaire est un peu long et qu'on a envie de le lire en diagonale).

            Encore faux. Les "double" ont toujours tenu sur un seul registre, puisqu'ils ont toujours eu des registres dédiés au sein de l'unité de calcul à virgule flottante (en tout cas depuis que cette dernière existe, c'est-à-dire bien longtemps).


            C'est ce que j'explique au-dessus. C'est quelque chose dont on fait abstraction parce que l'on s'appuie sur le coprocesseur mathématique qui, lui, est effectivement en 64 bits depuis longtemps. Mais les données n'y passent pas leur vie.

            Le même prix ? C'est vite dit. Il prend deux fois plus de place en mémoire, ce qui n'est pas très gênant certes, mais surtout les opérations effectuées sur les double sont plus lourdes que sur les float, ce qui fait que la plupart des CPU peuvent en exécuter moins par cycle.


            Même chose.

            Encore faux, seuls les pointeurs doublent de taille, les entiers selon les cas restent sur 32 bits (int) ou passent à 64 (long),
            .

            Les long changent donc de format, les pointeurs aussi, et tout ce qui manipulé en interne à la compilation du code dans les registres. De toutes façons, ces formats de nombres concernent ici le langage C. Un changement d'architecture doit être examiné sur toutes les plateforme de développement.

            quand aux flottants leur taille est inchangée comme expliqué plus haut.


            Oui. Par moi. Relis bien.
        • [^] # Re: Explications sur 64 bits

          Posté par . Évalué à 2.

          - Enfin, 65535, c'est tout de suite atteint. 4 milliards beaucoup moins vite, mais ça reste courant. 2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.

          Tu sais les IBM 360 utilise des pointeurs 128 bits... Faut dire aussi qu'il mappe automatiquement les HD en mémoire.

          "La première sécurité est la liberté"

          • [^] # Re: Explications sur 64 bits

            Posté par . Évalué à 1.

            2^64, ça dépasse le nombre de galaxies (visible) contenues dans l'univers entier. Ca veut dire aussi qu'on ne pourra jamais adresser autant de mémoire même au niveau atomique.

            C'est moi ou il n'y a aucune relation entre le nombre de galaxie (visible) et le fait que tu puisse adresser de la mémoire au niveau atomique ?
            Si tu disais 10**120, j'aurais pu comprendre : c'est supérieur au nombre d'atome dans l'univers, mais là...
            • [^] # Re: Explications sur 64 bits

              Posté par . Évalué à 2.

              C'est un raccourci un peu rapide, je te le concède, mais il me semble 2^64 atomes est plus que ce tu peux mettre dans le boîtier d'un PC. Je me trompe peut-être ...
              • [^] # Re: Explications sur 64 bits

                Posté par . Évalué à 1.

                ben vu qu'aucun ordre de grandeur est donné, on ne peut pas savoir.
                Idem pour "il me semble que 2^64 ne rentre pas dans un boitier de pc". Et pourquoi pas ?
                pour m'amuser, je vais mettre des ordres de grandeurs :

                si je me rapelle bien mes cours de maths, savoir combien 2^64 fait en puissance de 10 c'est :
                log (2^64)/log(10)
                ce qui me donne (d'après maxima) ~ 19.266
                donc 10^20.
                C'est si énorme que ca 10^20 atomes ?

                Nombre de bactérie sur le corps humain : 10^15 ! ( http://en.wikipedia.org/wiki/Human_flora )
                Il est nécessaire et suffisant alors que chaque bactérie soit composé de 10^5 atomes et on atteint, rien qu'avec les bactéries dans un corps humain, la limite imposé!

                Et si je récupère mes souvenirs de physiques :
                Masse molaire du carbone =12g.
                Dans une mole de carbone, il y a N(nombre d'Avogadro) atomes de carbones.
                C'est à dire :
                N=6,0221415 × 10^23

                On a déja dépassé notre 10^20 d'au moins 2 ordres de grandeur
                • [^] # Re: Explications sur 64 bits

                  Posté par . Évalué à 3.

                  Pour compléter:

                  Un atome a un diamètre moyen de 0,1 nanomètre (10^-10 m).

                  Donc 10^20 atomes rentre dans un cube de racine cubique de 10^20, sois 4.7 * 10^6 atomes, sois un cube de moins de 1 mm de coté...

                  "La première sécurité est la liberté"

                • [^] # Re: Explications sur 64 bits

                  Posté par . Évalué à 3.

                  Ok, j'ai fait une erreur dans un ordre de grandeur, ce n'est pas bien grave en soi. C'était pour donner une idée de ma pensée dans un commentaire Linuxfr, par pour soutenir une thèse.

                  Ce que je voulais dire, c'est que si l'on suit une progression géométrique style loi de Moore, on va finir par rencontrer ce genre de souci dans un intervalle de temps comparable à celui qu'il a fallu pour passer de 16 à 32 bits, c'est-à-dire pas grand chose. Même avec mille atomes par bit de mémoire, ça reste compliqué à mettre en oeuvre.

                  Pour autant, ça ne remet pas en cause l'utilité d'une architecture 64 bits. On est même à 128 sur certaines machines (consoles de jeux, en particulier) parce que c'est pratique pour des utilisations ciblées et que celles-ci sont suffisamment rentables à elles seules pour justifier la conception de telles machines.

                  En ce qui concerne l'adressage proprement dit, 4 Go de mémoire sont déjà atteints et exploités depuis quelque temps. Rien que ça justifie le 64 bits. Par contre, en considérant 2^64 octets de mémoire, un facteur très limitant restera le temps qu'il faut pour y accéder.

                  Evidemment, on paralélisera, on fera des MMU plus puissantes, etc. M'enfin, j'espère que d'ici à ce que la limite soit atteinte, on sera passé à une autre architecture que celle d'un PC.
                  • [^] # Re: Explications sur 64 bits

                    Posté par . Évalué à 3.

                    De mémoire, l'accroissement des besoins mémoires des applications est de 0.8 bits par an. Cela ne double pas mais pas loin.

                    Si les besoins "maximum" sont aujourd'hui de 64Go (36 bits),on en a encore pour 35 ans avant d'arriver au maximum. C'est loin mais le verra.

                    "La première sécurité est la liberté"

  • # j'ai compris qq petites choses

    Posté par . Évalué à 5.

    merci à tous

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.