Compiler et optimiser KDE 2.2.2

Posté par  (site web personnel) . Modéré par oliv.
Étiquettes : aucune
0
7
déc.
2001
KDE
userlocal propose un article plutôt intéressant sur la compilation de KDE 2.2.2 . On y parle entre autres de objprelink, qui semble vraiment efficace au vu des temps annoncés dans l'article: sur la machine de l'auteur, le temps de démarrage de KDE passe de 30-40 secondes à 10-15 , et celui de konqueror passe de 6-10 secondes à 2-4 !

Aller plus loin

  • # From Scratch roulez

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

    Je crois que c'est une preuve de plus que compiler soit-meme permet d'optimiser son systeme pas mal...
    Linux From Scratch roulez.... ;-)

    • [^] # Re: From Scratch roulez

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

      Do It Yourself ownz!

      • [^] # Re: From Scratch roulez

        Posté par  . Évalué à 10.

        C'est sympa une LFS, et très formateur, mais pour un poste desktop, ça demande beaucoup de travail avant d'obtenir une machine utilisable. Et pour la maintenance des packages, c'est tout à la main.

        L'idéal serait un hybride LFS et Debian : Une fois le système de base réalisé avec LFS, on greffe un gestionnaire de packages Debian et on installe tout ce dont on a besoin en faisant une recompilation à partir des sources (Pour ce qui est open-source).

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 10.

          L'idéal serait des méta-packages pour gnome (et kde, probablement, mais je ne connais pas) parce que ça reste toujours une galère de compiler les 42000 packages dans le bon ordre.

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 10.

          Il me semble que ce dont tu parles est en développement:
          ALFS (Automated LFS).

          http://alfs.linuxfromscratch.org/(...)

          (ou alors j'ai pas bien compris)

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 3.

          Je vote pour un système de ports.
          mpkg le fait il me semble (ou alors je confond avec un autre)

    • [^] # Re: From Scratch roulez

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

      Oui, ca prouve aussi que la slack est bien meilleure que la plupart des distros avec la contrainte que sont les dependances. Sur une distro avec les dependances, dés que l'on installe un pgm(ou pire une librairie) compilé a la main, on casse completement le systeme de dépendances ou alors il faut s'amuser a créer des packages avec dépendances, ce qui est loin d'etre evident pour tout le monde et prend beaucoup de temps.

      C'est vrai que l'on sait le faire aussi sur n'importe quel distros, mais alors autant passer direct a une slack, si il y a un systeme de dependances, autant l'utiliser.

      • [^] # Re: From Scratch roulez

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

        > Oui, ca prouve aussi que la slack est bien meilleure que la plupart des distros avec la contrainte que sont les dependances.

        Si tu veux bidouiller, ou customiser ton installation oui. Mais sinon avoir des packages est essentiel et fait gagner enormément de temps.

      • [^] # Re: From Scratch roulez

        Posté par  . Évalué à 6.

        Je suis entièrement d'accord. Moi je suis passé à la Slack depuis un bout de temps déjà pour m'affranchir de ce système de packages avec des dépendances à n'en plus finir. C'est vraiment galère, à chaque fois que tu veux installer un nouveau truc, t'es obligé de mettre à jours les 25 autres packages qui en dépendent (même si tu sais très bien que ça va marcher sans) ou alors tu fais un --nodeps ou --force et là tu casses tout ton système...

        En fait, j'ai trouvé un système assez pratique : http://www.gormand.com.au/peters/tools/graft/graft.html(...) qui permet d'installer les applis/bibliothèques dans un répertoire particulier (style /usr/local/pkgs/Emacs-21.1) et ensuite de faire des liens symboliques de tous les fichiers de ce répertoire dans l'arborescence classique. Ca permet d'avoir plusieurs versions du même programme installées, de tester la nouvelle, si ça marche pas on revient à l'ancienne etc...

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 7.

          En fait, j'ai trouvé un système assez pratique : www.gormand.com.au/peters/tools/graft/gr

          Oui et apparement c'est base sur Stow (http://www.gnu.org/software/stow/(...)) qui s'occupe de faire les liens. Stow n'a plus bouge depuis longtemps, c'est assez sommaire, mais je l'utilise tjs ...

          Je vais de suite essayer ce Graft :-)

        • [^] # Re: From Scratch roulez

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

          C'est vraiment galère, à chaque fois que tu veux installer un nouveau truc, t'es obligé de mettre à jours les 25 autres packages qui en dépendent (même si tu sais très bien que ça va marcher sans) ou alors tu fais un --nodeps ou --force et là tu casses tout ton système...

          Si --nodeps "casse tout ton système" ca veut dire que tu avais besoin de mettre à jours les autres packages... Si tu sais que ca va marcher sans et donc que c'est le package qui est mal fait utilises --nodeps. J'utilise rarement --nodeps mais quend je le fait ça ne pose aucun problème.

      • [^] # Re: From Scratch roulez

        Posté par  . Évalué à 10.

        C'est faut.

        Le paquet equiv sous Debian te permet justement d'informer à cout modique la base de données des paquets que tu as installé quelque chose à la main.
        De cette manière, Debian permet aussi d'installer les tarballs «proprement».

        • [^] # Re: From Scratch roulez

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

          > Le paquet equiv sous Debian te permet justement d'informer à cout modique la base de données des paquets que tu as installé quelque chose à la main.

          c'est le "à cout modique" qui me fait peur dans ta phrase. Ou est ce que l'on peut trouver des infos sur ton systeme equiv?

          • [^] # Re: From Scratch roulez

            Posté par  . Évalué à 7.

            Je ne connais pas équiv mais je peux également signaler que c'est complétement faux.

            Avec checkinstall, on peut avoir toutes ses installations répertoriées par le gestionnaire de paquet (RPM, deb, slack).

            C'est idéal : on compile soit même à partir des sources et on a un RPM fait sur mesure.

            Le programme fait un make install et observe ce que le make install fait pour créer le paquet.
            Donc ça ne coute rien de plus que de faire un make install en fait.

            http://asic-linux.com.mx/~izto/checkinstall-en.html#checkinstall(...)

          • [^] # Re: From Scratch roulez

            Posté par  . Évalué à 1.

            Pour trouver des infos sur equivs (désolé pour la faute de frappe ...) : http://packages.debian.org/stable/admin/equivs.html(...)
            Et puis, je « rappelle » quand meme, qu'on peut compiler les paquets debian à la volée, ce qui permet d'avoir le beurre et l'argent du beurre ...

    • [^] # Re: From Scratch roulez

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

      Qu'est ce qui empêche les distributions de compiler leurs packages avec ces optimisations ?

      On arrive au même résultat sans avoir à passer des heures à (essayer de) compiler un truc aussi gros que KDE.

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

      • [^] # Re: From Scratch roulez

        Posté par  . Évalué à 1.

        Rien du tout effectivement, meme si généralement les distribs essayent d'eviter certaines optimisations qui seraient trop hazardeuses pour la stabilité générale.

        Mais par exemple le coup de l'objprelink pour KDE est inclu dans la Redhat 7.2

        Donc LFS rulez, distribs rulez, opensource rulez

        • [^] # Re: From Scratch roulez

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

          > les distribs essayent d'eviter certaines optimisations qui seraient trop hazardeuses
          > pour la stabilité générale.

          Il faut bien sur se rappeler en lisant cette phrase que "hazardous" en anglais signifie "risqué". J'imagine que la subtilité est volontaire mais comme je l'ai découvert personellement assez tard, je me dis que je ne dois pas etre le seul à avoir fait la faute.

      • [^] # Re: From Scratch roulez

        Posté par  . Évalué à 10.

        Ca t'ennuie pas d'avoir un P12 à 5000 Ghz et que le binaire qu'on te propose soit compilé pour un i486 à 25 Mhz ?

        Si oui alors essaye LFS, et tu verras ce que ta machine a dans le ventre.

        Sinon effectivement les distro poropose le binaire le plus commun qui tournera sur le plus de machine. Debian i386 ? Mdk i586 ...

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 1.

          il ne manque pas:CC=gcc-3.0 CXX=g++-3.0 CPP=cpp-3.0 ?
          ou gcc3 ne donne pas du code assez stable?
          car je me ferait bien une lsf avec gcc3 moi

        • [^] # Re: From Scratch roulez

          Posté par  . Évalué à 2.

          Pourquoi les distrib ne filent pas plusieurs
          images sur leur site genre i386, i586, I686,
          athlon,...
          ca pourrait se faire...
          nan ?

      • [^] # Re: From Scratch roulez

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

        Because un paquet compilé avec optimisations pour un PIII ne tournera pas sur un K6 et un paquet optimisé à fond pour un k6 peut l'être bien plus si on le compile pour un PIII.


        Et puis l'optimisation pour une architecture ne se révelle pas forcément stable sur d'autres.


        Autre point: Regarde un peu les scripts de démarrage, allez disons SuSE. C'est,


        1. Je regarde d'où je suis lancé


        2. Je regarde si les fichiers de configurations que je dois lire sont lisibles par l'utilisateur courrant.


        3. S oui, je les lis.


        4. Si aucune erreur ne s'est produite, je vérifie si les variables en questions ont une valeur, et si celle-ci est cohérente.


        5. Si oui, je regarde si le fichier à exécuter est exécutable.


        6. Si oui, je le lance avec les parametres et je récupère les valeurs de retour.


        7. Je vérifie les valeurs de retour.





        Tout ça est nécessaire pour ne pas risquer de faire des trucs bizarres si un débutant s'amuse à manipuler ses fichiers de configuration.


        Sur ma LFS, c'est


        1. Je lis le fichier de configuration


        2. J'execute le programme avec les paramètres.





        Je me moque des valeurs de retour ou si les paramètres sont corrects, car je sais qu'ils le sont puisque c'est moi qui les ai posés dans le fichier de configuration.


        7.

    • [^] # Re: From Scratch roulez

      Posté par  . Évalué à 1.

      mouaip. m'enfin moi je dis qu'on peut tres bien recompiler ses packages soi-meme avec une distribution (au hasard debian), et mettre les flags d'optimisation voulus.

  • # bonne idée

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

    Je suis allé voir l'article et je l'ai trouvé très bien ! J'attends d'avoir un peu de temps pour essayer l'objprelinkage... C'est vrai que KDE 2 avait vraiement besoin de cette optimisation du démarrage... (ce n'est pas un troll, c'est une réalité).
    A noter un autre article pour le tuning de KDE: http://hints.linuxfromscratch.org/hints/kde.txt(...) qui explique pas à pas (dépendances comprises) comment compiler un KDE au poil.

    • [^] # Re: bonne idée

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

      Oui c'est bien que ca démarre plus vite, mais quelle est l'incidence sur le système ? Est-ce des composants restent en mémoire, comme dans M$, et bouffent inutilement des ressources tout le temps, et finissent par planter ?
      WM roulaize anyway...

      • [^] # Re: bonne idée

        Posté par  . Évalué à 10.

        Non (je crois qu')il n'y a pas d'incidence sur la mémoire.

        Si j'ai bien retenu ce que j'avais lu à l'époque, la lenteur viendrait du linkage dynamique des libs relatives au c++ utilisé par KDE qui serait assez lent et provoquerait un gros temps de latence.

        Donc je ne crois pas qu'il y ait des composants qui reste en mémoire, mais peut etre que les binaires / libs etc. sont un peu plus gros.

    • [^] # Re: bonne idée

      Posté par  . Évalué à 7.

      C'est vrai que KDE 2 avait vraiement besoin de cette optimisation du démarrage...
      Au passage, j'ai essayé kde 3 en cvs, et le lancement est beaucoup plus rapide qu'avant (au pifomètre je dirais 50%).

  • # Javascript

    Posté par  . Évalué à 1.

    Il me semblait que quand on compilait avec l'objprelink, Konqueror crashait assez lamentablement dès qu'il y avait un peu de javascript.

    Si c'est plus le cas, alors je me demande pourquoi les packages de kde pour sid sont compilés sans (vu que kde met plus de 30s a demarrer sur mon athlon xp flambant neuf avec tout plein de ram j'en conclue qu'il est compilé sans).

    • [^] # Re: Javascript

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

      Apparemment objprelink fait planter khtml. Extrait du changelog du package kde-base de Mandrake (Cooker) :

      2.2.1-16mdk
      - Remove objprelink reference
      2.2.1-15mdk :
      [...]
      - Remove objprelink (khtml crashs all the time with objprelink)


      Rien n'indique qu'ils l'on remis pour KDE 2.2.2

      En tout cas avec une Mandrake 8.1 (2.2.1-7mdk) le chargement de KDE est très rapide : pas plus de 15s avec mon P3 600.

      Pensez à l'environnement avant d'imprimer ce commentaire - Please consider the environment before printing this comment

    • [^] # Re: Javascript

      Posté par  . Évalué à 1.

      Sur mon "pauvre" PII 333 , KDE 2.2.1-7mdk sous Mdk 8.1 ne met également qu'une quinzaine de secondes à démarrer.
      Et ce avec seulement 64 MO de SDRAM.

      Alors quand je vois écrit que :
      "... le temps de démarrage de KDE passe de 30-40 secondes à 10-15, et celui de konqueror passe de 6-10 secondes à 2-4 ...
      je me demande sur quel type de machine ?

      Il me semble me souvenir que même sur mon P200 MMX (tjrs avec 64 MO de SDRAM) KDE ne mettait pas 40 secondes ...
      Quand à Konqueror, le temps de lancement indiqué me semble également des plus farfelus. (sans vouloir vexer qui que ce soit :o)

      • [^] # Re: Javascript

        Posté par  . Évalué à 1.

        Sur ton P200, ce n'était pas la même version... On ne peut comparer que ce qui est comparable. Pour l'histoire KDE Beta4, c'était assez rapide sur mon P90.

      • [^] # Re: Javascript

        Posté par  . Évalué à 1.

        les packages de mdk sont compile pentium et pas 1386 il me semble
        ils ont donc deja presque optimise les packages pour ton ordi

    • [^] # Re: Javascript

      Posté par  . Évalué à 2.

      ?
      Bof, j'utilise l'objprelink depuis plus d'un mois, et je n'ai pas de pb particulier. En tout cas, Konqueror marche toujours aussi bien.

      Oui, ça va un peu plus vite, c'est vrai. Rien de trancendant, mais c'est plus rapide.

  • # Gnome rulez , KaDeHEux su><><

    Posté par  . Évalué à -10.

    Ca fait 2 , voir trois mois que cette news est sorti, elle est deja integré a la debian depuis pas mal de temps

    de toute maniere KDE suxx

  • # Optimisation

    Posté par  . Évalué à 1.

    Moi je suis toujours surpris quand je vois des optimisations qui conduisent à des gains de plus de 40%. Je me dis que le programme en question est soit mal conçu soit que les développeurs sont des blaireaux trolleurs -(je parle pas de kde mais de gcc - mais ou est donc Stallman)

    En tout cas je pense que le plus simple serait d'intégrer le prelink dans gcc pour éviter une étape suplémentaire lors de la génération des objets.

    Je pense également qu'il serait bien que les distribs incluent des packages optimisés - au moins le minimum - de facto car n'en déplaisent aux linux gurus, moi (comme beaucoup) je me sers de mon PC sous linux non pas pour faire du linux et pour faire autre chose. (J'ai été admin sys. Unix pendant 6 ans et maintenant recompiler/optimiser un sys qui devrait fonctionnement bien du premier coup ca me gonfle grave).

    • [^] # Re: Optimisation

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

      la premiere optimisation c'est d'utiliser des algorithme performants, par ex un quicksort a la place d'un tri a bulle maison.
      La seconde c'est a la compilation optimiser le code généré par le compilo, cad spécialisé pour un PIII et puis qu'il deroule toute les boucles for etc...
      Le premier c'est le boulot du devel. chez kde ils l'ont bien fait
      Le second c'est le boulot du compilateur et de celui qui cree les packages.

      • [^] # Re: Optimisation

        Posté par  . Évalué à 4.

        En parlant d'optimiser pour PIII, j'ai essayé les logiciels téléchargeables à cette adresse http://www.acnatsci.org/~gnielsen/pgcc/(...) et c'est assez étonnant de voir bzip et gzip gagner 20 à 30% de performance rien qu'en changeant de compilateur... J'ai fait des test sur mon Athlon 750 et j'y gagne vraiment à utiliser les compresseurs fournis sur cette page!

    • [^] # beaucoup de conneries

      Posté par  . Évalué à 1.

      « Je me dis que le programme en question est soit mal conçu soit que les développeurs sont des blaireaux trolleurs -(je parle pas de kde mais de gcc - mais ou est donc Stallman) »

      C'est qui le blaireau là ?
      Tu dis que le problème d'optimisation vient de gcc ?
      Pourtant, dans un cas comme dans l'autre, c'est gcc qui est utilisé ? Donc le problème ne vient pas de gcc.

      « En tout cas je pense que le plus simple serait d'intégrer le prelink dans gcc pour éviter une étape suplémentaire lors de la génération des objets. »

      Tu dis ça comme ça, au feeling, ou tu es expert de la chose ?

      « Je pense également qu'il serait bien que les distribs incluent des packages optimisés - au moins le minimum - de facto car n'en déplaisent aux linux gurus, moi (comme beaucoup) je me sers de mon PC sous linux non pas pour faire du linux et pour faire autre chose. (J'ai été admin sys. Unix pendant 6 ans et maintenant recompiler/optimiser un sys qui devrait fonctionnement bien du premier coup ca me gonfle grave) »

      Le de facto, il vient faire quoi là ?
      Les paquets livrés avec les distribs sont optimisés pour tourner sous toutes les configurations supportés par les distribs. C'est ce qui fait que ces distribs fonctionnent du premier coup.

      Bref, tout est dans le titre

      • [^] # Re: beaucoup de conneries

        Posté par  . Évalué à 5.

        « En tout cas je pense que le plus simple serait d'intégrer le prelink dans gcc pour éviter une étape suplémentaire lors de la génération des objets. »

        Tu dis ça comme ça, au feeling, ou tu es expert de la chose ?


        Il n'a pas complètement tort. Le problème est que objprelink est actuellement spécifique et aux x86 et aux objets ELF. Donc ce n'est pas très portable (pas facilement pour l'instant) donc ce n'est pas intégré à gcc.

        Mais il est vrai que le compilo et l'éditeur de liens ont besoin d'être optimisés encore et toujours (le problème actuel venant plutôt de ld, mais aussi en partie de g++).

        La priorité actuelle des développeurs de gcc est quand même plutôt d'avoir des objets fonctionnels, car gcc 3 pose encore des problèmes avec certaines applis (je n'ai plus les noms).

        • [^] # Re: beaucoup de conneries

          Posté par  . Évalué à 3.

          La dessus, je ne dis pas, j'en sais rien.

          Je me demandais juste si le type parlais en connaissance de cause, ou si son avis était aussi élaboré que les autres.

          Parce que reprocher au staff de gcc que les paquets binaires de KDE aient été optimisé pour i386, c'est un peu gonflé.

      • [^] # Re: beaucoup de conneries

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

        > Pourtant, dans un cas comme dans l'autre, c'est gcc qui est utilisé ?
        > Donc le problème ne vient pas de gcc.
        Affirmation un peu rapide! Le probleme, c'est qu'on est obliger d'utiliser un programme exterieur pour faire qqch que gcc aurait du faire depuis longtemps. Donc c'est bien gcc qui est en cause, c'est lui qui n'optimise pas son edition de lien.

        > Je me dis que le programme en question est soit mal conçu soit que les développeurs sont des
        > blaireaux trolleurs -(je parle pas de kde mais de gcc - mais ou est donc Stallman) »

        J'ai un ami qui a bosse sur gcc pour faire un port. Son bilan etait que c'etait un truc absolument immonde, avec des symboles dont tu ne sais d'ou ils viennent, des fonctions dans tous les sens, des trucs obsoletes qui se melangent avec des trucs indispensables, et aucun partitionnement clair de ce qui sert a quoi.

        Ca fait peur quand tu te dis que c'est le compilateur de reference du logiciel libre. Je ne sais pas a quel point RMS est encore l'auteur de ce qu'il y a dans gcc mais je m'interroge sur sa responsabilite par rapport a ce bordel. Emacs est mieux ?

        gcc est certainement le compilateur le plus porte mais quand tu vois la merde que c'est pour faire un port, tu te demandes a quel point il n'y a pas de l'energie gachee et si on devrait pas tout reprendre depuis le debut.

        De meme, j'ai bosse sur vim, qui doit etre un des clones vi les plus utilises au monde. Le code est immonde, avec des fichiers de 10000 lignes, des fonctions encore en C pre-ansi, des trucs qui s'appellent dans tous les sens. Pour dire, il y a trois fichiers qui s'appellent "misc". A ton avis, il y a quoi dedans ?

        Pas de quoi etre fier.

        En ce qui concerne le prelinking, l'auteur est a ce que j'ai compris un developpeur de ld, donc cette optimisation sera bien inclus dans gcc a terme.

        • [^] # Re: beaucoup de conneries

          Posté par  . Évalué à 2.

          <mode pedantic>
          Il ne faut pas confondre un compilateur et un linker. Le seul rôle d'un compilateur (gcc) est de convertir un fichier source (c, c++ ou autre) en un code assembleur optimisé. Ensuite un assembleur (as) convertit ce fichier assembleur en fichier objet, et enfin le linker (ld) fait l'édition des liens.

          gcc exécute les autres programmes pour éviter d'avoir à taper 42 lignes de commandes, mais ce n'est pas à gcc de faire l'édition des liens, c'est à ld. Donc toutes vos critiques sur l'équipe de gcc devrait plutôt porter sur l'équipe des binutils.
          </mode pedantic>

          • [^] # Re: beaucoup de conneries

            Posté par  . Évalué à 1.

            Si tu donnes de la merde au linker il linkera de la merde. Donc l'objectif est bien de generer du code plus efficace à linker et ca c'est le boulot du compilateur. Mais cela n'empeche par pour autant d'ameliorer le linker.

  • # l'optimisation maximale pour kde...

    Posté par  . Évalué à -3.

    c'est de pas l'installer non ?

Suivre le flux des commentaires

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