mercredi 08 octobre

Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Articles précédents : Articles

[92] Debian sur Win32
[14] Resultats du Linux Journal Reader's Choice Awards
[38] Le Mystère Ginger enfin dévoilé
[31] Trophées 2001 Internet Professionnel : Linux vainqueur
[1] Résumé Gnome du 24-11 au 29-11-2001
[40] LinuxFr : le père Noël est en avance
[20] Les brevets superflus en matière de logiciels
[41] DaNews: Information spéciale
[25] Peace, Love & Linux... et paie la facture
[10] Rambus joue et perd

Liens connexes

l'article (1999 hits)

Dépêche modérée par

oliv

Articles : Compiler et optimiser KDE 2.2.2

Posté par Troy McClure (page perso, ). Modéré le 07 décembre 2001.

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 !

l'article (1999 hits)

> Lire les commentaires (50 commentaires, moyenne: 5).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

From Scratch roulez

Posté par Jean-Pierre Schwickerath (page perso, ) le 07/12/2001 à 12:01. (lien). Évalué à 26.

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

--
Nothing's impossible... Everything's relative!

[^]Re: From Scratch roulez

Posté par analogue o/ (page perso, ) le 07/12/2001 à 12:10. (lien). Évalué à 1.
Do It Yourself ownz!

--
Votez contre le cinéma sur DLFP: http://linuxfr.org/tracker/296.html
Le lien pour voter est en haut à droite.
- [^]Re: From Scratch roulez
  
  Posté par gle () le 07/12/2001 à 12:17. (lien). Évalué à 29.
  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 Anonyme () le 07/12/2001 à 12:22. (lien). Évalué à 16.
    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 bmc () le 07/12/2001 à 12:55. (lien). Évalué à 16.
    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 Migeot Olivier () le 07/12/2001 à 23:26. (lien). É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 Stone Tramo () le 07/12/2001 à 12:47. (lien). É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 Guillaume Laurent (page perso, ) le 07/12/2001 à 13:28. (lien). É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 jbbodart () le 07/12/2001 à 13:39. (lien). É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 Tony Gencyl (page perso, ) le 07/12/2001 à 14:46. (lien). É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 Pascal Terjan (Jabber id, page perso, ) le 07/12/2001 à 18:20. (lien). É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 Stéphane Del Pino (page perso, ) le 07/12/2001 à 14:20. (lien). Évalué à 12.
  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 Stone Tramo () le 07/12/2001 à 15:11. (lien). É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 gnap gnap (page perso, ) le 07/12/2001 à 16:03. (lien). É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 Stéphane Del Pino (page perso, ) le 07/12/2001 à 21:58. (lien). É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 Robert Palmer (page perso, ) le 07/12/2001 à 12:52. (lien). É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.
- [^]Re: From Scratch roulez
  
  Posté par f l () le 07/12/2001 à 13:09. (lien). É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 Philippe Fremy (page perso, ) le 07/12/2001 à 15:56. (lien). É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.
    
    --
    phil.freehackers.org
- [^]Re: From Scratch roulez
  
  Posté par didbaba (page perso, ) le 07/12/2001 à 13:18. (lien). Évalué à 13.
  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 yves-laurent allaert () le 07/12/2001 à 15:42. (lien). É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 didbaba (page perso, ) le 09/12/2001 à 18:39. (lien). Évalué à 3.
      gcc 3.0.2 est incompatible avec la glibc 2.2.4. Entre autre
  - [^]Re: From Scratch roulez
    
    Posté par Jésus Christ (page perso, ) le 09/12/2001 à 17:58. (lien). É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 Jean-Pierre Schwickerath (page perso, ) le 11/12/2001 à 17:49. (lien). É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.
  
  --
  Nothing's impossible... Everything's relative!

[^]Re: From Scratch roulez

Posté par shbrol () le 07/12/2001 à 15:49. (lien). É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 Pierre Tramal (page perso, ) le 07/12/2001 à 12:04. (lien). Évalué à 20.

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 VACHOR (page perso, ) le 07/12/2001 à 12:42. (lien). Évalué à 14.
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 f l () le 07/12/2001 à 13:00. (lien). É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 f l () le 07/12/2001 à 13:05. (lien). Évalué à 1.
    cf http://kt.zork.net/kde/kde20010803_19.html(...)
    §6: An Option For The Speed Obsessed
    
    27 Jul Archive Link: Faster startups by fixing C++ object files before linking (new version and results)

