Journal Linux devient-il comme Linus : obèse ?

Posté par  .
Étiquettes : aucune
0
23
avr.
2004
Soit un Pentium 200 Mz (le prototype des bécannes qui nous servent de consoles d'administration) avec 128 Mo de RAM.
Une compilation avec GCC 2.95 des sources du noyau 2.4.25 dure 40 mn et le vmlinuz obtenu pèse 700 Ko.
La compilation avec GCC 3.3 des sources du noyau 2.6.5 dure 1h30 et le vmlinuz pèse cette fois-ci 1,2 Mo !
Je précise que, dans les deux cas, seules les options strictement nécessaires au (bon) fonctionnement du PC ont été retenues.
Alors je me pose une question : à quoi sert de rajouter des milliers de lignes de code pour obtenir finalement un noyau dont l'embonpoint frise l'obésité et dont les gains de performance ne sont pas perceptibles ?
La question se pose également avec GCC pour lequel la vitesse de compilation paraît être inversement proportionnelle au numéro de version....
Bref, il serait temps que Linus fasse un peu de sport http://pcweb.mycom.co.jp/news/2001/02/02/07bl.jpg(...) !
Hé , les moules ! vos vmlinuz pèsent combien ?

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 4.

    ben pourquoi changer de version si celle que tu as fonctionne bien et qu'en plus tu sais que tu gagneras peu en performance ?

  • # Re: Linux devient-il comme Linus : obèse ?

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

    Et les inverse ca donne quoi?

    GCC 2.95 pour kernel 2.6.5
    GCC 3.3 pour kernel 2.4.25

    Quoi, comment ca je prend la porte?

    ===>[]

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 1.

    C'est pas ses abdos sur la photo ?

    Quoi ?
    C'est ouvert ? ha oui là
    -->[]

  • # Re: Linux devient-il comme Linus : obèse ?

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

    http://www.isaacos.com(...)

    C'est très très mal expliqué, mais bon...

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Re: Linux devient-il comme Linus : obèse ?

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

    plusieurs points à noter.
    - il est connu que gcc 3 compile moins vite que le 2. Beaucoup râlent à ce sujet.
    - 500 ko sur le disque, je ne vois pas le problème. De plus, il existe une option ("CONFIG_EMBEDDED") pour les noyaux embarqués, permettant de gagner beaucoup de place.
    - ton test, comme l'a dit lezius, est foiré, parce que quand on compare la compilation de deux codes différents, il faut le faire avec le même compilateur.
    - gcc "paraît" plus lent. C'est vrai, mais quand on compare deux compilateurs, il faut le faire avec le même code.

    Ton test se rapproche d'une course automobile avec deux concurrents, Mamie dans sa ferrari et Prost dans ma mazda rouge.

    (point supplémentaire:
    - je pense que les développeurs du kernel ont rajouté des milliers de ligne de code qui ne servent à rien pour faire semblant de travailler, quelle question.)

    • [^] # Re: Linux devient-il comme Linus : obèse ?

      Posté par  . Évalué à -3.

      Mon propos concerne surtout le poids des vmlinuz obtenus sur le même matériel. C'est quand même embètant de passer de 700 Ko à 1,2 Mo !

      • [^] # Re: Linux devient-il comme Linus : obèse ?

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

        Mais pas avec le même compilo donc ça ne veut rien dire !
        Et de toute façon, vu les différences entre le 2.4 et le 2.6 c'est tout à fait normal que ça change de taille.

        Reste en 2.4.x si ça te gène tant de perdre 500 ko.

      • [^] # Re: Linux devient-il comme Linus : obèse ?

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

        Prend le meme compilot pour avoir une difference de taille significative. Dans l'etat actuel des chose ca ne signifie rein. Peut etre que GCC 3.3 rajoute des protection en plus contre les buffer overflow ou je sais pas quoi qui produise une augmentation de code.

        D'ailleur pour etre bien faudrait prendre 1GCC pour compiler tes 2 GCC avec les meme option de compilation. Puis compiler tes 2 noyeau avec chacun des GCC en ayant les meme option de compilation pour chaque GCC et les meme options des noyaux.

      • [^] # Re: Linux devient-il comme Linus : obèse ?

        Posté par  . Évalué à 1.

        Un autre point important: As-tu compilé un noyau monolithique?
        Si non, donne aussi la taille cumulée de tous les modules compilés.

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 1.

    886 ko pour un 2.4.26, compile avec gcc 3.2.3, en 20-30 minutes

    • [^] # Re: Linux devient-il comme Linus : obèse ?

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

      manque les caracteristiques de la machines de la compil.

      Bref, et ca c'est une base dans toute science pour toute experience :

      Pour etudier l'influance d'un parametre il faut que seulement ce paramettre change, le reste du contexte devant etre conservé (base des cours de sciences du college et/ou lycee voir meme primaire). Exemple la version de gcc xor la frequence du proc xor la quantité de ram xor la version du noyau xor les option du noyau (bon ok, celle la c'est plus dure si y'a changement de noyau)....

  • # Re: Linux devient-il comme Linus : obèse ?

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

    Quelles options de compilation ?

    Si -O2 est activé, c'est normal que le code soit plus volumineux mais il est peut-être plus rapide à l'exécution. Avec gcc 3, peut-être que les optimisations sont encore meilleures, mais au détriment de la taille du code qui augmente...

    • [^] # Re: Linux devient-il comme Linus : obèse ?

      Posté par  . Évalué à -2.

      Avec gcc 3, peut-être que les optimisations sont encore meilleures
      A l'utilisation, ce n'est pas du tout évident !

      • [^] # Re: Linux devient-il comme Linus : obèse ?

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

        Ca depend du type d'optimisation que tu cherche. Une option de compilation "inline" va grossir la taille de ton binaire mais augmenter ca rapiditer d'execution.

        Mais bon de toute maniere si tu compare pas reelement (i.e. avec un protocole experimental correcte et pas ce que tu propose au debut) c'est sur que c'est pas evident.

        La ce que tu fait c'est genre si pour comparer les perf de leur nouveau moteur (kernel) a celui de l'ancien ferrari metait dans la meme voiture (pc) l'ancien moteur (K2.4.25) avec Shumi (GCC 2.95) comme pilote et le nouveau moteur (K2.6.5) avec Mamie (GCC 3.3) comme pilote. Moralité tu sais pas si c'est le nouveau moteur qui est moins performant ou le nouveau pilote.

  • # Re: Linux devient-il comme Linus : obèse ?

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

    depuis quand on mesure les fonctionnalités d'un OS à la taille du noyau ?

    Qui plus est, 500ko, c'est vraiment rien, même pour un p200 ...

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 4.

    Je ne sais pas si ce que je vais dire est totalement juste mais je tente le coup.

    Dans le texte du journal il est dit :

    Alors je me pose une question : à quoi sert de rajouter des milliers de lignes de code pour obtenir finalement un noyau dont l'embonpoint frise l'obésité et dont les gains de performance ne sont pas perceptibles ?

    Je pense que c'est normal et meme logique sur le matériel cité.

    En effet, le kernel 2.6 possede des fonctionnalités supplémentaires pour gérer les nouvelles fonctionnalités des nouveaux hardwares.

    Donc sur un hardware récent, le kernel 2.6 est susceptible d'offrir des meilleures performance que le 2.4 (J'AI DIT SUSCEPTIBLE, pas frapper j'ai pas fait de tests, donc c'est une simple conjocture).

    Sur un vieux hardware, les optimisations et nouvelles fonctionnalité du kernel 2.6 ne serviront à rien, puisque de toute facon, ledit vieux hard ne les gére pas. Donc, les performence seront quasi identique avec les deux kernels sur un vieux hardware.

    • [^] # Re: Linux devient-il comme Linus : obèse ?

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

      Je pense que le nouveau noyau ne fait pas que rajouter du support hardware. Il le fait, c'est évident, mais il n'y a pas que ça : voir les nombreux articles sur le sujet lors de la sortie du 2.6.0.

      Par exemple, il y a le developpement de sysfs, l'ordonanceur (? "scheduler) qui est plus efficace, la gestion multiprocesseurs (même les vieux :) améliorées, le kernel préemptible...

    • [^] # Re: Linux devient-il comme Linus : obèse ?

      Posté par  . Évalué à 3.

      si si le 2.6 ça peut être bien sur du vieux matos, le gestionnaire i/o fait des merveilles sur les vieux disques durs.

      • [^] # Re: Linux devient-il comme Linus : obèse ?

        Posté par  . Évalué à 2.

        oui, oui, je suis d'accord, mais le gain n'est peut etre pas le meme que quand on passe d'une d'un disque avec controleur IDE de base à un disque UDMA 133 gestion optimisé. Or sur un p200 mmx, je suis pas certain que ca existe.

        Et c'est clair qu'il y a plein d'autre chose qu'apporte le 2.6, je ne dis pas le contraire non plus, mais je pense encore que si la machine est vraiment trop vieille et franchement pas performante, on ne va pas aller loin.


        parce que meme si, en exagerant a mort, le passage du 2.4 au 2.6 permettait d'apporter 50% de perf globale en plus sur le 200 mmx, ca ne ferai que l'equivalent d'un 250 mmx (la c'est plus que de l'approximation, mais c'est histoire de faire une comparaison) avec IO plus rapide. Ce qui reste quand meme tres lents (par rapportau standard premier prix actuel).

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 1.

    Tu devrais utiliser le 2.4.26, il corrige une faille de sécurité.

  • # Re: Linux devient-il comme Linus : obèse ?

    Posté par  . Évalué à 1.

    Ba moi j'ai un 2.4.22 sur un 486 (j'ai besoin de préciser la fréquence ? Ha oui, 66Mhz), et c'est pas top non plus.

    Mais j'ai pas essayé le 2.6 avec gcc 3.2 :-))

    je prend de l'élan et hop

    ===> []

Suivre le flux des commentaires

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