Journal Pierre Tramo 2.0

Posté par .
Tags : aucun
12
24
août
2012

Bonjour les gens.

Au hasard de ma veille technologique bi-semi-horaire quotidienne de la semaine, je tombe sur ce magnifique message sur la liste de diffusion du noyau.

Pour faire simple, une personne propose tout simplement de retirer la prise en charge de l'architecture x86 (NdM : 32 bits) car "cela économiserait des ressources aux développeurs du noyau, des compilo, machines virtuelles et applications"

Le troll nourri, on y voit des messages faisant référence au pilote binaire nvidia ainsi qu'à des projets "open source" comme Oracle Java ou Google Chrome

La personne en question finissant même par se décrire comme un (lead architecte ?) développeur de GUI en java et c++

Et là, je me dit juste que ça n'est pas possible, ce type est un troll délibéré, il ne peut pas ne pas le faire exprès…
D'après vous ? j'ai la berlue ou bien notre Pierre Tramo national a un fils caché aux states ?

  • # x86 32bits [:aloy]

    Posté par . Évalué à 2.

    s/x86/& 32 bits/

    • [^] # Re: x86 32bits [:aloy]

      Posté par . Évalué à 1. Dernière modification le 24/08/12 à 15:37.

      oui, x86-32 serait plus correcte.

      Et dans l'exitation du message, j'ai même oublié de parler de la référence à windows 9, et j'ai laissé une coquille…
      à un fils -> a un fils caché (a sans accent)

      • [^] # Re: x86 32bits [:aloy]

        Posté par . Évalué à 3.

        plutôt que Pierre Tramo, je dirais plutôt jvachez

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: x86 32bits [:aloy]

        Posté par (page perso) . Évalué à 5. Dernière modification le 24/08/12 à 16:09.

        x86-32 et x86 sont 32 bits (et sont deux archis distinctes si j'ai bien compris), x86_64 est 64 bits. J'ai ajouté la précision et corrigé.

        • [^] # Re: x86 32bits [:aloy]

          Posté par . Évalué à 3.

          Merci :)

        • [^] # Re: x86 32bits [:aloy]

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

          x32 c'est du x86_64 avec des pointeurs sur 32 bits, l'idée étant d'avoir le "meilleur des deux mondes".

          • [^] # Re: x86 32bits [:aloy]

            Posté par . Évalué à 0.

            Ça reste encore à prouver que garder des pointeurs sur 32bits fasse vraiment parti du "meilleur des deux mondes" (imo, sauf quelques cas particuliers, le meilleur des 2 mondes, c'est le 64 bits complet)

            • [^] # Re: x86 32bits [:aloy]

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

              De ce que j'ai compris, ça permet aux applications qui n'ont pas besoin d'adresser plus de 2 Go d'utiliser les registres en rab du 64 bit.

              • [^] # Re: x86 32bits [:aloy]

                Posté par . Évalué à 3.

                Oui, c'est exactement ça.

                Mais ce que je voulais dire, c'est que les situations où le gain est significatif par rapport à du 64 bits complet sont très rares.

                • [^] # Re: x86 32bits [:aloy]

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

                  Ça s'appelle donc x32, une annonce ici :
                  http://linuxfr.org/users/reno/journaux/x32-une-nouvelle-abi-linux-32-bits-pour-les-cpu-x86-64

                  Mais surtout des nouvelles dans la dépêche du kernel 3.4 :
                  http://linuxfr.org/news/sortie-officielle-du-noyau-linux-3-4#toc_9

                  A priori si ils le font c'est que dans certains cas c'est efficace, par exemple quand on tape beaucoup dans la mémoire :

                  D’après les premiers tests, postés sur le site spécialement dédié à x32, les performances semblent encourageantes.
                  Le test 181.mcf du banc d’essais SPEC CPU2000 a été utilisé car il est extrêmement dépendant de la mémoire, et il profite à fond d’une réduction de la pression sur le cache. Selon ce test, effectué sur un processeur Core i7, on obtient un gain de vitesse d’environ 32 % par rapport au mode x86-64. Comme prévu les performances sont très proches de celles de x86 (moins d’1 % d’écart).
                  Le gain induit par les pointeurs mémoire 32 bits est donc bien visible.

                  • [^] # Re: x86 32bits [:aloy]

                    Posté par . Évalué à 2.

                    C'est bien de ce truc de là dont je parlais, et je reste sur ma position : sauf cas très spécifiques, ça sert pas à grand chose et il vaut mieux miser sur 64 bits complet. Le bench que tu cites n'est absolument pas représentatif d'une utilisation normale.

  • # Je prends les paris

    Posté par . Évalué à 8.

    Il y croyait vraiment au début, parce qu'il n'a réellement aucune idée de quoi il parle. Au mieux, il a lu un article de vulgarisation (ou pas) qui parlait de X32, et en a conclu que "mais putain c'est l'avenir!!".

    Comme bon nombre d'imbéciles, il s'est convaincu qu'il était plus malin que les autres, a vu que MS allait abandonner l'archi dans sa prochaine version, et est venu faire son visionnaire sur la LKML en espérant que quelqu'un réponde "héééé, mais c'est pas con! pourquoi on y avait pas pensé avant??".

    Ensuite il est complètement largué par les explications des-uns et des-autres, sans compter que certains dévs sont peu diplomates (mais là, on les comprend!!). Du coup il se braque un peu et s'accroche à son idée que "vous êtes tous cons sauf moi!".

    La venue en douceur de son activité de développement ne vient pas renforcer l'idée qu'il savait ce qu'il faisait.
    "Je sais comment le noyau doit changer!
    -T'es développeur noyau?
    -Euh… non, je fais du Java et du C++, pour des GUI, mais je comprends parfaitement le problème, hein! Y'a un souci d'ABI qui…
    -Et donc, tu as un problème avec l'ABI? C'est curieux!
    -Ben en fait, je l'utilise pas vraiment, mais j'ai un super pote (bon, on se connait pas, mais si on se connaissait on serait super potes…) qui à coup sûr… enfin certainement… enfin peut-être… utiliser l'habit dont on parle là…"

    Enfin, le reste de ses réponses me fait penser qu'il essayait plus de sauver la face que son idée.

    Bref: pour nous, que du bonheur, mais je pense que certains dévs ont dû s'énerver un peu sur lui!

  • # Tiens ça me dit quelque chose

    Posté par . Évalué à 4.

    Quelqu'un propose de supprimer la prise en charge de x86 dans le kernel pour simplifier la gestion du code parce que la fonctionnalité n'est pas beaucoup utilisée ?
    Attendez, c'était pas le GUADEC il y a pas longtemps ?

    Bon, sérieusement, c'est marrant comme proposition sachant qu'il doit y avoir des archis supportés par Linux qui sont utilisées par 50 personnes dans le monde.

Suivre le flux des commentaires

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