Journal utilité du i386

Posté par  .
Étiquettes :
0
14
jan.
2007
Voilà, j'ai découvert récemment archlinux qui me plaît beaucoup, mais je ne vais pas rentrer en détail sur ce point ici.
Cette distribution est optimisé pour les processeurs 686. Certains diront que ce n'est pas bien parce que c'est rejeter des architectures (mais non je ne pense pas au débianiste).
J'ai installé Linux sur beaucoup d'ordi, dont des plus tout jeunes. Et bien je n'ai jamais utilisé d'architecture inférieur au i686.
Et c'est la que je me pose une question : pourquoi une distribution comme ubuntu ne compile-t-elle pas sa distribution en 686 vu que de toute façon, elle ne tournera pas (ou difficilement) sur un 386 vu que les carte-mère gérant de tel processeurs ne géraient déjà pas une grande quantité de mémoire (en edo en plus, ne pensais même pas rajouter une barrette de 256).
De plus je pense que celui qui va installer linux sur une telle machine va plutôt s'orienter vers une debian ou une slackware.

Voilà, c'est juste une question que je me posais et que je pose donc tout haut. Quelqu'un a-t-il une raison à cela ?

  • # Parce que

    Posté par  . Évalué à 6.

    C'est compilé en i386 parce que ubuntu, c'est juste un snapshot de debian, et que debian est compilé en i386* pour pouvoir tourner sur le plus de machines possibles.

    * et toutes les autres plates-formes supportées, qui ne concernent pas ce journal.

    • [^] # Re: Parce que

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

      AFAIK Debian ne supporte plus les i386 http://lists.debian.org/debian-devel/2003/04/msg02112.html

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Parce que

        Posté par  . Évalué à 2.

        Ni meme le kernel : IRRC i386 a besoin d'emulateur (je sais plus pourquoi), et le truc possait des pb de secu. Du coup il a ete virer vu que personne (ou que c'etait trop compliqué) a refaire.

        • [^] # Re: Parce que

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

          Je crois que la raison est la même que pour Debian. En fait, aujourd'hui, lorsqu'on dis 386 cela veut dire en pratique 486.

    • [^] # Re: Parce que

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

      Faut arrêter de délirer. Ubuntu reprend bien les packages source chez Debian, mais ils appliquent leurs propres patchs, et finalement tout est recompilé chez Ubuntu. Ils pourraient donc, s'ils le désirent, ne sortir que des packages optimisés i686.

      • [^] # Re: Parce que

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

        Debian tourne en 486 et non en 386 par défaut même si pour des raisons historique, il est écrit 386 sur les noms des archives.

        Comme il a été dis dans d'autres post, seules quelques applications ont vraiment besoin de profiter de l'optimisation du processeur et il y a en général une version binaire du paquet par architecture.

        Comme il n'est pas possible de faire cela pour tous les paquets, ni de multiplier les architectures matérielles, je pense qu'une des solutions possibles est celle aujourd'hui utilisé par le noyau : le remplacement de code à chaud lors du démarrage. Le noyau linux est déjà capable de s'adapter à la carte mère ainsi (voir le SMP pour le noyau 2.6.18). On peut très bien imaginer (en tout cas, je l'imagine très bien) avoir dans un même binaire plusieurs implémentations des parties critiques et que le code exécuté soit choisie automatiquement à chaud.

        • [^] # Re: Parce que

          Posté par  . Évalué à 4.

          c'est aussi fait par mplayer si on active la détection de l'architecture. Mais c'est pas vraiment du 'remplacement du code à chaud'. Amha c'est plus un bon ciblage des parties optimisés, et qq variables globales pour définir de quel style d'optimisation on a le droit.

          • [^] # Re: Parce que

            Posté par  . Évalué à 3.

            oui le remplacement de code a chaud c'est surtout utile pour retirer du code
            quand t'as un systeme monoprocesseur (tout ce qui est spin lock ... hop a la trappe). Sous Linux en dehors du noyau je ne vois pas d'autres applications qui pourraient en tirer parti.

  • # Qu'est-ce que ca change?

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

    Quelles ont été les évolutions depuis i386?
    Pas grand chose qui permette de dire que compiler en i686 est plus rapide que i386.

    Est qu'est-ce que le i686? En fait, si je regarde le man de gcc,
    http://www.hmug.org/man/1/gcc.php
    i686 = Intel PentiumPro CPU
    Tu en as vu beaucoup des Pentium pro? Pas moi.
    Après, tu vas devoir choisir entre AMD K6 ou K7, Intel P4 ou Core Duo, etc... hum. Pourquoi alors privilégier des vieuw Pentium Pro?

    Bref, le jour où on me montrera que compiler pour i686 est plus rapide que i386 sur un Intel Core 2 Duo et un AMD K7, peut-être que je compilerai moi-même en i686, mais pour le moment, ben... non, à part compiler pour toutes les architectures, le i386 reste le plus universel.

    • [^] # Re: Qu'est-ce que ca change?

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

      Peut-être parce qu'entre i386 et i686, il y a tout un tas de nouvelles instructions, qui sont dispos sur tout les processeurs ci-après, je pense donc que ça a de fortes chances d'optimiser au moins certaines applications.

      Je pense qu'utiliser ses instructions permettent de gagner aussi bien sur un core 2 que sur un AMD K7. Que le gain ne soit pas forcément le même entre les deux c'est quasi-forcé, mais je pense qu'il y a un gain. Sauf qu'à remplacer les nouvelles instructions par des blocs d'instructions équivalentes et dispos sur i386 permettent de gagner sur l'un des deux processeurs(se dont je doute tout de même, ce serait illogiques, mais pourquoi pas après tout...).

      • [^] # Re: Qu'est-ce que ca change?

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

        bah moi sur mon intel core2 duo, c'est en x86_64 :p (et oui j'ai dû repackager des backports donc j'ai effectivement recompilé).

        bon après, l'utilisation du x86_64 met en avant les limitations des logiciels avec java en dépendance (oui je pense à la compil' de OOo qui segfaulte à 98% de la compil') ou firefox dont le greffon java segfaulte méchamment (et vivement que gnash soit encore un peu plus abouti).

      • [^] # Re: Qu'est-ce que ca change?

        Posté par  . Évalué à 2.

        Je doute qu'actuellement (en 4.1) , GCC soit vraiment capable de profiter de ces différences de jeux d'instructions. GCC est réputé pour être un bon compilateur très généraliste (beaucoup d'architectures supportées) au détriment des optimisations pour chacun d'entre eux. De plus, depuis le i386, les instructions qui sont apparues correspondent à des besoins très particuliers surtout pour le calcul multimedia. A côté de ça, les instructions existantes très utilisées ont été optimisées au maximum ce qui fait que le même code s'exécute plus vite.
        Bref, je doute que GCC puisse facilement tirer parti de ces nouvelles instructions (même si l'après-4.1 devrait améliorer les choses mais sans vraiment utiliser ces instructions). Après, si on veut des optimisations Intel, il suffit d'utiliser le compilateur d'Intel qui ne compile pour les x86 !

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 2.

          Et n'utiliser le compilateur intel que pour les intels, pas pour les AMD ;-)

        • [^] # Re: Qu'est-ce que ca change?

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

          Bin oui, mais quand on parle de compiler toute une édition en i686, on parle de compiler aussi les applications multimedias. Le but n'est pas non plus d'optimiser bash ;).

          Et justement, une édition comme Ubuntu étant à destination du grand publique, elle doit donc être tournée multi-media.

          Après, on est d'accord, le gain est sans doute faible. La question est: est-il négligeable? Mais ce que l'auteur du journal disait, c'était que de toute façon, Ubuntu sur un Pentium n'est pas forcément génial, donc autant sauter le pas.

          Sinon, je suis d'accord, c'est surtout les instructions existantes qui sont optimisées. Parce qu'il faut bien que 4 jours avant la sortie du proc, les benchs en mettent au maximum plein la vue. Et puis bon, tout le monde n'a pas la chance d'utiliser Gentoo.

          • [^] # Re: Qu'est-ce que ca change?

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

            Les applications multimédia (couche bas-niveau) il n'y en pas pas des milliers et les applications scientifique non plus. Par exemple, pour la bibliothèque fftw on trouve trois versions spécialisé sur debian : p4fftwgel2, k6fftwgel2k et k7fftwgel2. Avec l'une de ces versions, j'ai vu un code tourner 5 fois plus vite. Cependant, ce cas de figure est rare. Il suffit donc d'avoir quelques bibliothèques optimisés et cela suffit. Je ne sais pas ce que vous faisez de votre machine mais mon expérience personnel montre que globalement un PC aujourd'hui ne fait rien (sauf ponctuellement). Il n'y a donc pas intérêt à complexifier les distributions pour des programmes comme bash.

            Je me souviens un bench il y a quelques années qui comparait la gentoo à la debian compilé pour 386. Globalement la debian allait plus vite que la gentoo (sauf quelques bench) ce qui m'avait pas mal surpris mais pas déplu ;-)

            Il vaut voir qu'a chaque fois qu'on change les paramètres de compilation, les bogues ne sont pas toujours reproductibles. C'est bien de compiler avec plusieurs compilateurs et plusieurs jeux de paramètres mais il faut encore pouvoir ensuite maitriser son Bogue Tracking System et arriver à en faire quelque chose.

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 5.

          De plus, depuis le i386, les instructions qui sont apparues correspondent à des besoins très particuliers surtout pour le calcul multimedia.
          Il n'y a pas que le jeu d'instruction qui compte m'ai aussi leur performance et l'ordonancement.

          Sur certaines familles il peut etre plus interresant de faire des additions avec l'instruction X alors qu'avec une autre famille il faut mieux utiliser l'instruction Y.

          D'ailleurs gcc propose ce choix : compiler avec un jeu d'instruction donné en optimisant pour une archi.

    • [^] # Re: Qu'est-ce que ca change?

      Posté par  . Évalué à 3.

      C"est perninent en effet, mais l' architecture P6 (pentium pro, I686), est quasi-universelle en desktop/laptop/serveur.
      Pourquoi dans l' architecture PC (X86) devraient on ce contenter du i386 ?
      La Mandriva ( mandrake ) en i586 a donné une premiére impulsion. Qui irait installer une "ce que vous voulez" sur un pentium 75 ?
      Gael tu as eu une trés bonne idée la dessus

      Les seules distributions utilisable pour ce type de machines sont dédiées . Et je suis optimiste.
      Maintenant, il faut être clair : on ne passe pas son temps a traiter des données en 64 ou 128 bit. Le I386 est encore nettement suffisant pour beaucoup d ' application.
      Il y a un juste compromis a trouver.....

    • [^] # Re: Qu'est-ce que ca change?

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

      Par expérience, pour avoir déjà recompiler des distributions complètes sur PowerPC et sur ix86, je confirme qu'optimiser la compilation pour le processeur cible apporte un gain de performance non négligeable.

      Si tu pense qu'un i386 est équivalent à un Core 2 Duo, libre à toi. le ridicule ne tue pas !

      Il serait temps qu'aujourd'hui les distribs "grands public" soit optimisé pour les CPUs récent et exploite leurs nouvelles instructions, en particulier les instructions vectorielles MMX et SSE*. Utiliser l'auto-vectorization de GCC ne coute rien et rapporte beaucoup !

      Et demain, avec la généralisation des architectures multi core, l'auto-parallelisation du code est là aussi une fonctionnalité de GCC a activer, qui ne coute rien et rapporte beaucoup.

      • [^] # Re: Qu'est-ce que ca change?

        Posté par  . Évalué à 2.

        Je ne connais pas grand chose à l'optimisation, mes notions d'assembleur sont vraiment légères, et je ne suis pas programmeur, mais il me semble que les jeux d'instructions mmx, sse, etc., par exemple, sont largement orientées pour certains types d'applications.
        Ma question est donc: est-il pertinent d'y avoir recours pour tout type d'applications, ou justement de ne s'en servir que là où ils sont réellement efficaces?

        Ca prendrait un temps fou et nécessiterait des connaissances techniques bien au-delà des miennes, mais un test à faire:
        - prendre une debian (on n'est pas vendredi, mais en Chine les trolls, c'est tous les jours :D) standard, avec les paquets 586 ou 686 quand ils sont dispos
        - recompiler intégralement tous les paquets de la debian ci-dessus, pour une utilisation bureautique/loisirs/ce-que-vous-faites-de-votre-ordi

        et faire une série de tests pour voir si on sent vraiment une différence
        (je précise que je ne m'intéresse pas aux benchs genre "on voit bien que A prend 3ms et B 7ms pour faire blablabla", parce que moi, entre 3ms et 7ms, j'ai besoin d'être vachement concentré pour espérer sentir la différence sur une opération ponctuelle)

        Bon! Personne ne va le faire (certainement pas moi d'abord!)! Donc, on n'a aucune information objective pour démontrer qui a raison et qui a tord!

        A VOS TROLLS! :D

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 2.

          Le plus simple, c'est encore de prendre une gentoo... Elle est faite pour être recompilée ;-)

          D'ailleurs, c'est un débat qui a déjà eu lieu maintes et maintes fois à propos de cette distrib' : gagne-t-on vraiment beaucoup en recompilant tout ? Je n'ai jamais eu de véritable réponse...

          En tout cas pour ma part, le temps perdu à recompiler le compense pas le temps gagné à l'exécution !

          • [^] # Re: Qu'est-ce que ca change?

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

            Oui mais non!
            Les patchs et les configurations entre une debian et une gentoo n'ont rien à voir !
            Faut comparer une debian avec une debian ou une gentoo avec une gentoo, sinon ca voudra rien dire...

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 2.

          Ce test a déjà été fait, et alors, chose incroyable, Debian i386 se revèle plus rapide que gentoo en moyenne. Amusant ;-)

          http://linuxfr.org/2003/08/13/13629.html

          • [^] # Re: Qu'est-ce que ca change?

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

            ...Et après, mon commentaire initial sur le sujet (comme quoi compiler en i686 c'est pas mieux que compiler en i386, donc pas d'interet spécialement de diffuser du i686) se fait moinsser, pas mal... Faudra m'expliquer pourquoi, il me semble que je n'avais pas si tord que ça...
            Mais bon, passons!

      • [^] # Re: Qu'est-ce que ca change?

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

        Utiliser l'auto-vectorization de GCC ne coute rien et rapporte beaucoup

        J'aimerais bien voir des bench pour confirmer ça (perso j'y crois pas -- lui non plus: http://gcc.gnu.org/ml/gcc/2007-01/msg00288.html )

      • [^] # Re: Qu'est-ce que ca change?

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

        Euh, il me semblait que PPC était justement hyper sensible aux optimisations. Du genre, une bête compilation linéaire du code pouvait être bien moins performante qu'une réorganisation équivalente de celui-ci, mais exploitant les spécificités(sans même parler des instructions).

        Côté x86, j'ai l'impression que la multiplication des architectures pousse ce travail de réorganisation du code au niveau du processeur plutôt qu'au niveau du compilo, ce qui est bien dommage car cela joue sur le coût du processeur et sur sa consommation.

        Quelqu'un peut confirmer?

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 2.

          Euh, il me semblait que PPC était justement hyper sensible aux optimisations.
          Comme toutes machines RISC, ou chaque instruction fait qu'une chose et c'est au compilo de se debrouiller pour les mettres quand il faut en tenant compte des specificité de la machine.

      • [^] # Re: Qu'est-ce que ca change?

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

        Par expérience, pour avoir déjà recompiler des distributions complètes sur PowerPC et sur ix86, je confirme qu'optimiser la compilation pour le processeur cible apporte un gain de performance non négligeable.

        Des preuves, je veux des preuves!
        J'arrete pas d'entendre les gens dire "c'est plus rapide", "c'est plus lent", jamais sans benchs
        Ah si : j'ai vu quelques benchs, tous donnaient un gain de perfs négligeable, voir négatif, alors bon... J'ai plus les URLs sous la main, zut, mais voila, j'en garde le souvenir que compiler avec GCC en i386 ou autre, ca ne change pas grand chose...
        Apportez des preuves SVP!

      • [^] # Re: Qu'est-ce que ca change?

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

        Si tu pense qu'un i386 est équivalent à un Core 2 Duo, libre à toi. le ridicule ne tue pas !

        Je n'ai jamais dit ca, tu détournes mes dires pour te faire plaisir.
        un Core 2 Duo va optimiser le code i386 à l'exécution, et au final le gain est nul. Depuis le i386, il n'y a pas eu de nouvelle instructions fulgurantes qui accelere autre chose que le multimédia, ce qui a changé est l'optimisation des instructions existantes.
        D'ou le gain quasi nul de la compilation en autre que i386.
        Maintenant, si tu peux m'apporter des preuves, en tous cas le troll de LFS ou Gentoo montre que ce n'est pas si évident que tu sembles vouloir le croire...

        • [^] # Re: Qu'est-ce que ca change?

          Posté par  . Évalué à 2.

          Maintenant, si tu peux m'apporter des preuves, en tous cas le troll de LFS ou Gentoo montre que ce n'est pas si évident que tu sembles vouloir le croire...
          Ben ecoute dans un stage, on était sur des xeon HT 3Ghz.
          On a fait certains test de calcul scientifique, et entre gcc et icc on obtenait plus de 20% de perfs sur certains code.

          Alors ensuite en restant tout le temps sous gcc je sais pas, mais en optimisant pour l'archi lors de la compilation, sisi on peut gagner bcp !

          • [^] # Re: Qu'est-ce que ca change?

            Posté par  . Évalué à 3.

            On a fait certains test de calcul scientifique, et entre gcc et icc on obtenait plus de 20% de perfs sur certains code.

            Alors ensuite en restant tout le temps sous gcc je sais pas, mais en optimisant pour l'archi lors de la compilation, sisi on peut gagner bcp !

            Rien a voir, donc. Ca prouve juste que icc est un meilleur compilo que gcc, ce qui n'est pas franchement nouveau et est completement orthogonal au fait de compiler pour i386/i486/i586/i686.

            Cela n'empeche que pour certaines applications, passer les bons parametres a la compilation peut effectivement apporter un gain en perf non negligeable pour certaines applis, scientifiques ou multimedia entre autre, via l'utilisation du MMX, SSE, etc... Encore faut-il que le compilo reussisse a reperer les cas ou il peut s'en servir, ce qui est loin d'etre evident.

            Apres on peu aussi jouer sur le scheduling et les temps de latence des instructions pour grapiller encore un peu ; mais on arrive au point ou il faudrait de toute facon recompiler les applis soi-meme, donc pas pour une distro binaire.

            Plus ou moins dans le meme sujet, j'ai relu hier un article[1] sur l'Itanium et les difficultes d'optimisations avec. Pour un appel systeme L4, le compilo arrivait a 508 cycles. Apres pas mal de boulot et d'assembleur ecrit a la main, ils sont descendus a 36 cycles...

            [1] http://www.usenix.org/events/usenix05/tech/general/gray/gray(...)

            • [^] # Re: Qu'est-ce que ca change?

              Posté par  . Évalué à 2.


              Rien a voir, donc. Ca prouve juste que icc est un meilleur compilo que gcc, ce qui n'est pas franchement nouveau et est completement orthogonal au fait de compiler pour i386/i486/i586/i686.

              Donc on peut pas prendre les optimisation de gcc suivant l'archi comme montrant qu'on ne peut rien gagner, vu que tu dis toi meme que c'est un 'mauvais compilo' , il fait donc pe mal ces optimisations ;)

              ps icc permet aussi de spécifier l'archi . Je serais curieux de savoir si la aussi on 'gagne rien' ou pas.

              • [^] # Re: Qu'est-ce que ca change?

                Posté par  . Évalué à 2.

                Donc on peut pas prendre les optimisation de gcc suivant l'archi comme montrant qu'on ne peut rien gagner, vu que tu dis toi meme que c'est un 'mauvais compilo' , il fait donc pe mal ces optimisations ;)

                J'ai pas dit qu'il etait mauvais mais qu'il etait moins bon. Et ca ne veut pas dire que les optimisations ne sont pas valides. Il me semble meme que pour l'Itanium, a une epoque, gcc etait meilleur sur cetains aspects, et icc sur beaucoup d'autres. Pour faire une analogie avec mon boulot, ce n'est pas parce qu'une F1 (la RB2 en l'occurence) a une aerodynamique pas terrible que passer a une boite seemless shift ne peut pas nous faire gagner 2 dixiemes au tour.

                ps icc permet aussi de spécifier l'archi . Je serais curieux de savoir si la aussi on 'gagne rien' ou pas.

                Je n'ai pas dit qu'il n'y avait rien a gagner, hein. Les problemes des optimisations au-dela du 486, en gros, c'est que :
                -MMX, SSE, etc... c'est pas des instructions triviales, pour que le compilo reussisse a retrouver ses petits, c'est pas gagne. C'est pas pour rien que les mecs se font de sbouts en assembleur...
                -si on fait abstraction des differences de jeux d'instructions, on joue sur leur scheduling, ce qui veut dire qu'on va privilegier une arch plutot qu'une autre. C'est assez genant quand on a des differences aussi fondamentales qu'entre P3, P4 et K7 (surtout le P4). Mais quand on arrive a ce stade-la, je doute que les differences soient vraiment perceptibles pour les applis classiques ; donc j'aurais tendance a penser que effectivement ca vaut le coup pour les applis de calcul vraiment intensives, mais pour le reste...

        • [^] # Re: Qu'est-ce que ca change?

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

          Juste quelques exemples

          Avec le bench Polyhedron
          Sur un Athlon XP 1900+ (avec g95, le dernier gfortran de la FC6 ayant un bug sur ix86)
          i386 == 1629s (-O2 -mtune=i386)
          athlon-xp == 1551s (-O3 -march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse,387)

          Sur un Opteron 285 où par défaut gcc utilise déjà mmx, sse, sse2 en 64 bits avec gfortran
          x86_64 == 569s (-O2)
          amd64e == 535s (-O3 -march=opteron -msse3)

          Alors oui, ça vaut le coup d'optimiser sa compilation pour le processur cible.

          Juste pour info, avec pgf90 6.2, le bench dure 439s... gfortran a encore de la marge pour gagner en optimisation...


          Ensuite, concernant le gain sur une distrib complète avec les mêmes versions de logiciels bien sûr...
          avec 500 itérations de gtkperf
          Fedora Core 6 == 142s
          Gentoo optimisé == 117s

          Encore une fois ça vaut le coup d'optimiser une distrib à la compil !!

          Sinon on peut vraiment se demander à quoi ça sert que les fondeurs se décarcasse à sortir des nouvelles fonctions à leur CPU, ou encore que les devs de GCC continue à bosser !!

          Sur certains codes scientifiques faisant un usage considérables de matrices, les gains, lors de l'utilisation des instructions vectorielles et des fonctions spécifiques du CPU, peuvent être phénoménaux...

          • [^] # Re: Qu'est-ce que ca change?

            Posté par  . Évalué à 6.

            i386 == 1629s (-O2 -mtune=i386)
            athlon-xp == 1551s (-O3 -march=athlon-xp -mmmx -m3dnow -msse -mfpmath=sse,387)
            [...]
            x86_64 == 569s (-O2)
            amd64e == 535s (-O3 -march=opteron -msse3)

            Tu aurais le bench avec le meme niveau d'optim pour les differents cas ? Parce que la, on ne sait pas si ce qui ameliore les perfs c'est le -O3 ou les autres flags. Bref, ton bench vaut 0 comme comparaison pour le sujet qui nous interesse.

          • [^] # Re: Qu'est-ce que ca change?

            Posté par  . Évalué à 4.

            Tu utilises O3 à la place de O2 lorsque tu compiles en spécifiant l'architecture...

            Dans certaines grosses applications, le code généré par le compilateur peut-être plus volumineux lorsque tu optimises, et ça peut dégrader les perfs.

            J'ai du mal à croire que les différences dans les résultats obtenus avec gtkperf ne soit due qu'aux flags de compil.

      • [^] # Re: Qu'est-ce que ca change?

        Posté par  . Évalué à 4.

        Les benchmarks montrent que dans une utilisation courante, il y a déjà très très peu de différences entre une distro 32 et 64 bits. Alors franchement, tout recompiler en 686..

  • # Tout le monde optimise pour i686

    Posté par  . Évalué à 5.

    Tout le monde optimise pour i686 mais n'utilise que le jeux d'instruction i386. Si ça présente un intérêt d'avoir du i686, alors il y a un paquet spécifique.
    Exemple (système rpm) :
    $ rpm -q --queryformat "%{NAME} %{ARCH}\n" glibc
    glibc i686

    Ça ne peut tourner que sur i686.

  • # lowarch

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

    si tu veux une arch mais pour les machines plus anciennes :
    http://www.lowarch.org/

    voilà

  • # En cours

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

    Le noyau par défaut (-generic) est deja optimisé pour les 686.

    Pour les applis il y a parfois des versions 686 (ardour, libc) mais il est vrai que vu la lourdeur d'ubuntu, même pour son dérivé xubuntu il y a peu de chances que les utilisateur de 386 utilisent cette distrib.

  • # Embarqué

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

    Je rappelle aussi que le jeu d'instruction i386 ne correspond pas qu'aux processeurs Intel 80386. Pas mal de processeurs embarqués (les Via il me semble) ne gèrent que les instructions i386, pas les plus récentes.
    Donc pour de l'embarqué, ça a du sens (les packages binaires sont directement réutilisables)

    • [^] # Re: Embarqué

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

      les via (c5) c'est du 686 avec quelques instructions non supportées... Je peux te dire avec fiabilité que i585 passe!!! mais il n'y a pas de package debian :( ....

  • # Merci pour tout ces commentaire

    Posté par  . Évalué à 10.

    premier point que je vois :

    -- les optimisations sont-elles utiles ?
    Quand je me posais cette question, je ne pensais pas à des jeux d'instructions super-spécifique, mais à des choses plus basique tel que le mmx.
    Je ne sais pas exactement ce qu'apporte ce jeux d'instruction, ni même à partir de quand il apparaît (486, 586, 686 ?). J'ai juste souvenir qu'à ça sortie, c'était un truc qui devait tout accélérer, mais bon, ce n'était peut-être que marketing.

    -- l'utilisation de vieux matériel
    Je parle ici des distributions « grand publique », et quand on vois les ressources demandé, j'ai l'impression qu'une ubuntu, mandriva, suse, etc... n'est tout simplement pas installable sur du matériel pré-686.

    -- le rapport :
    Cela n'apporte peut-être pas grand chose de compiler pour du 686. Mais dans ce cas, cela voudrait-il dire que depuis les 386, tout les jeux d'instructions qui sont implémenté dans les processeurs (mmx, sse...) ne sont que marketing et ne servent pas à grand chose ?
    Après, même si le gain est négligeable : quelle utilité de garder une compatibilité avec du matériel qui de toute façon ne peut tourner avec, donc qu'est-ce que ça coûte d'optimiser ?
    Pour ce qui est de la remarque de l'embarquer, je ne pense pas que pour ce type de matériel, on utilise le type de distribution visé ici.

    • [^] # Re: Merci pour tout ces commentaire

      Posté par  . Évalué à 1.

      Le MMX n'est pas qu'un effet de manche marketing. Les instructions SIMD (Single Instruction, Multiple Data) comme celles du jeu MMX permettent de réaliser la même opération sur plusieurs données en parallèle, et ce de façon atomique par nature. Utilisé judicieusement (par exemple pour des calculs sur des pixels), ça peut doubler/tripler les performances, et ça peut être une manière aisée de paralléliser certains traitements sans utiliser de threads.

      'fin sinon, avec un ami on avait dû tester un noyau compilé pour i386 sur une machine, et tout était vraiment plus lent qu'avec un noyau optimisé pour l'architecture réelle. Je ne sais pas si l'impact est aussi important en userland, mais en tout cas ça influe très fortement les perfs du kernel. Dans tous les cas, Slackware est entièrement compilée avec "-O2 -march=i486 -mtune=i686" et c'est la distribution la plus rapide que j'ai utilisé (à l'époque, Slackware 9.1 comparée à Mandrake 9.2, Red Hat 9 et une vieille Debian).

      • [^] # Re: Merci pour tout ces commentaire

        Posté par  . Évalué à 3.

        un noyau compilé pour i386 sur une machine, et tout était vraiment plus lent qu'avec un noyau optimisé pour l'architecture réelle
        Cf le lien sur la ml de debian plus haut. i486 apporte des chose en plus pour le noyau (operations atomiques (utilisé pour les verous), ...).
        La difference entre i486 et les autres apporte beaucoup moins.

    • [^] # Re: Merci pour tout ces commentaire

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

      cela voudrait-il dire que depuis les 386, tout les jeux d'instructions qui sont implémenté dans les processeurs (mmx, sse...) ne sont que marketing et ne servent pas à grand chose

      Elles servent, mais que pour des besoins spécifiques. Par exemple pas de super-effet psychédéliques avec les mods visuels pour la musique, car il y a besoin de calculs bourrins parallélisables, et la MMX et SSE sont rois (multiplier les perfs par 2 voire 3, ça aide pour le framerate).
      Maintenant, si Apache était plus rapide en i686/MMX/SSE3 qu'en i386 pour un serveur web, ça se saurait...

      • [^] # Re: Merci pour tout ces commentaire

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

        > Maintenant, si Apache était plus rapide en i686/MMX/SSE3 qu'en i386 pour un serveur web, ça se saurait...

        Ben ça se sait !! En particulier lorsqu'on utilise https...

        • [^] # Re: Merci pour tout ces commentaire

          Posté par  . Évalué à 3.

          C'est d'ailleurs pour ca qu'Apache utilise la libssl, qui peut gerer du code conditionel, et utiliser en fonction de ce qu'il trouve, du code optimise pour i386/i486/Pentium(1,2,3)/K7, avec ou sans MMX, et du code optimise a la main en assembleur. (C'est en tout cas comme ca que ca marche dans la lib distribuee par Debian).

    • [^] # Re: Merci pour tout ces commentaire

      Posté par  . Évalué à 0.

      Les instructions SIMD ne sont pas du tout inutiles !
      Pour l'arrivée de chaque technologie, ca doit être :
      - MMX : avec le Pentium du même nom
      - SSE : avec le P3 (il me semble)
      - SSE2 : avec le P4

      Je peux te dire que sans MMX et consorts, tu ne pourrais lire aucune vidéo à plus de 2 fps, ni jouer à aucun des jeux modernes, ni avoir un Xorg à peu près rapide dès qu'on mélange un peu plus que des carrés de couleur unie.
      Tu ne les "vois" peut-être pas au jour le jour, car la plupart des opérations qu'on trouve "lentes" aujourd'hui, c'est quand les ressources ne sont pas limitées par le processeur, mais par les entrées/sorties (disque dur lent, mémoire lente, etc ...) ou alors par la conception plus que douteuse de certaines applis (problème au niveau du code, donc de l'homme ...). Mais pour tout ce qui est calcul intensif sur des données demandant le même genre de calcul, c-a-d tout ce qui est parallélisable, ça aide beaucoup.

  • # parce que i486 existe toujours

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

    Et j'ai même installé ubuntu dessus.
    Et ce n'est pas de l'EDO qu'il y a dessus. Pour info le processeur est un AMD K6 II 300Mhz. Pour le reste, je ne sais plus trop.

    Ceci dit, maintenant j'utilise ArchLinux qu j'aprécie beaucoup par rapport à ubuntu et hereusement que j'ai un i686. Si je récupère le PC en question je pourrais bien vouloir installer ArchLinux mais je ne sais pas comment je ferais.

    • [^] # Re: parce que i486 existe toujours

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

      euh... K6 c'est minimum i586 comme architecture, peut-être même un 686.

      Les 486 c'est i486 pour les intel et am486 pour les AMD (les DX4-100 ; c'était mon rêve à l'époque).

      • [^] # Re: parce que i486 existe toujours

        Posté par  . Évalué à 2.

        Mais euh... et l'AMD 5x86, alors ? Il etait bien mon 5x86 PR 133. Pis y'avait aussi le Cyrix Cx5x86 dans le meme genre. Ah, c'etait le bon temps...

        • [^] # Re: parce que i486 existe toujours

          Posté par  . Évalué à 2.

          Vu la fiabilité des Cyrix à l'époque, je doute qu'il en reste beaucoup aujourd'hui.

          Alors que les Intel Pentium 1XX, c'est increvable. J'ai un serveur à base de Pentium 133 qui tourne 24/24h depuis 7 ans maintenant sans le moindre problèmes. Le ventilateur à même grillé il y a deux ans. Je ne l'ai jamais changé.

      • [^] # Re: parce que i486 existe toujours

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

        mea culpa, c'est bien un 586 ... Je me disais bien qu'il y avait autre chose que 486 entre 386 et 686.
        N'empêche que Archlinux ne devrait quand même pas tourner dessus

    • [^] # Re: parce que i486 existe toujours

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

      Le K6 II possède des instructions MMX et 3Dnow!
      Il doit se situer entre le Pentium II et le Pentium III... on est loin du simple 486 !!

      Pas étonnant que la mémoire ne soit pas de l'EDO ;o)

  • # Juste en lisant le titre...

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

    En regardant le titre dans mon agrégateur favoris (que je ne citerais pas, le but du troll était sur autre chose), je me suis dit, "tien quelqu'un qui trouve que l'architecture x86 c'est du n'importe quoi"
    Bon ben je me suis planté, m'enfin je vais quand même en parler:
    Je trouve personnellement que l'architecture x86 (et x86_64 c'est encore pire), est très mal foutue:
    C'est une somme d'extensions ajoutées les une après les autres, avec à la base un processeur 16bits (ou 8? oué non je crois pas faut pas exagerer),
    On peut parler aussi des BIOS, le truc qui pèse dans la moitié du temps de boot, et qui permet aux applications des années 80 de tourner (les applications MS DOS quoi), qu'est-ce qu'on en a à faire ?
    Alors évidement certaines applications MS DOS continuent d'être utilisé, mais l'OS sale (DOS quoi) peut être facilement remplacé, quitte à utiliser un émulateur (vous connaissez beaucoup d'appli dos qui a besoin de 2Ghz ?) .
    Alors la tendance (et encore...) est à l'EFI, qui semble nettement plus performant et fonctionnel (un shell avec support réseau enfin un peu tout quoi), m'enfin est-ce vraiment utile ?
    Le temps de boot d'EFI est que je sache beaucoup plus rapide, mais bon il n'a toujours pas à gérer tout ca !
    L'IDE, du VESA, l'ethernet (et encore), et ca suffit!
    L'OS sachant déjà gérer tous les périphériques.
    D'ailleur LinuxBIOS est très bien pensé dans cet optique: Il fait le stricte minimum et laisse linux se demerder (ce qu'il fait très bien)

Suivre le flux des commentaires

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