Une distribution à compiler soi-même

• # ca va plus vite ?

  Posté par nico168 le 31 janvier 2002 à 12:33. Évalué à 10.

  

  tout recompiler apporte t'il vraiment des meilleures performances ?
  
  parceque bon...je suppose que ca doit prendre du temps

  • [^] # Re: ca va plus vite ?

    Posté par Sylvain Rampacek (site web personnel) le 31 janvier 2002 à 12:44. Évalué à 10.

    

    du temps mais aussi de la place...
    
    
    
    Par exemple, pour compiler wine il faut 500Mo de libre...
    
    et quelques heures sur une machine à 400Mhz.

    • [^] # Re: ca va plus vite ?

      Posté par Dams Nadé (site web personnel) le 31 janvier 2002 à 13:01. Évalué à 10.

      

      Le pire j'crois que c'est XFree86.. :)
      A configurer c'est assez *original*, et a compiler ca mettait plus de 6h sur mon pti k6-2 350 et ca bouffe environ 700Mo de disk :)
      Cela dit, je crois vraiment qu'a part les gros machins genre glibc, XFree (justement), mozilla, et (of course) noyau, on y gagne tellement peu a recompiler que c'est risible. Ou alors il faut des applis comme mplayer qui sachent *reellement* tirer parti des specificites de chaque type de processeur (3dnow!, mmx, double ALU...). Mais precisement dans le cas de mplayer, il serait peut-etre mieux de reconnaitre les processeurs a l'execution plutot qu'a la compilation... ca permettrait notemment de le trouver dans des distributions (avec des binaires...) en version precompilee....
      
      J'vais eviter de lancer un troll en disant que c'est aussi un peu la faute a gcc qui ne genere pas forcement le code le plus optimise' qui soit (mais non j'l'ai pas dit..) comme l'a montre le bench realise avec le compilateur d'intel. (voir les news de /. du week-end dernier..) Jusqu'a 47% plus rapide que le code genere par gcc..
      Fin voila j'dis ca mais j'dis rien :)

      • [^] # Re: ca va plus vite ?

        Posté par furai (site web personnel) le 31 janvier 2002 à 13:10. Évalué à 10.

        

        Cela dit, je crois vraiment qu'a part les gros machins genre glibc, XFree ...
        

        
        D'ailleurs, est-ce que ca apporte quelque chose si tu recompiles tout, sauf la glibc.
        Parce que la, ca ne serait qu'optimiser des softs qui s'appuient sur une bibliotheque pas optimisee
        (tout du moins pour les progs ecrits en C)( en fait, les autres ca doit pas trop les deranger)

        • [^] # Re: ca va plus vite ?

          Posté par Simon_N le 31 janvier 2002 à 13:50. Évalué à 10.

          

          Tout dépend du soft. Il faut utiliser un profiler pour voir où il passe son temps. Si c'est dans la glibc, il vaut mieux qu'elle soit optimisée. Mais en général, le temps est perdu principalement dans les E/S et dans le code de l'application, rarement dans la glibc. Donc ce n'est pas toujours crucial qu'elle soit optimisée.

          • [^] # Re: ca va plus vite ?

            Posté par Dams Nadé (site web personnel) le 31 janvier 2002 à 14:03. Évalué à 10.

            

            Pour un programme unique oui on peut profiler, mais pour une distribution tout entiere.. Beaucoup de programmes font appels aux routines de la glibc, et vu le nombre a la fois de programmes, de routines et d'appels a ces routines, je ne pense pas que ce soit un vulgaire detail. La glibc est surement la premiere chose (apres DaKernel) a optimiser pour son processeur. D'ailleurs les distributions Linux les plus repandues fournissent souvent des paquetages de la glibc pour i586 ou i686 (i886, athlon?)...

            • [^] # Re: ca va plus vite ?

              Posté par Simon_N le 31 janvier 2002 à 14:34. Évalué à 6.

              

              Je suis tout à fait d'accord. Il vaut mieux optimiser le facteur commun de tous les programmes de sa machine, évidemment !

      • [^] # Re: ca va plus vite ?

        Posté par Sylvain Rampacek (site web personnel) le 31 janvier 2002 à 13:20. Évalué à 4.

        

        il serait peut-etre mieux de reconnaitre les processeurs a l'execution plutot qu'a la compilation...
        
        heu, la taille des exécutables va grossir considérablement...
        
        Bon, pour une version MMX ou standard, y'aura pas beaucoup de différence mais une version x86 et sparc, il y a beaucoup de différence donc l'exécutable sera presque deux fois plus gros...

        • [^] # Processeur

          Posté par wismerhill le 31 janvier 2002 à 13:47. Évalué à 9.

          

          On a pas dit un exécutable multiplateforme!
          Juste un exécutable pouvant détecter à l'exécution les petites spécificités d'une même famille de processeurs dont les générations successives ont chacune ajouté des fonctionnalités.
          Il est pas question de mettre du code sparc avec du code x86 mais dans le code x86 d'avoir la possibilité de détecter s'il peut utiliser les instructions mmx (par exemple) ou pas.
          
          Et soit dit en passant c'est prévu pour la version 1.0 de mplayer, qui n'est pas encore pour tout de suite vu qu'ils n'ont pas encore commencé à travailler sur ce problème et que l'interface graphique doit encore être considérablement stabilisée.

        • [^] # Re: ca va plus vite ?

          Posté par Dams Nadé (site web personnel) le 31 janvier 2002 à 13:54. Évalué à 5.

          

          Vu la taille des disques durs de nos jours, je ne suis pas sur que l'agument de la taille tienne encore la route.. (Ok, tu as un 486dx2 qui a un disk dur de 400Mo et pour toi ca compte mais ne me fait pas croire que tu lis du divx sur une bete comme ca :)
          
          De plus, si c'est fait sous forme de plugin ou de bibliotheque chargees dynamiquement.... Mais bon.. on se complique la vie pour peut-etre pas grand chose apres tout..
          
          De plus, mon argument n'est effectivement valable que pour les processeurs d'une meme famille (typiquement les i386 & cie).

          • [^] # Re: ca va plus vite ?

            Posté par Sylvain Rampacek (site web personnel) le 31 janvier 2002 à 20:55. Évalué à 1.

            

            Ben ça prend aussi de la place sur le disque et en mémoire vive !
            
            En plus, c'est plus gros également à traiter par le microprocesseur... donc une exécution plus longue...
            
            La franchement, je ne vois pas trop l'intérêt de mettre les formes Pentium, PentiumMMX, PentiumPro, PentiumII, PentiumIII, PentiumIV (et pourquoi pas une version Céléron avec une gestion de la mémoire cache plus faible...) ! et puis encore les technologies AMD !
            Non, je ne pense pas que ce soit une bonne idée !
            
            En plus, cela supposerai une compilation plus longue...
            Et de toute façon, la taille de l'exécutable sera bien plus grosse... car si on fait un test pour chaque bloc de code exécutable critique, ça va prendre du temps (et c'est pas un frein à l'optimisation voulue ?).
            
            Je vois déjà la réponse : "ben pas besoin de faire plusieurs tests, en faire qu'un seul au début", mais alors à quoi sert ce truc ? car il faut avoir une version de l'exécutable dans UN exécutable pour chaque architecture (même x86) et un temps de chargement plus long... pour une appli, ce n'est pas bien génant mais pour un serveur... alors recompiler pour recompiler, autant ne pas grossir les exécutables au départ et en fournir des compatibles comme cela se fait en ce moment !

      • [^] # Re: ca va plus vite ?

        Posté par Alphonse Oncle le 31 janvier 2002 à 17:44. Évalué à 6.

        

        "le compilateur d'intel. (voir les news de /. du week-end dernier..) Jusqu'a 47% plus rapide que le code genere par gcc"
        
        Meme si on a un athlon?
        En tout cas ce serait bien la honte pour intel si son compilo etait pas plus puissant que gcc sur ses propres processeurs. Le compilo d'intel il tourne que sur i386 ou il marche ailleurs?

        • [^] # Re: ca va plus vite ?

          Posté par furai (site web personnel) le 31 janvier 2002 à 17:52. Évalué à 9.

          

          C'etait paru dans LMF ou il etait question du P IV.
          On y apprenait que l'athlon beneficiait d'une amelioration de ~10% en execution (si je le rappelle bien).
          Pas de quoi casser trois pattes a un canard, en tout cas.

        • [^] # Re: ca va plus vite ?

          Posté par matiasf le 31 janvier 2002 à 18:45. Évalué à 2.

          

          > Jusqu'a 47% plus rapide que le code genere par gcc
          
          les 47% c'est pour quoi ? quel est le gain en moyenne ?
          
          Sur un athon XP, linux/glibc compile en i386 ou i686 (gcc march=...) c'est bonnet blanc et blanc bonnet.
          Subjectivement, je ne remarque rien ...

          • [^] # Re: ca va plus vite ?

            Posté par reno le 31 janvier 2002 à 23:47. Évalué à 10.

            

            Certes, mais avec un Athlon XP, ton CPU est une bete de course et il y a de forte chance que le goulot d'etranglement soit déplacé ailleurs pour la majorité des utilisations: la mémoire ou encore pire le disque.
            
            De maniere savante ça s'appelle la loi d' Amdhal..
            En clair: attendre que le disque fasse son boulot à 2 ou 3 GHz ça ne fait pas grande différence:-)

          • [^] # Re: ca va plus vite ?

            Posté par Troy McClure (site web personnel) le 01 février 2002 à 08:54. Évalué à 10.

            

            les 47% c'était sur des bouts de code qui faisaient du calcul en virgule flottante (fft et compagnie). Je serais fort surpris que la glibc ou Xfree ou le kernel bénéficie du même gain (si ils étaient compilable avec icc)..

          • [^] # Re: ca va plus vite ?

            Posté par egh le 04 février 2002 à 16:29. Évalué à 1.

            

            Les distribs fournissent en général une version i686 (en plus de la i386) pour les paquets comme linux ou la glibc... Il doit donc y avoir une différence tout de même.
            
            Sinon, l'intérêt de la recompilation ne se résume pas à des optimisations de compilation, cela permet aussi de rajouter ou ôter des options à souhait, selon son propre matériel.

        • [^] # Re: ca va plus vite ?

          Posté par Benjamin le 01 février 2002 à 22:54. Évalué à 4.

          

          le compilo d'intel ne marche justement que sur les intels, alors que gcc est prévu pour cibler tout un éventail de plate-formes. C'est pas vraiment comparable.
          
          Quand au test, meme si je veux bien croire à la victoire du compilo d'intel (encore heureux pour un compilo dédié codé par les auteurs du CPU!), il était tres peu objectif, puisque les tests étaient fait sur du code assez précis, et la version de gcc n'était pas une des plus récentes

  • [^] # Re: ca va plus vite ?

    Posté par Jésus Christ le 31 janvier 2002 à 20:22. Évalué à 0.

    

    perso j'ai compilé XFree une fois, j'ai pas trouvé ca plus long que le kernel...
    Mais je n'est pas trouvé de différences majeures, pourtant c'était sur une Mandrake et j'ai entendu dire que le XFree de la mdk était particulièrement lent.
    Donc ca peut être sympa. Le seul truc c'est qu'il faut pas avoir peur de perdre un week-end et encore...
    Remarque après ca on peut surement overclocker son processeur un max....;))A le bon vieu temps ou pour faire gagner qqles MHz à son Celeron 333 on jouait à Quake pendant 12 heures d'affilé ;))