[^]Re: bonne idée

Posté par jojolapin (page perso, ) le 07/12/2001 à 12:48. (lien). É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 f l () le 07/12/2001 à 12:34. (lien). É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 Robert Palmer (page perso, ) le 07/12/2001 à 13:29. (lien). É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.

[^]Re: Javascript

Posté par nixo () le 07/12/2001 à 14:01. (lien). É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 Henri () le 07/12/2001 à 17:54. (lien). É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 yves-laurent allaert () le 08/12/2001 à 14:58. (lien). É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 Sebastien (page perso, ) le 09/12/2001 à 00:50. (lien). É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 laurent Belmonte () le 07/12/2001 à 14:18. (lien). Évalué à -19.

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

[^]Re: Gnome rulez , KaDeHEux su><><

Posté par Thomas Cataldo (page perso, ) le 07/12/2001 à 15:36. (lien). Évalué à 1.
kdelibs (4:2.2.1-1) unstable; urgency=low

* New upstream version
* Don't use objprelink anymore

-- Ivan E. Moore II <rkrusty@debian.org> Fri, 07 Sep 2001 12:10:00 -0700

Voilà monsieur, debian a supprimé le prelink.

trolls sucks
- [^]Re: Gnome rulez , KaDeHEux su><><
  
  Posté par Philippe Fremy (page perso, ) le 07/12/2001 à 16:29. (lien). Évalué à 1.
  Redhat préfere utiliser du "prelinking" que objprelink.
  
  Pour le prelinking:
  http://lists.kde.org/?l=kde-core-devel&m=99134101312638&w=2(...)
  
  --
  phil.freehackers.org
  - [^]Re: Gnome rulez , KaDeHEux su><><
    
    Posté par Vivi (page perso, ) le 07/12/2001 à 16:52. (lien). Évalué à 2.
    En lisant le mail en question, je constate que je n'y connait quasiment rien sur le principe du "linkage" dynamique. Ça a l'air finalement assez complexe. Quelqu'un sait où trouver de la doc la-dessus (HOWTO ...) ?

Optimisation

Posté par Cook Captain () le 07/12/2001 à 17:03. (lien). É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 Emmanuel Blindauer (page perso, ) le 08/12/2001 à 02:53. (lien). É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 Bee Bairt () le 09/12/2001 à 17:22. (lien). É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 gnap gnap (page perso, ) le 08/12/2001 à 14:39. (lien). É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 Jean-Yves B. () le 08/12/2001 à 15:36. (lien). É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 gnap gnap (page perso, ) le 09/12/2001 à 02:18. (lien). É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 Philippe Fremy (page perso, ) le 09/12/2001 à 11:07. (lien). É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.
  
  --
  phil.freehackers.org
  - [^]Re: beaucoup de conneries
    
    Posté par Gaël Le Mignot (page perso, ) le 09/12/2001 à 11:21. (lien). É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 Cook Captain () le 11/12/2001 à 13:47. (lien). É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 Benjamin Michotte (page perso, ) le 07/12/2001 à 17:18. (lien). Évalué à -3.

c'est de pas l'installer non ?

[^]binny ....

Posté par kadreg () le 07/12/2001 à 17:27. (lien). Évalué à 0.
http://kadreg.free.fr/perso/tusors.gif(...)

Revenir en haut de page

Articles précédents : Articles

Liens connexes

Dépêche modérée par

Articles : Compiler et optimiser KDE 2.2.2

From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

[^]Re: From Scratch roulez

bonne idée

[^]Re: bonne idée

[^]Re: bonne idée

[^]Re: bonne idée

[^]Re: bonne idée

Javascript

[^]Re: Javascript

[^]Re: Javascript

[^]Re: Javascript

[^]Re: Javascript

[^]Re: Javascript

[+] Gnome rulez , KaDeHEux su><><

[^]Re: Gnome rulez , KaDeHEux su><><

[^]Re: Gnome rulez , KaDeHEux su><><

[^]Re: Gnome rulez , KaDeHEux su><><

Optimisation

[^]Re: Optimisation

[^]Re: Optimisation

[^]beaucoup de conneries

[^]Re: beaucoup de conneries

[^]Re: beaucoup de conneries

[^]Re: beaucoup de conneries

[^]Re: beaucoup de conneries

[^]Re: beaucoup de conneries

[+] l'optimisation maximale pour kde...

[^]binny ....