Journal Quels avantages à installer un noyau 64 bits ?

Posté par (page perso) . Licence CC by-sa
Tags :
4
28
sept.
2011

Il y a un an ou deux, installer un noyau 64 bits pouvait s'avérer problématique surtout si on devait utiliser des applis proprios, généralement uniquement compilées pour 32 bits. (Il y'avait Flash, Skype, Lotus Notes, des machins de ce genre).

Disposant d'un PC avec 4 Go de Ram, j'avais installé un noyau 64 bits avant de tout réinstaller en 32 bits pour un truc du genre décrit plus haut (un flasheur de firmware, je pense, je ne me souviens plus).

Aujourd'hui, je suis toujours en 32 bits, utilisant mes 4 Go de RAM grâce à un noyau PAE, automatiquement installé par Ubuntu.

Ma question est donc: qu'aurais-je à gagner à réinstaller une distrib 64 bits ?

  • En performance ?
  • En autonomie ?
  • En n'importe quoi d'autre ?

Et quel serait le prix à payer ?

J'ai même lu des rumeurs comme quoi le 64 bits serait plus gourmant et donc boufferait plus vite la batterie. Qu'en est-il ?

Et vous, pourquoi êtes-vous en 64 ou 32 bits ?

  • # Noyau / espace utilisateur

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

    Déjà, tu peux distinguer noyau et espace utilisateur, parce que Linux amd64 est parfaitement capable de lancer des processus i386. En particulier, il est tout à fait possible d'installer une distribution i386 avec un noyau amd64.

    • [^] # Re: Noyau / espace utilisateur

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

      Et ça permet d'utiliser plus de 4 Gio de mémoire sans passer par les PAE, donc probablement de façon plus efficace. Bien évidemment, chaque processus ne peut accéder à plus de 4 Gio, en revanche.

      • [^] # Re: Noyau / espace utilisateur

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

        A propos:

        utilisant mes 4 Go de RAM grâce à un noyau PAE

        Il n'y a pas besoin de PAE pour utiliser 4 Go de RAM. L'extension PAE est necessaire pour en addresser plus (mais ne changera rien au fait que chaque processus est limite a 4 Go).

        Excusez l'absence d'accents dans mes commentaires, j'habite en Allemagne et n'ai pas de clavier francais sous la main.

        • [^] # Re: Noyau / espace utilisateur

          Posté par . Évalué à 5.

          Il n'y a pas besoin de PAE pour utiliser 4 Go de RAM

          Me semble que si. Y'a pas que la RAM dans l'espace adressable.

          https://secure.wikimedia.org/wikipedia/en/wiki/Memory-mapped_I/O

          • [^] # Re: Noyau / espace utilisateur

            Posté par . Évalué à 1.

            Je confirme.
            Sans le noyau pae, debian/ubuntu ne détecte pas toute ma ram.

            • [^] # Re: Noyau / espace utilisateur

              Posté par . Évalué à 1.

              Alors, je viens d’en acheter 4Go et de me renseigner.

              En fait c’est un peu plus compliqué que ça et ça dépend des options de compilations du noyau. Je n’y ai rien compris, à part que c’est un petit peu au bonheur la chance. Grosso modo il y a une certaine quantité de mémoire réservée par le matos et le noyau, on peut se retrouver, avec ou sans PAE, avec plus ou moins de mémoire en fonction (machine — processeur et matériel —, bios, noyau — ça vaut pour windows aussi, suivant l’édition — et pour le noyau en fonction des options de config. et des patchs — je soupçonne Ubuntu qui cible le desktop de changer ça par rapport à Debian).

              • [^] # Re: Noyau / espace utilisateur

                Posté par . Évalué à 1.

                je soupçonne Ubuntu qui cible le desktop de changer ça par rapport à Debian

                C'est vrai que sur la page d'accueil on a une écran de desktop et un laptop mais Ubuntu server.

                Je ne suis pas sûr que Canonical cible seulement le desktop avec Ubuntu.

    • [^] # Re: Noyau / espace utilisateur

      Posté par . Évalué à 6.

      On peut d'ailleurs noter que certains développeurs du noyau prévoient un mode x32. Ce mode doit combiner le meilleur des deux modes:

      • Les instructions et les registres supplémentaires du mode 64 bits
      • Des registres et des pointeurs sur 32 bits pour réduire l'empreinte mémoire

      Lire http://lwn.net/Articles/456731/ et voir https://sites.google.com/site/x32abi/

  • # Mémoire et performance

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

    Des logiciels en amd64 consomment un peu plus de mémoire, puisqu'ils utilisent des pointeurs sur 64 bits au lieu de 32.

    En revanche, ils sont probablement un peu plus rapide, parce qu'ils ont accès à plus de registres, ce qui évite des opérations de permutation.

    • [^] # Commentaire supprimé

      Posté par . Évalué à 10.

      Ce commentaire a été supprimé par l'équipe de modération.

    • [^] # Re: Mémoire et performance

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

      pointeurs sur 64 bits au lieu de 32
      évite des opérations de permutation

      on perd d'un côté, on gagne de l'autre, pas sûr que l'empreinte mémoire soit si augmentée que ça.

      et pour les calculs intensifs, on gagne facilement 20% en effet.

      Je rajouterai qu'en 64 bits le FPU est définitivement enterré (il est inaccessible), c'est le SSE qui est utilisé pour les calculs flottants, donc adieu le format interne de 80 bits même pour les variables de type float, mais du coup bonjour les incompatibilités binaires d'exécution entre 32 et 64 bits... Par contre, pour le calcul en float 32-bits pur, ça torche.

      Remarquez qu'on peut aussi utiliser le SSE au lieu du FPU sous pour le calcul flottant en 32 bits, avec l'option -mfpmath=sse de gcc.

      • [^] # Re: Mémoire et performance

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

        le x87 n'est pas inaccessible, il est juste deprecié à la faveur de sse2, mais a priori on peut continuer à l'utiliser, je pense d'ailleurs que le type long double continue à l'utiliser.

        cf par exemple http://www.virtualdub.org/blog/pivot/entry.php?id=107

        • [^] # Re: Mémoire et performance

          Posté par . Évalué à 0.

          Les perfs ne sont pas pathétiques de chez pathétique dans ce cas la ? Si je me rappelle bien, le P4 n'avait déjà plus qu'une sombre émulation du x87

          • [^] # Re: Mémoire et performance

            Posté par . Évalué à 2.

            Les perfs sont moins bonnes. Cependant, parfois, l'important c'est la reproductibilité des résultats. J'ai bossé avec des partenaires industriels qui refusaient mes optimisations parce que l'ordre des opérations sur les flottants n’était plus garanti. En pratique ca n'aurait rien du changer (les instructions SSE2 et plus sont effectuées sur 80 bits en interne), mais du coup la norme IEEE754 sur 64 bits n’était plus respectée, et malgré des résultats plus précis, ils ne pouvaient plus passer les tests de régression de leurs clients... Du coup : FPU.

            • [^] # Re: Mémoire et performance

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

              Tu voulais dire FPU à la place de SSE2 et SSE2 à la place de FPU, non ?

              • [^] # Re: Mémoire et performance

                Posté par . Évalué à 2.

                Non non. FPU == 64 bits "purs" là où SSE2+ == 80 bits en interne lors de l’opération.

                • [^] # Re: Mémoire et performance

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

                  c'est peut être en 80 bits en interne en SSE2 (mais je doute), mais dans tous les cas les résultats intermédiaires sont stockés en 64 bits, contrairement au x87 où les valeurs contenues dans les registres sont sur 80 bits. d'où l'incompatibilité.

                  • [^] # Re: Mémoire et performance

                    Posté par . Évalué à 0.

                    Tu peux douter tant que tu veux, ça reste vrai. :) L’unité flottante utilisée par les instructions SSE est sur 80 bits en interne, avec accumulation potentielle si tu peux "pipeliner" les opérations (d'ou une meilleure précision). Sauf que le client de nos partenaires utilisait des machines "vectorielles" NEC qui se contentaient de la norme stricte IEEE, et donc les tests échouaient malgré une précision accrue.

                    De plus, si tu utilises le compilateur d'Intel (ce qui était mon cas), a partir du moment ou du spécifies -mieee-strict (ou un truc du genre), la plupart des optimisations qui devraient etre legales (puisque + et * sont commutatifs) deviennent "illégales" du point de vue d'icc (justement à cause des problèmes d'arrondis), et icc génère du code x87.

                    • [^] # Re: Mémoire et performance

                      Posté par . Évalué à 1.

                      Breaking news. Alors j'ai pigé. Apparemment il est possible de forcer la FPU x87 à se limiter à 64 bits, alors que pour l’unité SSE, c'est tout simplement pas possible.

                    • [^] # Re: Mémoire et performance

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

                      L’unité flottante utilisée par les instructions SSE est sur 80 bits en interne

                      franchement je pense que tu te trompes. SSE2 c'est 64 bits en double precision, et c'est tout. Des problemes de non-conformité ieee peuvent survenir avec les instructions fused mult-add , mais elles n'existaient pas en sse2. Je te laisse chercher une url qui va dans ton sens, a mon avis tu vas avoir du mal.

                      • [^] # Re: Mémoire et performance

                        Posté par . Évalué à 1.

                        Bon, the intraweb a l'air de te donner raison. Cependant, je me donne le droit de questionner la réalité et de revenir ici avec plus d'informations.

                • [^] # Re: Mémoire et performance

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

                  Comme précisé par ouasse , c'est bien le fpu x87 qui a des registres sur 80-bits. Heureusement intel n'a pas réédité cette colossale connerie avec le SSE2 dont les registres 128 bits contiennent deux reels en double précision, et qui effectue des calculs conformes a IEEE754.

    • [^] # Re: Mémoire et performance

      Posté par . Évalué à 3.

      donc un pointeur <64 prend 64 de tout façon, c'est ça ?

      Il n'est donc pas possible, comme c'est le cas dans l'ARM Cortex de mixer pour avoir des données de tailles différentes alignées en mémoire pour prendre moins de place ?

  • # Commentaire supprimé

    Posté par . Évalué à 7.

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Quels avantages à installer un noyau 64 bits ?

    Posté par . Évalué à 3.

    Moi j'attends l'avis de skc< sur le TLB et les cache hits/misses de PAE pour basculer en 64 bits.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Quels avantages à installer un noyau 64 bits ?

      Posté par . Évalué à 10.

      Ok, c'est parti.

      Le PAE (Extension d'adresse physique) est un principe plutôt simple: le MMU (Unité de gestion mémoire) qui fait la conversion entre adresse logique et adresse physique est étendu afin que les adresse physiques soient codées sur 36 bits (64Gio). Les adresses logiques restent sur 32 bits (4gio), ce qui explique que les processus soient limités à 4Go.

      Lorsque le processeur accède à une case mémoire, l'adresse logique sur 32 bits est convertie en adresse physique sur 36 bits via le TLB (Translation Lookaside Buffer) et tout le monde est content. De ce coté, ça n'a quasiment aucun impact.

      Pour le kernel, les choses sont moins roses. Lui aussi est limité à 4Gio car toutes les adresses sont sur 32 bits. Or le kernel a globalement besoin d'accéder à toute la mémoire de tous les processus (pour mapper les pages du programme, des fichiers, lire ou écrire les données réseau, disque etc...) et comme on a plus de 4 Gio de mémoire, il est impossible de faire tout rentrer dans l'espace d'adressage de 32 bits du kernel.

      Ça oblige à revenir aux joies de la mémoire paginées. Le kernel modifie en permanence les réglages de la MMU pour accéder, morceaux par morceaux, aux pages mémoires dont il a besoin. Opération très couteuse parce qu'elle oblige à vider un certain nombre de cache, en particulier le cache TLB qui conditionne tous les accès à la mémoire.

      Bref, un bricolage pas très élégant.

  • # Autre question

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

    Dans le cas où tu dois installer/réinstaller une distro, quel est intérêt de rester en 32bits?
    Je ne suis passé au 64bits que récemment (sortie de Debian Squeeze) et je n'ai jamais eu à me plaindre depuis. Tout fonctionne (Flash, les jeux 32bits sous wine, etc...)

    • [^] # Re: Autre question

      Posté par . Évalué à -4.

      En résumé, tu essaies de nous expliquer que l'avantage du 64 bits, c'est que ça fonctionne aussi bien que le 32 bits, sauf que ça utilise un peu plus de mémoire, 64 bits oblige ? Ok, ça me va, je reste en 32 bits.

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

      • [^] # Re: Autre question

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

        D'ailleurs dans les minimum systeme requirements de windows 8, c'est

        1 Go de ram en 32-bit
        2 Go de ram en 64-bit

        • [^] # Re: Autre question

          Posté par . Évalué à 5.

          Ouais, enfin ça veut strictement rien dire, Microsoft Propaganda Inside.

          "The trouble with quotes on the internet is that it’s difficult to discern whether or not they are genuine.” Abraham Lincoln

        • [^] # Re: Autre question

          Posté par . Évalué à 6.

          Et où tu as vu que M$ faisait de l'informatique ?
          Ils font du marketing, du commerce, du juridique, du lobbying ; le tout saupoudré de FUD.

          • [^] # Re: Autre question

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

            moi je veux bien que ce soit de la propagande ou du marketting mais dans quel but ? pourquoi artificiellement gonfler les prérequis de la version 64-bit ?

            • [^] # Re: Autre question

              Posté par . Évalué à 5.

              artificiellement gonfler
              
              

              je ne serai pas allé jusque là.
              imho, juste que en effet, la 64bit nécessite logiquement plus de RAM que la 32bit, donc comme il faut bien donner des pré requis, on va prendre un chiffre simple pour 32bit et le doubler pour 64bit. On est plus dans une approche marketing je pense.

              • [^] # Re: Autre question

                Posté par . Évalué à 2.

                Je pense que tu as raison. Il ne faut pas oublier que s'il est vrai que les adresses doublent en taille, mais que pour une application multimédia (DVD, jeu, etc.) par exemple, ce qui consomme le plus de place, ce sont les données, qui elles ne changent pas. La partie purement code et adresses devient anecdotique au fur et à mesure que la somme de données a récupérer grandit.

      • [^] # Re: Autre question

        Posté par . Évalué à 7.

        il y a 2x plus de registre le code est plus rapide.

        Si tu as plus de 4 Go de mémoire, le noyau sait utiliser correctement la mémoire en plus pour en faire du cache disque.

        SSE2 est inclus d'office ce qui évite de se poser mille question sur la présence ou non de certaines instructions.

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

      • [^] # Re: Autre question

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

        Tes applis sont pas compilées avec les mêmes optimisations par défau (i386 vs x86-64). la taille des registres, pas besoin de te prendre la tête si tu rajoutes de la RAM...
        Après faudrait sortir les benchs plutôt que parler.

      • [^] # Re: Autre question

        Posté par . Évalué à 2.

        C'est pire que ça. Ca prend aussi plus de place sur disque si tu veux utiliser du 32 bits et du 64 bits. Ben wii, il te faut l'userland 64 bits plus toute une palanquée de trucs 32 bits pour les programmes 32 bits \o/

  • # Un avis totalement subjectif et non technique

    Posté par . Évalué à 1.

    Je suis passé en 64bits natif... Parce que mon processeur le pouvait et que je voulais voir s'il y avait vraiment une différence.

    Bilan: A mon niveau (usage quotidien: Internet, mail, bureautique, un peu de synthèse 3D, films, musique,...) aucun changement significatif des performances.

    La différence, pour moi, réside dans le nombre de cœurs (deux au lieu d'un) et quelques paramètres de noyau "tuné" (IO scheduler, etc...), où je ressent vraiment une plus grande réactivité de l'interface.

    Prix à payer: Aucun (si le proc, mais... :) ) Tous mes logiciels habituels fonctionnent (recompilés, car je suis sur "gentoo")

    Comme c'est un PC "fixe", je ne peux pas répondre pour la batterie.

    Il n'y a pas de mauvais outils, il n'y a que de mauvais ouvriers

  • # Quels avantages à installer un noyau 64 bits ?

    Posté par . Évalué à 9.

    J'avais posé la question il y a environ 6 mois sur La 3Bune © : je me suis dit qu'avec tous les experts en puissance internationale, j'allais avoir des arguments techniques en bétons armés.

    Et effectivement, j'en ai eu pour m'aider à la prise de décision. En résumé, si j'ai bien compris, c'est du style « tu comprends, en 64 bits, tu as la mémoire burstée du pipeline de niveau 4 qui s'entrelace à l'interface scalaire des vecteurs de propagation d'adresse du cache L1, du coup évidemment, c'est Mieux © car ça ne va pas plus vite qu'en 32 bits, ça n'est pas plus sécurisé non plus, tu auras peut-être quelques problèmes mineurs que tu n'avais pas avant, mais bon, au moin ça utilise presque deux fois plus de RAM qu'avant, et ça tombe bien, tu as 4Go, autant qu'ils servent ! ».

    J'ai évidemment constaté que tout le monde sur La 3Bune © était d'accord - ce qui est quand même assez miraculeuxdans un débat d'expert - et que c'était le meilleur argument, aussi je n'ai pas hésité un seule seconde : je suis resté en 32 bits.

    « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

  • # Plus mieux bien !

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

    En général on gagne en performances (l'extension du nombre de registres fait plus que compenser la taille des pointeurs).
    J'ai aussi vu pas mal de mails sur la LKML qui disaient que le code 64 bits était souvent plus propre.
    Dans tous les cas on gagne en sécurité (cf la dernière phrase de ce post de Kees Cook).

    • [^] # Re: Plus mieux bien !

      Posté par . Évalué à 4.

      Dans tous les cas on gagne en sécurité (cf la dernière phrase de ce post de Kees Cook).

      Oui, mais comme on est obligé d'installer un système multilib si tu utilises wine, skype ou virtualbox tu risques aussi d'en perdre.

    • [^] # Re: Plus mieux bien !

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

      Il me semble que l'un des intérêts aussi, pour les non gentooistes, c'est d'avoir des binaires exploitant les jeux d'instructions un peu avancé. Car les distribs 32 bits se doivent d'être compatible avec d'anciennes archis. En plus des nouveaux registres, et des registres plus large, évidemment.

      • [^] # Re: Plus mieux bien !

        Posté par . Évalué à 10.

        Car les distribs 32 bits se doivent d'être compatible avec d'anciennes archis.
        N'oublions tout de même pas que même Debian a droppé le support de l'architecture 386 au profit du 486 !

        -----------> []

  • # argumentaire en béton armé

    Posté par . Évalué à 7.

    C'est possible, c'est faisable, c'est fait.

  • # flash 64

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

    Pour flash il suffit d'utiliser ce binaire qui fonctionne très bien :
    Download plug-in for Linux 64-bit (TAR.GZ 6.7 MB)
    http://labs.adobe.com/downloads/flashplayer11.html

    le .so est à copier dans ~/.mozilla/plugins

  • # ~ +30% de perf en encodage

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

    Il y a quelques temps j'avais comparé le temps d'encodage d'un CD extrait en wav en ogg. Passer d'un noyau 32 bits à 64 bits me faisait gagner environ 30% de temps d'encodage.

    Je n'ai pas réitéré dernièrement des tests notamment pour du dématriçage d'image au format raw en format jpg, j'ai supposé que les gains de temps étant dans les mêmes eaux que ce que j'avais constaté avec l'encodage.

    Au final j'utilise Mageia en 64 bits parce que mon processeur est 64 bits et que je suppose que ça apporte quelques plus de l'utiliser ainsi plutôt qu'en 32 bits.

  • # L'intérêt de ce type de question sur un journal ?

    Posté par . Évalué à 5.

    Il y a un an ou deux, installer un noyau 64 bits pouvait s'avérer problématique surtout si on devait utiliser des applis proprios, généralement uniquement compilées pour 32 bits. (Il y'avait Flash, Skype, Lotus Notes, des machins de ce genre).

    Tu sais il y a des forums pour répondre à ce type de question.

    Nonobstant je vois deux choses contradictoires.

    Un tu n'as même pas cherché que l'on pouvait lancer des applications 32 bits dans un environnement 64 bits.

    Deux tu cherches une justification a rester sur tes propres impressions/arguments sans même chercher à comprendre comment fonctionne un OS.

    Bref ton proc est il 32 ou 64 bits ?
    Si il est en 32 tu restes en 32, si il 64 tu l'as mets en 64.

    • [^] # Re: L'intérêt de ce type de question sur un journal ?

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

      "Un tu n'as même pas cherché que l'on pouvait lancer des applications 32 bits dans un environnement 64 bits."

      Si, et je l'ai déjà fait. Mais c'est lourd, chiant, demande du bricolage et ne s'intègre pas avec les mises à jours de ta distrib. De plus, ça casse souvent quand tu mets des librairies système à jour. Quand tu as un repository 32 bits (et pas de 64 bits) et que tu veux bosser, utiliser 32 bits est vachement plus simple.

      "Bref ton proc est il 32 ou 64 bits ?
      Si il est en 32 tu restes en 32, si il 64 tu l'as mets en 64."

      Mon proc est en 64 bits. Ma distrib 32 bits. Et je n'ai pas vu le moindre argument en faveur d'installer une distrib 64 bits étant donné que je ne fait pas de l'encodage ni du calcul intensif.

      "Deux tu cherches une justification a rester sur tes propres impressions/arguments sans même chercher à comprendre comment fonctionne un OS."

      Tu as cherché à poster vite fait sans même prendre le temps de comprendre ma question. ;-)

      • [^] # Re: L'intérêt de ce type de question sur un journal ?

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

        Et je n'ai pas vu le moindre argument en faveur d'installer une distrib 64 bits étant donné que je ne fait pas de l'encodage ni du calcul intensif.

        Et l'argument de la sécurité ?

        • [^] # Re: L'intérêt de ce type de question sur un journal ?

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

          oui, c'est vrai. D'ailleurs, je suis en 64 bit sur mon serveur. Sur mon laptop, j'estime ça moins crucial.

          • [^] # Re: L'intérêt de ce type de question sur un journal ?

            Posté par . Évalué à 6. Dernière modification le 29/09/11 à 15:31.

            Mais c'est lourd, chiant, demande du bricolage et ne s'intègre pas avec les mises à jours de ta distrib. De plus, ça casse souvent quand tu mets des librairies système à jour.

            ???
            Déjà il n'y a pas de liens entre les mises à jours de tes appli. 64 bits et 32 bits donc en aucun cas ça ne peut casser quelque chose entre elles. Sur debian, centos, redhat ou fedora (arch est hors course puisque en rolling) j'ai rarement vu une mise à jour casser quelque chose à part bien sur lorsque l'on change de version de distribution. Ou alors j'ai vu aussi un comportement assez idiot qui est d'utiliser ndiswrapper quant le paquet en 64 bits est dispos.

            Bref à part si tu compiles toi-même tes versions 32 ou 64 bits ou récupère une application non dispos dans les dépots ; une mise à jour peut poser problème mais c'est aussi à toi de regarder les mises à jour que tu fais et ne pas faire dans le syndrome press button.

            Pour résumer :

            • si ça casse quelque chose dasn une utilisation normale ça veut dire que le paquet à été mal fait (qu'il n'a pas à être dans les dépots) et tu as tout à fait le droit de le reporter sur le bugzilla de ta distribution. Ceci est aussi valable sur les distribution only 32 que 64 bits. Dernièrement j'ai encore le cas du paquet libmtp qui met en l'air la reconnaissance des sondes spyder mais c'est aussi valable si tu avais une version seulement 32 bits.

            • Si ça casse quelque chose parce que l'utilisateur s'amuse à faire n'importe quoi (interface, chaise, clavier) pas besoin de reporter sur un système qui fonctionne correctement jusqu'à preuve du contraire.

            ps ==> on ne dit pas librairies

      • [^] # Re: L'intérêt de ce type de question sur un journal ?

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

        Si tu as une distrib qui fait bien les choses pour 64 bits comme Arch Linux, tu as les librairies 32bits sous forme de package, donc pas de soucis. Ça fait bien 2 ans que je suis en 64bits, jamais eu un soucis pour lancer un programme en 32bits.

      • [^] # Re: L'intérêt de ce type de question sur un journal ?

        Posté par . Évalué à 2.

        Mais c'est lourd, chiant, demande du bricolage et ne s'intègre pas avec les mises à jours de ta distrib

        Ben si, ça marche. En tout cas avec Mageia.

  • # Un désavantage du 64bits, même si ce n'est pas sa faute

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

    Effectivement tout marche bien en 64bits depuis quelques années/mois. On y gagne un peu pour quelques gros calculs à mon avis même si je ne vois pas la différence au quotidien.

    J'ai quand même un problème notable avec le 64 bits : ndiswrapper a besoin d'un pilote windows 64bits (forcément) fonctionnel, ce qui est souvent très difficile à trouver, et la compatibilité avec ndiswrapper est plus rare. Conclusion pour certaines cartes wifi foireuses, le passage en 64 bits peut poser problème, voire carrément rendre indisponible le pilote wifi.

  • # saitmieux

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

    Et vous, pourquoi êtes-vous en 64 ou 32 bits ?

    64 bits c'est mieux pour ZFS.

    (je suis déjà dehors).

    les pixels au peuple !

    • [^] # Re: saitmieux

      Posté par . Évalué à 2.

      pourquoi tu sors ?

      $ lsmod |grep zfs
      zfs                   985736  20 
      zcommon                46636  1 zfs
      znvpair                52918  2 zfs,zcommon
      zavl                   15010  1 zfs
      zunicode              331186  1 zfs
      spl                   110091  5 zfs,zcommon,znvpair,zavl,zunicode
      $ uname -m
      x86_64
      $ uname 
      Linux
      
      

      (ce commentaire est totalement inutile ^^)

  • # Consommation de batterie

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

    J'ai récemment installé LMDE en 64bits, j'ai effectivement remarqué que ma batterie se décharge plus vite par rapport à avant (à savoir Debian Squeeze en 32bits).

    • [^] # Re: Consommation de batterie

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

      Tu es sûr que ce n'est pas du aux problèmes récents de consommation du noyau ?

      • [^] # Re: Consommation de batterie

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

        Pas au courant du problème! Une source?!

        LMDE est à base de Squeeze, donc, ça ne doit pas être dû au noyau, non?

        • [^] # Re: Consommation de batterie

          Posté par . Évalué à 2.

          Pas au courant du problème! Une source?!

          On en a parlé ici-même

          LMDE est à base de Squeeze, donc, ça ne doit pas être dû au noyau, non?

          Mais LMDE, tout comme Squeeze, a forcément un noyau ! Donc il se peut que le noyau inclus dans Squeeze et/ou dans LMDE soit un de ceux concernés par le bug...

        • [^] # Re: Consommation de batterie

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

          Euh il me semble que LMDE est basé sur Debian Testing ... donc c'est pas la même version de noyau ni les même versions d'appli que sur ta squeeze (sans compter la "surcouche" de Linux Mint).

          Du coup je suis pas sur que la différence d'autonomie que tu as remarqué ai un quelconque rapport avec le 64 bits.

    • [^] # Re: Consommation de batterie

      Posté par . Évalué à 3.

      C'est parce que ta batterie est en 32 bits.

  • # Sur les distributions compilées....

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

    Je rejoins le commentaire plus haut, les distributions / OS qui se recompilent (Gentoo, BSD, etc...) bénéficient des améliorations des compilateurs en 64 bits.

    Certes, l'utilisation mémoire est plus importante, mais on peut gagner quelques cycles d'horloges pour certaines opérations, qui lorsque très sollicitées, peuvent apporter un plus.

    Corrélation avec une DB Oracle:
    - nombre d'IOs total: 100 000 / heure
    - j'ai deux requêtes SQL:
    -- une mal foutue (full scan) qui bouffe 25 000 IOs chaque exécution, mais qui est pas souvent exécutée -> une fois par heure,
    -- une bien foutue, qui bouffe seulement 5 IOs par exécution, mais est souvent exécutées -> 4 fois par secondes (total cumulé par heure=environ 75 000 IOs)

    Moralité: si j'arrive à ne diminuer que de 1 ou 2 blocs la petite requête, je gagnerais beaucoup plus que si j'optimise la grosse requête.

    Et avec le 64 bits, par exemple avec un serveur web qui sert des milliers de petites requêtes, le gain peut être significatif.

    Enfin, pour le end-user, rappelons qu'un système n'est qu'un petit nombre de petites fonctions appelées très souvent....

    Moralité: de nos jours, la plupart des puces travaillent bien en 64 bits, et les compilateurs savent optimiser de mieux en mieux cette architecture, d'où l’intérêt d'un OS qui se recompile sur sa cible, ou dont les paquets binaires ont été optimisés.

    Si la puce Itanium avait pu émerger, nous aurions du vrai 64 bits sur nos laptops, et on serait dans un monde meilleur.

    • [^] # Re: Sur les distributions compilées....

      Posté par . Évalué à 6.

      Si la puce Itanium avait pu émerger, nous aurions du vrai 64 bits sur nos laptops, et on serait dans un monde meilleur.

      En attendant, les machines à base d'Itanium 2 ont un double emploi : calcul haute-performance bien sûr, mais aussi table-basse chauffante (quand tu as la version "mini-armoire" et pas un rack).

    • [^] # Re: Sur les distributions compilées....

      Posté par . Évalué à -3.

      Et avec le 64 bits, par exemple avec un serveur web qui sert des milliers de petites requêtes, le gain peut être significatif.

      Plus que ça encore, avec un serveur d'appli qui traite un minimum de volume de données, le faire tourner sur 4 a 8 Go est souvent un minimum syndicale, et la, en dehors du 64 bits, point de salut.
      Apres, ça reste un cas particulier quand meme.

      If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

  • # La killer feature

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

    En 64 bits, les entiers natifs OCaml passent sur 63 bits, ce qui permet de résoudre bien plus de problèmes de Project Euler sans avoir à passer en Int64 ou en BigInt, dont les syntaxes sont moches et les performances pas terribles.

    • [^] # Re: La killer feature

      Posté par . Évalué à 10.

      Quelle avancée prodigieuse ! Il est possible d'utiliser 63 bits sur les 64 pour les nombres !

      les syntaxes sont moches

      Quand on utilise un langage où 1. + 1. ne compile pas car il faut écrire 1. +. 1. (et qu'évidemment 1 +. 1 ne fonctionne pas non plus), il est vraiment curieux que l'on se permette de faire des remarques sur la beauté d'une quelconque syntaxe.

      • [^] # Re: La killer feature

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

        Quelle avancée prodigieuse ! Il est possible d'utiliser 63 bits sur les 64 pour les nombres !
        Je trouve ça plutôt malin. Ça permet au runtime de ne pas à avoir à utiliser le boxing pour les types entiers, ce qui est très bon pour les performances, et est une optimisation utilisée par bon nombre de machines virtuelles. Alors qu'avec 32 bits, la limite se situait à 1 milliard et des brouettes (compter le bit de boxing et le bit de signe), ce qui est un poil limite, en 64 bits, c'est suffisamment haut pour ne généralement pas avoir à s'en préoccuper.

        Maintenant, il est vrai que +. pour les flottants, ce n'est pas bien pratique, et c'est un gros défaut du langage, d'autant plus dommage que Haskell résout le problème fort élégamment avec les type classes. Mais ça serait dommage de jeter bébé avec l'eau du bain: une fois que l'on a compris où vont les point virgules, OCaml est un langage avec lequel il est très agréable de programmer.

  • # Qui peut le plus ?

    Posté par . Évalué à -5.

    64 en force.
    Après 3 ans d'OS 64 bits (Vista puis Seven) sur le portable professionnel (Lenovo T410), le changement de boulot et le retour à XP 32 bits (Lenovo L512), ça pique.

    • [^] # Re: Qui peut le plus ?

      Posté par . Évalué à 10.

      Oui moi aussi j'ai connu ça. Je suis passé d'une 306HDi (rouge) à une Laguna V6 (grise). Et bien je confirme :
      - une Renault ça avance bcp plus vite qu'une Peugeot
      - un moteur atmosphérique est bcp plus puissant qu'un moteur turbo
      - une voiture grise est plus confortable qu'une voiture rouge

      • [^] # Re: Qui peut le plus ?

        Posté par . Évalué à 9.

        une voiture grise est plus confortable qu'une voiture rouge

        Vous avez tout à fait raison Thérèse parce que le gris et bordeaux ça va avec tout alors, vous ne risquez pas de vous tromper.

  • # On peut vraiment??

    Posté par . Évalué à 4.

    Mettre 4Go de RAM dans un N800 à la boulangerie du coin?

    ---------------> [ ]

  • # Avantages et inconvénients

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

    Pour madame Michu, la question c'est plutôt "Quels avantages à rester en 32 bits". Je pense honnêtement aujourd'hui que la réponse est aucun: tu installes n'importe quelle distribution digne de ce nom en 64 bits et les potentiels problèmes de Mr. Tout Le Monde sont résolus par cette dernière (le Flash qui ne marche qu'en 32 bits par exemple est utilisé avec nspluginwrapper de manière transparente).

    Pour un serveur, ou un utilisateur avancé, il faut savoir plusieurs choses: le 64 bits a priori est censé être plus performant pour tout ce qui est gros traitement de données (registres 48 bits je crois au lieu de 32) je suis pas trop sûr des détails, mais normalement c'est plus rapide.

    Par contre, désavantage: la taille des pointeurs est plus élevée, donc tu consommes plus de mémoire.

    Pour les administrateurs système, il faut savoir que des logiciels (comme le serveur de base de données clé-valeur Redis, par exemple) va stoquer tous ses entiers en 64 bits si l'OS est en 64bits, et en 32 bits sinon. Conclusion: il va utiliser beaucoup plus de mémoire pour le stockage de ces données (et un système de stockage clé valeur va potentiellement être utilisé pour stoquer des compteurs en masse, choses du genre).

    Donc personnellement, j'ai pas de réponse universelle; Par contre, pour Mme Michu, la vraie question c'est "Pourquoi pas?".

Suivre le flux des commentaires

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