• # Intéressant

  Posté par wismerhill le 31 janvier 2002 à 17:54. Évalué à 5.

  

  Ça a l'air plus simple qu'une LFS en ayant les avantages de l'optimisation.
  Quelqu'un l'a essayé et pourrait nous en dire plus?

• # LFS & Gentoo

  Posté par Guillaume Lefevre le 31 janvier 2002 à 19:03. Évalué à 4.

  

  de mon point de vue j'utilise LFS pour avoir une
  distrib configuree comme j'ai envie...
  pas pour le gain de vitesse... malheureusement c'est
  c'est une methode qui prend du temps et j'utilise
  surtout Gentoo...

  • [^] # Re: LFS & Gentoo

    Posté par Guillaume Lefevre le 31 janvier 2002 à 19:22. Évalué à 4.

    

    ah oui... gentoo ce qui est interessant aussi c'est que les fichiers de démarrage gèrent les dépendances
    par ex network doit etre lance avant apache, etc.

• # et aussi

  Posté par Thomas Cataldo (site web personnel) le 31 janvier 2002 à 20:13. Évalué à 7.

  

  Il y a aussi http://www.rocklinux.org(...) que l'on peut recompiler entièrement.
  
  Pour l'installer il faut un linux minimal, avec un environnement de compilation, et une connec au net.
  
  Ensuite les scripts rocklinux vont récupérer les packages sur les mirroirs du logiciel donné, le compilent et l'installent. Les script peut bien sur sortir une iso à la fin.

