Journal Flash version 64 bits pour linux exclusivement!

Posté par  (site web personnel) .
Étiquettes : aucune
14
17
nov.
2008
Voici un lien en anglais avec plus d'infos:

http://www.download.com/8301-2007_4-10097931-12.html

Ils expliquent que le 64 bits s'est développé plus rapidement sous linux que sous les autres OS, notamment grâce à la philosophie de recompilation à partir des sources.

En conséquence, le support 64 bits est proposé en exclusivité pour linux! Seul bémol, c'est encore une version alpha.
  • # et pour télécharger ?

    Posté par  (site web personnel) . Évalué à -2.

    yaurait un lien vers le svn ?
    et un changelog aussi ?
    (ah on me souffle dans l'oreillette que question licence, ce n'est toujours pas ça et que Adobe prendrait ses utilisateurs pour des bêta-testeurs gratuits).
    • [^] # Re: et pour télécharger ?

      Posté par  . Évalué à 2.

      http://labs.adobe.com/technologies/flashplayer10/

      Il y a quand même un forum pour discuter des problèmes
      • [^] # NE SURTOUT PAS TÉLÉCHARGER !

        Posté par  (site web personnel) . Évalué à 6.

        Un peu d'altruisme et d'écologie tout de même :-). Le plugin flash c'est tout de même un des codes les plus polluant (au sens propre comme au figuré, mais ici au sens propre) du monde. Dès qu'il est installé et que votre navigateur à eu le malheur de passer sur une page contenant une $£~!/\ en flash il se met à faire « tourner » joyeusement le microprocesseur ; celui-ci chauffe et active les ventilateurs du boitier tout en réduisant le rendement de l'alimentation. Au final je ne serais pas étonné si la consommation moyenne des ordis avec flash n'était pas 20% supérieur à ce qu'elle est sans lui...

        « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

        • [^] # Re: NE SURTOUT PAS TÉLÉCHARGER !

          Posté par  . Évalué à 1.

          Un processeur qui est plus utilisé consomme plus ? Je croyais que non justement, que seuls processeurs pour ordi portable avaient cette caractéristique (baisser la consommation lorsque la charge diminue) ...
          • [^] # Re: NE SURTOUT PAS TÉLÉCHARGER !

            Posté par  (site web personnel) . Évalué à 8.

            Oula clairement pas, les processeurs pour portables ne font que consommer moins, mais à vue de nez le ratio entre consommation en charge et consommation à fond est le même. Le meilleur contre exemple c'est les Q9450 (je crois) d'intel, 15W à vide, 80 à pleine charge. Tout ce que les processeurs de portables ont en plus c'est la possibilité de bloquer le CPU à une vitesse d'horloge inférieure et/ou de le bloquer X% du temps (et encore sur les processeurs de bureaux c'est plus ou moins valable aussi).
            • [^] # Re: NE SURTOUT PAS TÉLÉCHARGER !

              Posté par  . Évalué à 3.

              Tout ce que les processeurs de portables ont en plus c'est la possibilité de bloquer le CPU à une vitesse d'horloge inférieure et/ou de le bloquer X% du temps

              Les processeurs de pc de bureau ont également ce genre de chose. Mais c'est arrivé en premier pour les portables, évidemment.
              • [^] # Re: NE SURTOUT PAS TÉLÉCHARGER !

                Posté par  (site web personnel) . Évalué à 2.

                Comme je l'ai mis c'est plus ou moins vrai, meme si j'aurais du le tourner dans l'autre sens. Chez les Core 2 de chez Intel, il n'y a en général que très peu de liberté au niveau changement au vol de fréquence: la plupart du temps le multiplicateur est fixé, ou tout au mieux on peut zapper entre x6, x6,5 et x7 mais ca s'arrête là, alors que sur les processeurs de portables on peut descendre bien plus bas à ma connaissance. Après sur les processeurs fixes très modernes y a peut être une gestion avec l'acpi plus poussée mais même mon Q6600 pas si vieux que ca a pas ce genre de fonctionnalités.
        • [^] # Re: NE SURTOUT PAS TÉLÉCHARGER !

          Posté par  (site web personnel) . Évalué à 5.

          Personnellement, j'utilise deux profils Firefox, un pour la navigation courante, et un pour voir les vidéos en Flash.
          Sinon il y a toujours FlashBlock.
  • # Enfin...

    Posté par  . Évalué à 10.

    S'pa trop tôt ! Prochaine étape, la libération ? Bah... On peut toujours rêver...

    Sinon, c'est quoi cette philosophie de la recompilation !? C'est nouveau, on compile pas sur les autres plateformes ? On écrit directement les .exe à la mano ? Ça expliquerai beaucoup de choses !
    • [^] # Re: Enfin...

      Posté par  (site web personnel, Mastodon) . Évalué à 10.

      À priori c'est pas ça qui est dit mais :
      «The 64-bit support will arrive on other operating systems later, Adobe said, but Linux fans get it first because they were the most vocal in their desire for it.»

      En gros, on l'aurait en premier parce qu'on a gueuler les plus forts ;-)
      • [^] # Re: Enfin...

        Posté par  . Évalué à 10.

        C'est à babord qu'on gueule qu'on gueule, c'est à babord qu'on gueule le plus fort !
    • [^] # Re: Enfin...

      Posté par  . Évalué à 10.

      Je suis le premier à cracher sur Flash. Par contre, il ne faut pas oublier ils ont libérés les specs de la version 10 récemment (http://blogs.adobe.com/penguin.swf/2008/11/swf_and_flv_10_sp(...)

      Alors certes le player est closed source, et ils méritent le bûcher pour ça, mais en même temps, on aurait plus aucune raison de leur cracher dessus, et ce serait dommage.

      En passant, y'a la version de swfdec 0.9.2 qui est sortie (en « instable »)

      Pour en revenir sur Flash, c'est quand même une bonne chose cette édition 64 bits. On pourra d'ailleurs noter l'humour du développeur principal :

      "I feel a bit sentimental about it all. It's weird, but I think I'm going to miss the hundreds of comments on every post gently requesting a 64-bit version. So don't be afraid to pop in with a "64-BIT NOW!!!1!!" comment every so often, you know, just for old time's sake."

      Source : http://blogs.adobe.com/penguin.swf/2008/11/now_supporting_16(...)
      • [^] # Re: Enfin...

        Posté par  . Évalué à 5.

        Ouai, ça fait un baille qu'Adobe a mis des restrictions à 2 balles sur son format, et depuis mai 2008, on avait une spec "ouverte" mais sans aucune indication sur les restrictions. Quand ça fait 10 ans qu'on en met, le jour où on les enlève, on le signale. Tout, dans l'annonce à la presse, et autres communiqués, sous entendait l'ouverture, mais tout au futur ("will ...") et sans aucun texte façon jursite, genre "Adobe ne vous fera pas chier si vous implémentez un player SWF", ce qui pour moi serait le minimum.

        Bon, j'allais encore gueuler sur le fait qu'on ne sait toujours pas si c'est vraiment ouvert, mais en fait, si : faut aller chercher au fin fond de la FAQ http://www.openscreenproject.org/about/faq.html

        Alors je veux bien que ceux qui gueulent soient chiants des fois, mais là les pro-Adobe ne font absolument _rien_ pour montrer que l'engagement de cette boite a l'air de changer un petit peu en faveur du libre^W^W de l'open source.
        • [^] # Re: Enfin...

          Posté par  . Évalué à 2.

          Ha oui, et ce lien est intéressant : http://www.openmedianow.org/?q=node/21
          C'est la réaction des devs de Gnash/swfdec.

          Ha, et aussi : le lien vers les précisions concernant les licences donne un 404 ... franchement, faudrait qu'ils fassent un petit effort.
        • [^] # Re: Enfin...

          Posté par  (site web personnel) . Évalué à 6.

          Avec toutefois un petit bémol :
          "What Adobe announced is the release of the SWF specification without the license agreement. The specification has never included a license to third-party technologies like codecs, which is still true today. Thus, developers of SWF-compliant applications are responsible for ensuring that their implementations do not infringe on the intellectual property rights of others, including those of codec providers."
          Ce qui n'est pas vraiment étonnant en soit, Adobe ne maîtrisant pas les codecs utilisés.
    • [^] # Re: Enfin...

      Posté par  . Évalué à 1.

      Trop tard, ça fait 6mois que je n'ai plus touché une goûte de Flash sur mon système.

      Je pense que niveau cevrage, c'est pas mal, non?

      à moins de le libérer, je n'y replongerais pas!
  • # la vraion raison

    Posté par  (site web personnel) . Évalué à 6.

    La vrai raison :
    "We chose Linux as our initial platform in response to numerous requests in our public Flash Player bug and issue management system and the fact that Linux distributions do not ship with a 32-bit browser or a comprehensive 32-bit emulation layer by default."
    ce qui se traduit par :
    Nous avons choisi Linux comme plateforme cible initiale en réponse aux nombreuses requêtes dans notre tracker, ainsi qu'au fait que les distributions Linux ne proposent pas de navigateur 32bits ou une couche d'émulation 32bits par défaut.

    Bref, si Linux est la cible initiale, c'est parcque c'est indispensable sur cette plateforme. Sous Mac ou Windows 64 bits, y'a pas le problème, le plugin 32 bits fonctionne.
    • [^] # Re: la vraion raison

      Posté par  . Évalué à 1.

      Faux problème, sous GNU/Linux le plugin 32 bits peut fonctionner sur une installation 64 bits, à condition d'avoir installé un navigateur 32bits avec les libs qui vont bien. Mais les deux peuvent tout à fait cohabiter si l'utilisateur en a vraiment besoin. C'est simplement que les distributions ne cherchent pas à alourdir leurs packets avec des versions 32/64Bits (à la MacOS avec leurs universal binaries qui sont une vraie hérésie) des libs et softs concernées pour un simple plugin flash propriétaire.
      • [^] # Re: la vraion raison

        Posté par  . Évalué à 5.

        C'est bien ce qui a été dis :
        >> ainsi qu'au fait que les distributions Linux ne proposent pas de navigateur 32bits ou une couche d'émulation 32bits par défaut
        • [^] # Re: la vraion raison

          Posté par  . Évalué à 1.

          J'utilisais une Slamd64 (portage de slackware) sur une machine machine x84_ 64 (avant sa mort prématurée, paix à son âme) et je n'ai jamais eu de souci avec le package firefox 32 bit fournis d'origine. Je crois bien que c'était le seul soft fournis dans cette version justement à cause du problème de flash.
          Bref il ne faut pas en faire une généralité, toutes les distributions ne proposent pas de navigateur 64 bit par défaut.
      • [^] # Re: la vraion raison

        Posté par  . Évalué à 4.

        Ou tout simplement avec nspluginwrapper, installé et activé par défaut à l'installation du plugin flash sur debian et ubuntu...
        nspluginwrapper est utile aussi pour faire tourner un plugin 32bits dans un navigateur 32bits, si on souhaite l'isoler pour qu'il plante son processus plutôt que le navigateur.
        • [^] # Re: la vraion raison

          Posté par  (site web personnel) . Évalué à 3.

          Pas étonnant que flash32 fonctionne sur un windows 64, en effet lancez internet explorer et regardez votre gestionnaire de taches et oh miracle l'internet explorer est une appli 32 bits :D

          (bon pour faire cette manip faut être équipé en win64, peu ici pourront le faire moi je l'ai remarqué au taffe ;))
          • [^] # Re: la vraion raison

            Posté par  (site web personnel) . Évalué à 1.

            On peut quand même lancer l'IE 64 bits en passant par le menu Démarrer.
            Le Windows Media Player par défaut aussi est en 32 bits, mais en installant un pack de codecs 64 bits et en modifiant une entrée de la base des registres, on peut le lancer en 64 bits.
            • [^] # Re: la vraion raison

              Posté par  . Évalué à 10.

              en installant un pack de codecs 64 bits et en modifiant une entrée de la base des registres, on peut le lancer en 64 bits.


              Quelle convivialité !!!
              • [^] # Re: la vraion raison

                Posté par  . Évalué à -2.

                Allez, pour nous rappeler que dans 4 jours, c'est trolldredi :
                Très franchement, je vois mal la différence avec une distrib linux classique…

                Mais bon, c'est prêt pour le desktop d'après certains.
              • [^] # Re: la vraion raison

                Posté par  . Évalué à -2.

                Pourquoi, c'est un probleme pour toi d'utiliser la version 32bits ? Quels sont les desavantages ?
                • [^] # Re: la vraion raison

                  Posté par  (site web personnel) . Évalué à 8.

                  Ben si jamais ton plugin a besoin d'allouer 13Go de mémoire vive, on sait jamais !
                  • [^] # Re: la vraion raison

                    Posté par  . Évalué à 4.

                    Ah tiens c'est uniquement la quantite de memoire que l'on peut utiliser le pourquoi on utilise des processeurs 64 bits... Je sais pas pourquoi mais je suis a peu pres sur qu'il y a d'autre problematique que la memoire et je suis aussi a peu pres sur aussi qu'un plugin flash, qui permet entre autre, de voir de la video HD peut avoir un grand benefice d'un passage en 64 bits pure.
                    • [^] # Re: la vraion raison

                      Posté par  . Évalué à -1.

                      Ah tiens c'est uniquement la quantite de memoire que l'on peut utiliser le pourquoi on utilise des processeurs 64 bits... Je sais pas pourquoi mais je suis a peu pres sur qu'il y a d'autre problematique que la memoire

                      C'est bien, tu vas pouvoir nous expliquer lequel...

                      et je suis aussi a peu pres sur aussi qu'un plugin flash, qui permet entre autre, de voir de la video HD peut avoir un grand benefice d'un passage en 64 bits pure.

                      Ca aussi tu vas pouvoir nous l'expliquer...

                      Pour t'aider:
                      a) il n'y a pas besoin d'avoir un systeme 64bit pour lire des fichiers de >4Gb
                      b) Les processeurs 32bit existant peuvent faire des operations sur des donnees 64bit(genre multiplier des entiers 64bit), comme les CPU 64bit
                      • [^] # Re: la vraion raison

                        Posté par  . Évalué à -2.

                        c'est pas parce que le 64-bit n'est pas d'Intel, donc que ça ne doit pas trop plair à Microsoft, qu'il faut faire exprès de passer pour un con. où alors tu l'es vraiment ??
                      • [^] # Re: la vraion raison

                        Posté par  . Évalué à 1.

                        Soyons bien clair: tu es donc en train de dire que la seule et unique raison des processeurs 64 bits et des OS 64 bits c'est le nombre d'adresse memoire?

                        Et juste pour le plaisir:

                        de tout de facon ton boss t'a bien dit que "640 Ko (environ 0.6 MO) devraient suffire a tout le monde" donc je comprend meme pas pourquoi vous en 32 bits pour windows...

                        :)
                        • [^] # Re: la vraion raison

                          Posté par  . Évalué à 0.

                          Oui.

                          Mais si tu as qqe chose qui prouve l'inverse, fais seulement hein... je suis toujours ouvert a apprendre des trucs nouveaux.
                        • [^] # Re: la vraion raison

                          Posté par  (site web personnel) . Évalué à 0.

                          Tiens pourquoi tu cherches pas par toi même ? Genre pourquoi tu vas pas sur wikipedia chercher l'article concernant le 64 bits ? Par exemple la rubirque "avantages" ?
                          Allez je t'aide, c'est par là :
                          http://fr.wikipedia.org/wiki/64_bits
                          Oui le passage de 32 bits à 64 bits indique juste un changement de la taille des registres manipulés par le processeur, ce qui n'a pas grand chose à voir avec les perfs de traitement.
                          Encore une fois, t'as perdu l'occasion de te taire.
                          • [^] # Re: la vraion raison

                            Posté par  . Évalué à 10.

                            "Accessoirement", le passage de x86 à x86-64 a à peu près doublé le nombre de registres disponibles (en plus d'en doubler la taille pour la plupart). Et ça, ça change énormément de choses pour les performances : à peu près deux fois moins d'accès nécessaires au cache, donc performances mémoire accrues. C'est notamment utile pour la lecture des vidéos HD, mais toutes les applications en profitent.

                            (voir par exemple http://www.hardware.fr/articles/478-3/amd-athlon-64-athlon-6(...) pour la liste des registres et leur modification)

                            (ça se voit d'ailleurs nettement en java, désolé je n'ai pas de benchmark objectif pour le montrer, mais c'est sensible).
                            • [^] # Re: la vraion raison

                              Posté par  . Évalué à 3.

                              (ça se voit d'ailleurs nettement en java, désolé je n'ai pas de benchmark objectif pour le montrer, mais c'est sensible).
                              Attention, si t'as fait ton test uniquement avec la JVM de Sun, as-tu bien utilisé la JVM server en x86 ?
                              En effet, Sun a décidé (pour une raison inconnue) de ne pas porter la JVM client sur x86-64. La JVM server consomme plus de mémoire vive, démarre les logiciels un peu plus lentement mais, en contrepartie, compile bien plus de bytecode en code natif.

                              Au passage tiens, pourquoi y'a besoin d'un plugin pour utiliser Java dans un navigateur web ? Dans Konqueror il suffit d'indiquer l'emplacement de Java...
                              • [^] # Re: la vraion raison

                                Posté par  . Évalué à 4.

                                La JVM server consomme plus de mémoire vive, démarre les logiciels un peu plus lentement mais, en contrepartie, compile bien plus de bytecode en code natif.

                                Ce n'est pas tout à fait exact. En fait, il y a des optimisations de code plus poussées et comparables à un compilateur statique dans HotSpot server. Par exemple, dans mon souvenir, HotSpot server fait une allocation de registres par coloration hiérarchique de graphe alors que HotSpot client utilise l'algo linear scan (variante de Poletto?). Une autre différence, je crois, c'est que hotspot server optimise au niveau super bloc (traces) alors que hotspot client le fait "juste" au niveau bloc de base. HotSpot server ferait aussi de l'inlining et de la spécialisation de méthode.
                            • [^] # Re: la vraion raison

                              Posté par  (site web personnel) . Évalué à 0.

                              "Accessoirement", le passage de x86 à x86-64 a à peu près doublé le nombre de registres disponibles
                              Oué bah oué les processeurs ont évolués au passage, mais c'est pas directement lié à la taille des registres sur 64 bits en soit, les processeurs évoluent généralement d'une génération à une autre hein :)
                              • [^] # Re: la vraion raison

                                Posté par  . Évalué à 4.

                                Et le soleil tourne autour de la terre aussi ?

                                Un bench on le fait sur le meme cpu en mode 32 et en 64... c'est le même processeur
                                • [^] # Re: la vraion raison

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Ben vas-y fait un bench en te contentant uniquement d'activer le support des registres 64 bits (pas autre chose hein, genre jeu d'instruction supplémentaire ou autre) et montre moi les résultats.
                                  Et encore, je suis même pas sûr que ce soit représentatif, vu que je suis pas sûr que le mode 32 bits soit implémenté comme le mode 64 bits sur le processeur.
                                  • [^] # Re: la vraion raison

                                    Posté par  (site web personnel) . Évalué à 4.

                                    Bon alors on va pas parler uniquement du support des registres 64bits vu que c'est complétement idiot étant donné que c'est loin d'etre la seule amélioration du x86-64 sur le x86, donc voilà un exemple très simple (et très con j'avoue):


                                    phh @ phh-desktop ~ % cat test2.c
                                    #include <stdio.h>
                                    #include <sys/time.h>
                                    #include <time.h>

                                    int main(int argc, char **argv) {
                                    long long i;
                                    struct timeval tv1,tv2;
                                    for(i=0;i<=1024*1024*1024;i++);
                                    printf("%lld\n", i);
                                    }
                                    phh @ phh-desktop ~ % gcc test2.c -o test2 -m32 ; time ./test2
                                    1073741825
                                    ./test2 4,68s user 0,00s system 99% cpu 4,699 total
                                    phh @ phh-desktop ~ % gcc test2.c -o test2 ; time ./test2
                                    1073741825
                                    ./test2 3,37s user 0,00s system 99% cpu 3,394 total

                                    Résultats reproductibles à moins de 10% de marge sur mon système (Core 2 Q6600 sur une kubuntu intrepid). En ce qui concerne les registres spécifiquement ca serait pas trop dur mais fastidieux à faire, m'enfin ca montre déjà que y a un gain à avoir (à moins que ce soit au niveau de gcc, mais j'ai essayé une paire d'options ca changeait rien à part -Ox qu'est trop intelligent)
                                • [^] # Re: la vraion raison

                                  Posté par  . Évalué à 4.

                                  Et le soleil tourne autour de la terre aussi ?
                                  Bah oui, dans le référentiel terrestre, le soleil tourne autour de la Terre.
                            • [^] # Re: la vraion raison

                              Posté par  (site web personnel) . Évalué à 2.

                              Le 64bit double aussi la taille des pointeurs. (Qui prennent donc plus de place en mémoire et dans le cache.)
                              • [^] # Re: la vraion raison

                                Posté par  . Évalué à 3.

                                Je crois que Donald Knuth a râlé à propos de ça, parce que la taille des pointeurs est inutile sur des systèmes avec moins de 4Go de mémoire RAM

                                lien : http://www-cs-faculty.stanford.edu/~knuth/news.html

                                traduction :
                                A Flame About 64-bit Pointers

                                Une diatribe enflammée à propos des pointeurs 64 bits

                                C'est absolument idiot de disposer de pointeurs sur 64 bits quand je compile un programme qui utilise moins de 4 gigabytes de mémoire vive. Lorsque des valeurs de pointeur de ce genre apparaissent dans une structure (NdT : structure type langage C je pense) , elles ne gâchent pas seulement la moitié de la mémoire vive, mais elles foutent également à la poubelle la moitié de la mémoire cache.
                                La page de manuel de GCC prévient qu'il existe une option "-mlong32" qui semble correspondre à ce que je veux utiliser. En effet, je pensais qu'elle allait compiler le code pour mon architecture x86-64, en utilisant les avantages des extra-registres (NdT : propres aux x86-64) etc, mais en permettant à mon programme d'exister dans un espace d'dressage virtuel de 32 bits. Malheureusement, l'option -mlong32 a été introduite pour les ordinateurs MIPS, il y a des années. Probablement qu'elle n'est jamais utilisée parce que les programmes qui sont compilés avec auront besoin d'être chargé avec une version spécial de la libc.

                                S'il vous plaît , quelqu'un. Essayez de transformer mon voeux en réalité.

                                NdT : Désolé pour la traduction approximative
                                • [^] # Re: la vraion raison

                                  Posté par  . Évalué à 2.

                                  En fait, tu voudrais une ABI ILP32 qui utilise un seul registre pour représenter un pointeur 64-bit? Cela n'avait pas été spécifié pour Linux. Des gens n'y voyaient pas vraiment d'intérêt à l'époque non plus pour prévoir cela au niveau CPU. Par contre, ce modèle est effectivement usuellement implémenté pour MIPS (pour se cadrer sur l'ABI N32 de SGI), ou IA-64 (mais HP-UX uniquement, pas Linux).

                                  Pour x86_64, des patches existent je crois chez Code Sourcery pour VxWorks. Par contre, ça utilise le préfixe addr32 ce qui n'est pas recommandé (en termes de performances, selon les docs d'Intel).
                          • [^] # Re: la vraion raison

                            Posté par  . Évalué à 1.

                            Tu t'es trompe d'interlocuteur celui qui pose les questions quand au 64 bits c'est pbpg dans ce poste la

                            http://linuxfr.org/submit/comments,27503,983230,5.html#reply
                      • [^] # Re: la vraion raison

                        Posté par  . Évalué à 2.

                        Tu faisais mieux avant niveau arguments quand même...
                        Là tu joues à la provoc on dirait.
                        Quelques chiffres sur le 32 vs 64 bits :
                        - http://64-bit-computers.com/windows-vista-32-bit-vs-64-bit-b(...) sous windows vista (je vois venir le gnagna oui mais c'est pas forcément les mêmes pilotes ou une connerie de ce genre), 10% de bonux pour le 64 bits apparemment
                        - http://forums.amd.com/devblog/blogpost.cfm?threadid=93648&am(...)
                        Flemme de chercher plus en fait. Dans l'ensemble la compression et le multimedia s'en sortent considérablement mieux en 64 bits qu'en 32 bits... Bien sûr tout n'est pas blanc, sur phoronix on peut trouver un benchmark où, dans les jeux 3D, le 64 bits se prend quelques FPS dans la gueule...
                        • [^] # Re: la vraion raison

                          Posté par  . Évalué à 0.

                          C'est une comparaison 32bit x86 vs 64bit amd64 , la plus grande partie de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.

                          Mon point pour Albert etait de lui faire comprendre que simplement passer d'un CPU 32bit a 64bit n'amene rien si ce n'est un espace d'addressage plus large.

                          Un CPU 64bit qui n'aurait pas ces registres supplementaires(et c'est tout a fait concevable) n'aurait aucun autre avantage q'un espace memoire plus large.
                          • [^] # Re: la vraion raison

                            Posté par  . Évalué à -1.

                            Rattrapage aux branches detected.

                            Je pense que tous le monde aura compris que ton message http://linuxfr.org/comments/983230.html#983230 etait encore une tentative (joliment avorte) de me faire passer pour un con et de m'humilier. J'ai comme l'impression que il y a eu un leger retour de boomerang sur le coup...
                            • [^] # Re: la vraion raison

                              Posté par  . Évalué à 3.

                              Je te cites :

                              Ah tiens c'est uniquement la quantite de memoire que l'on peut utiliser le pourquoi on utilise des processeurs 64 bits... Je sais pas pourquoi mais je suis a peu pres sur qu'il y a d'autre problematique que la memoire

                              et la reponse est effectivement que la memoire (espace d'addressage pour etre precis) est reellement le pourquoi des CPU 64bit, il n'y a AUCUNE garantie qu'un CPU 64bit soit plus rapide qu'un CPU 32bit

                              L'objectif n'etait pas de te faire passer pour un con (tu y arrives tres bien tout seul quand tu veux), mais te faire comprendre que la difference entre 32bit et 64bit, c'est uniquement ca.
                          • [^] # Re: la vraion raison

                            Posté par  . Évalué à 4.

                            > C'est une comparaison 32bit x86 vs 64bit amd64 , la plus grande partie
                            > de ces perfs est due au fait que le l'amd64 a des registres en plus notamment.

                            Il y a aussi un avantage pratique (ou "stratégique"), non inhérent aux spécificités du x86_64, mais dû au champ d'utilisation du IA32 (et à son âge).

                            Dans le cas spécifique des distributions Linux (et je suppose que ça doit être aussi vrais pour certains binaires distribués pour win32), les binaires x86 sont compilés en ciblant la compatibilité avec les vieux pentiums 686 - quand ce n'est pas carrément la compatibilité avec les 486 (par ex. chez Debian). Dans tout les cas, lorsque ce n'est pas explicitement demandé (-mcpu & co), et en 32bits, GCC produit des binaires qui peuvent tourner tels quels sur un 486.

                            Les jeux d'instructions et fonctionnalités ultérieurs aux vieux pentiums ne sont généralement que peux exploités dans les paquets binaires pour Linux (ie. seulement si c'est suffisamment modulaire pour être activé dynamiquement, et si le développeur les a écrit explicitement à la main). Si bien que certaines distributions, qui s'efforcent de conserver la compatibilité avec les x86 pré-pentiums, distribuent deux paquets distincts pour la libc (une "libc" tout court et une libc-i686). Mais ce procédé, couteux en temps de maintenance, n'a pas été généralisé aux autres paquets.

                            En revanche, tout les x86_64 supportent les jeux d'instructions supportés par les pentium4, dont le compilateur peut alors tirer partis sans affecter la compatibilité. Aussi, les binaires x86_64 (qui n'existent que depuis peu) affranchissent le compilateur de ce besoin de rétro-compatibilité avec des processeurs vieux de presque 20 ans. GCC peut s'efforcer, avec plus ou moins de succès, d'exploiter les instructions et fonctionnalités des CPUs x86 modernes.

                            Je ne crois pas que ça fasse une très grande différence pour un navigateur comme firefox cela dit. D'après le blog d'un développeur de flash, ça ne change rien pour flash non plus, dans la mesure où les développeurs de ce logiciel écrivent eux même à ma main les parties critiques en assembleur optimisé modulairement selon les jeux d'instructions disponibles à l'exécution (ce qui fait, au passage, qu'il leur a fallu beaucoup de temps pour faire ce port x86_64 de flash).

                            Donc dans ce cas précis on peux supposer qu'il est peu probable qu'un flash 64 bits améliore les performances (en termes d'efficacité CPU uniquement, parce qu'être obligé d'avoir sur disque et chargé en mémoire les libs 32 bits, c'est quand même du gachis de ressources à mon gout). Mais en pratique, et dans le cas d'une distribution Linux, on ne peux pas généraliser ce constat en disant que le 64bits n'apporte aucun autre gain qu'un plus grand espace d'adressage.

                            Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
                            • [^] # Re: la vraion raison

                              Posté par  . Évalué à 1.

                              Et je ne sais pas vous mais je vois malheureusement venir à grands pas le jour où firefox utilisera régulièrement plus de 3 Go de ram /o\
                              Suffit de continuer à utiliser nspluginwrapper pour isoler Flash de Firefox. J'ai diminué comme ça de 40% la mémoire utilisée par Firefox sur ma machine....
                              • [^] # Re: la vraion raison

                                Posté par  . Évalué à 3.

                                Le plugin utilisera toujours autant de RAM qu'il soit exécuté via le browser en direct ou via nspluginwrapper. i.e. ce que tu économises dans Firefox, tu le retrouves dans le process de nspluginwrapper. Idem en terme d'occupation CPU, c'est juste que tu le vois plus facilement via nspluginwrapper vu que c'est un autre process...
                                • [^] # Re: la vraion raison

                                  Posté par  . Évalué à 2.

                                  Certes, mais là au moins tu peux le tuer pour libérer de la RAM, t'es pas obligé de redémarrer le navigateur.
                        • [^] # Re: la vraion raison

                          Posté par  . Évalué à 2.

                          il y a aussi plus de sécurité avec le mode x86-64. Par exemple, les pages mémoire exécutable ne sont vraiment plus accessible en écriture.

                          Surtout, ça simplifie la conception de CPU plus performant à terme.
                  • [^] # Re: la vraion raison

                    Posté par  . Évalué à 2.

                    Il y a un port d'OpenOffice pour Flash ?

                    Ok, je --> []
                  • [^] # Re: la vraion raison

                    Posté par  (site web personnel) . Évalué à 6.

                    > Ben si jamais ton plugin a besoin d'allouer 13Go de mémoire vive, on sait jamais !

                    Vista aura tout bouffé avant....


                    ~~~~> []
                • [^] # Re: la vraion raison

                  Posté par  . Évalué à 4.

                  La n'est pas le problème ... Ce qui m'amuse c'est de voir les critiques envers Linux comme quoi c'est pas convivial, que c'est un OS d'un autre temps, etc ..... et de devoir modifier une entrée de la base de registres pour pouvoir profiter du mode 64 bits ....

                  Mais si tu veux, oui ça me pose problème d'utiliser un soft en mode 32 bits sur une archi 64 bits. Tout simplement parce que mon archi 64 bits je l'ai payée et que j'aimerauis en profiter ...
                  Avec un linux ou BSD, j'en profite sans problème.
                  • [^] # Re: la vraion raison

                    Posté par  (site web personnel) . Évalué à 1.

                    et de devoir modifier une entrée de la base de registres pour pouvoir profiter du mode 64 bits ....
                    mais le péquin moyen qui veut du convivial il en a rien à branler d'avoir un navigateur web en 64 bits. La convivialité, c'est lui proposer par défaut un navigateur qui va faire fonctionner la majorité des plugins qu'il va trouver sur le net.
                    • [^] # Re: la vraion raison

                      Posté par  . Évalué à 2.

                      Nan, la convivialité c'est de ne pas devoir chercher de plugins sur le net.
                      • [^] # Re: la vraion raison

                        Posté par  (site web personnel) . Évalué à 2.

                        Ben ca tombe bien, la plupart du temps tu cliques sur le lien à l'emplacement du plugin et il te propose le téléchargement/installation, pas besoin de chercher.
                        Après tu vas me dire qu'on devrait pas avoir à cliquer, moi je te répondrais qu'il me paraît indispensable que l'utilisateur soit conscient qu'il va installer du code exécutable avec des droits potentiellement dangeureux sur ta machine. oui, sécu et convivialité font pas toujours bon ménage.
                        • [^] # Re: la vraion raison

                          Posté par  . Évalué à 1.

                          C'est pour ça qu'il faut éviter autant que possible les plugins sur les pages web. Heureusement, certains webmestres commencent à s'en rendre compte, ça fait longtemps que j'ai plus vu de site web avec un menu en flash par exemple...
    • [^] # Re: la vraion raison

      Posté par  . Évalué à 4.

      > ainsi qu'au fait que les distributions Linux ne proposent pas de navigateur 32bits ou une couche d'émulation 32bits par défaut.

      Chez Red Hat/Fedora, il y a le support 32bits pour 64bits depuis RH9 (bref, c'est très vieux).
      Par contre, Fedora n'installe plus le support 32 bits depuis F9 ou F10 (depuis F10 c'est sûr). NB: il est toujours là, mais il n'est plus installé par défaut.

      Enfin, depuis F8 il y a un "truc" pour utiliser des plugins 32 bits sur Firefox 64 bits.

      Bref, pas de quoi se plaindre.
  • # et d'un !

    Posté par  (site web personnel) . Évalué à 4.

    Manque plus que le plug-in Java en 64 bits et on sera plus obligé d'installer un Firefox 32 bit en plus de la version 64.
  • # Philosophie

    Posté par  (site web personnel) . Évalué à 0.

    > Ils expliquent que le 64 bits s'est développé plus rapidement sous linux que sous les autres OS, notamment grâce à la philosophie de recompilation à partir des sources.

    Ah ouais, quand meme !
    C'est vrai que moi, sur mes autres OSs, tout marche mal car je recompile a partir de mouchoirs usagés.

    Nan, mais c'est quoi cette raison de merde ? Sous Windows aussi on recompile les logiciels pour les tester ! Sous BSD aussi !

    Puis s'ils avaient utilise' un vrai langage avec REPL (Scheme, CL, OCaml), ils auraient pu aller encore plus rapidement sans attendre de devoir recompiler tout le projet a chaque fois (les trois langages cités peuvent aussi au final se compiler tres efficacement, pour une aise de developpement incomparable)

Suivre le flux des commentaires

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