• # Y a pas que la vitesse dans la vie

  Posté par tfing le 31 janvier 2002 à 21:25. Évalué à 6.

  

  recompiler toute sa ditribution ne permet pas seulement de gagner en vitesse mais aussi de pouvoir definir toutes les options de configuration pour ses propres besoins
  c'est interessant a cause des dependances qui, dans le cas des distributions de binaires, sont forcees
  par exemple, certaines applications gtk+ proposent d'utiliser gnome et je ne vois pas pourquoi les mainteneur (ca existe ?) du package devrait nous imposer son choix
  donc voila ce que je voulais ajouter : recompiler ca permet non seulement de gagner un poil en vitesse (jacky touch) mais aussi de paufiner tout ses petits packages a son propre gout
  
  et je confirme ce que disait le message precedent : ROCKLinux, ca rox !!!

  • [^] # Re: Y a pas que la vitesse dans la vie

    Posté par Matthieu le 02 février 2002 à 21:34. Évalué à 1.

    

    Tout à fait d'accord, recompiler son système, ce n'est pas forcement pour améliorer les performances. Je me suis compilé mon système Linux en suivant les recommandations LFS, et c'est une très bonne expérience à vivre. Bon, ok, il faut quand même quelques pré-requis, tout le monde ne peut pas s'aventurer dans une telle expérience sans avoir quelques connaissances sur les systèmes unix. De plus, j'utilise très régulièrement LFS. Une fois pour créer un linux pour un routeur, une autre fois pour créer un cd-rom bootable. Donc si vous avez le temps et le courage, compiler vous un système linux. (moi ça m'a pris 2 jours la première fois. Maintenant moins de 6 heures). bon courage.

Suivre le flux des commentaires

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