Bonsoir à vous!

Je souhaiterai savoir si il existe un kernel propre à mon Intel Celeron à 2Ghz ancienne génération.

Pensez-vous que cela puisse ajouter au confort d'utilisation (tout en sachant que ma config est vieille)?

si il existe un kernel propre à mon Intel Celeron il n'y a qu'un seul noyau... c'est justement ce noyau qui s'appelle "Linux" à la base.

Tu peux t'amuser à le compiler toi-même, mais à moins d'avoir une idée précise en tête sur une/des options permettant d'améliorer les performances sur ta machine, tu ne gagneras rien du tout.

En général, la raison qui pousse les gens à recompiler eux-même le noyau est plutôt l'activation d'une option propre à la marque de la machine pour corriger un bogue ou l'ajout/le patchage d'un driver.

Donc il n'y rien qui permet de coller au plus de près des caractérisque de mon cpu?

Je pensais en fait qu'on pouvait avoir un noyau qui s'executerait de sorte à mieux utilisé les cycles de tel ou tel cpu.

Que dit la commande :
$ uname -m
?

i686

Pentium pro quoi

Moi j'ai un Celeron x86 sur socket 478

"j'ai un Celeron x86 sur socket 478" Oui, tu as un beau i686 avec un beau noyau pour i686.

Ne va pas croire qu'il existe du code optimisé pour chaque machine au monde. C'est déjà un travail bestial que de supporter une dizaine de cpu générique...

il y a bien les options -march et -mtune de gcc qui sont cense generer des codes compatible et optimiser pour tel ou tel architecture (en faisant des choix qui dependent des taille de pipeline et cie, des latences des instructions...), mais je ne suis pas bien sur que ca fonctionne vraiment.

Regler la taille des buffers systemes, le scheduling des applications, en utilisant les bon drivers, en utilisant intelligement ses applications (etc), on obtiendra probablement de bien meilleur performances qu'en changeant les parametres de son compilateur.

D'accord, je vous remercie tout cela est très instructif.

On va pas toucher pour le moment hein

godrik
"il y a bien les options -march et -mtune de gcc qui sont cense generer des codes compatible et optimiser pour tel ou tel architecture (en faisant des choix qui dependent des taille de pipeline et cie, des latences des instructions...), mais je ne suis pas bien sur que ca fonctionne vraiment."

Bien sur que ça fonctionne c'est pas juste fait pour faire beau lol. D'où le fait que l'industrie liée aux processeurs à pas mal changé ses dernières années, maintenant on optimise l'architecture du processeur au lieu de monter "betement" en fréquence en suivant la loi de moore.
Dans les distributions "classiques" ton kernel est optimisé pour une famille d'architecture, après tu peux pousser un peu plus loin en optimisant pour un processeur en particulier, je pense que tu peux jeter un coup d'oeil directement à gentoo qui est spécialement conçue pour ça.

Gentoo, Wikipedia
"Sa particularité est la compilation complète (ou en partie) d'un système GNU/Linux à partir des sources, à la manière de Linux From Scratch mais automatisée.

Ses outils de gestion de paquets s'inspirent des ports des BSD. Ce processus permet une optimisation et une personnalisation complète du système mais prend un certain temps pour compiler tous les logiciels nécessaires.

Ce type d'installation permet de tirer parti au mieux de l'architecture de la machine. En effet, le code source sera compilé en tenant compte des optimisations possibles du jeu d'instructions du processeur. La majeure partie des distributions sont compilées avec un jeu d'instructions générique et non pas pour un processeur plus récent, ceci afin de conserver un fonctionnement sur le maximum de machines. Les processeurs plus récents fonctionnent alors de façon minimale sans utiliser les optimisations du fondeur."

Ça résume mieux la chose.

Effectivement ça fonctionne dans le sens où le code généré tire partie au mieux de l'architecture en ordonnant spécifiquement le code et en tirant partie des instructions spécifiques au processeur. Après dans les faits, gagner quelques ticks sur une machine destiné à faire principalement de la bureautique, c'est complètement invisible.
J'avais fait le test sur une machine équipée d'un dual core intel avec 3 stages gentoo :
-- stage x86 avec aucune optimisation
-- stage x86 avec diverses optimisations (march + diverses options de linkage)
-- stage amd64 avec haut niveau d'optimisation (march, O2, gnu-hash pour le linkage,...)

Au final, je n'ai constaté aucune différence de perfs.

Je vois que tu bosses dans l'embarqué temps réel, donc sans doute sur des systèmes critiques qui ont besoin de fortes optimisations, où chaque cycle cpu est précieux. À ce niveau, je ne doute pas que le tunning de code est nécessaire. Sur la machine de l'individu lambda, je doute beaucoup plus.

Sankukai, exactement ce que je voulais dire.
Evidement que ces options d'optimisation font quelque chose.
Cependant mes test sur du calcul numerique ont montre que ca ne servait a rien. Dans le sens ou modifier legerement le code pour eviter quelques appels de fonction critiques ou changer les parametres de deroulement de boucle (et cie), sont beaucoup plus efficace que d'optimiser le code pour une architecture.
basiquement, la seul chose que ca fait, c'est reordonnancer les instructions assembleur pour gagenr sur l'utilisation du pipeline.
90% de ton temps de calcul n'est pas dans le pipeline mais dans des appels de fonctions, des default de cache/de page des entre/sortie, des descente en espace noyaux...
ca ton compilo il n'y peut rien
Alors oui, ces options -march -mtune font quelques chose, mais qudn j'ai du code a faire tourner plus vite, ce n'est definitivement pas par la que je commence!

Et concernant la gestion de l'Hyper-Threading (j'envisage de trouver un P4), il faut un noyau SMP?

Bon, on va faire tout d'un coup :

Que dit la commande :
$ uname -a
?

Linux localhost 2.6.22.19-desktop586-2mdv #1 SMP Mon May 5 20:45:47 EDT 2008 i686 Intel(R) Celeron(R) CPU 2.00GHz GNU/Linux

Il me spécifie bien "SMP", donc c'est cool

Voilà.

@Sankukai

Tu ne peux pas affirmer avec une seule machine de test que ça n'apporte rien sans même expliquer la manière avec laquelle tu as fait tes mesures.
Après je n'ai jamais dit qu'il suffisait de compiler avec certaines options pour gagner 10s au démarrage non plus, et puis tout dépend de ton archi s'il y a vraiment des choses supplémentaires à exploiter "mieux". J'ai simplement répondu à la question, si ça l'intéresse de voir ce que ça fait je ne vois pas ou est le problème.

@godrik
Pour le pipeline je crois que tu le sous estime énormément le temps que ça fait gagner quand c'est utilisé "au mieux". D'ailleurs il n'y à qu'a voir les recherches sur les algo pour les optimiser, il y a énormément d'efforts mis en œuvre par Intel de ce coté quand ils sortent une nouvelle architecture.
De même, tu sous estime l'importance du compilo, suivant le compilo et les options utilisés tu n'auras pas les mêmes temps d'exécutions. Donc tant qu'a faire autant ne pas se mettre une balle dans le pied.

"Alors oui, ces options -march -mtune font quelques chose, mais qudn j'ai du code a faire tourner plus vite, ce n'est definitivement pas par la que je commence! "
Oui mais la on parle de code déjà fait.

Oui bien sûr, je n'ai jamais parlé de benchmark fiable. Je me suis placé dans la situation de l'individu lambda qui se fie plus à son ressenti qu'à un bench qui va montrer qu'en calant un -march=i686 -O3 à gcc on gagne 0,1ms au lancement de firefox.

J'ai simplement répondu à la question, si ça l'intéresse de voir ce que ça fait
je ne vois pas ou est le problème.

Il n'y en a aucun, ne te sens pas agressé. :p
Je répondais plus à la question, qu'à ta remarque. Le point de vue que j'ai avancé est partagé même par les plus gros ricers gentoo, j'ai exprimé cet état de fait afin d'aider l'op dans sa décision. Effectivement, s'il veut mettre les mains dans les options de compilation pour « s'amuser » et apprendre grand bien lui fasse, si au contraire il se casse les dents une semaine sur un truc qui l'emmerde pour aucun bénéfice, il vaut mieux qu'il ait entendu mon point de vue.

subwarez, je ne sous estime pas les options de compilations.
Ce que je dis c'est que:
-gcc est un mauvais compilateur qui genere du code assez peu efficace
-la qualite du pipelining est assez peu importante quand on fait des entres/sortie ou de la descente en espace noyaux. Ce qui represente l'utilisation moyenne d'un ordinateur.
-gcc en -O3 est parfois moins efficace qu'en -O2 (a cause de certaine strategie d'allocation memoire qui foutent le bordel quand on fait trop d'indirection)
-recompiler un noyau est assez chiant. Il faut le maintenir a jour, maintenir la coherence entre le compilo des modules et le compilo du noyau.
-Les problemes de performances dans linux sont des bugs ou des problemes d'architecture et de driver et certainement pas des problemes de compilations
-L'activation des -march et cie sert beaucoup a l'utilisation des instructions vectorielles (mmx et generation superieur) qui sont tres pratiques quand on fait de l'imagerie ou de la compression, mais qui le sont beaucoup moins quand on gere des tables de pages ou des interruptions.

L'utilisation de ces options pour un noyaux me semble relativement inutile.
Apres j'ai fait ce genre d'optimisation sur vlc, mplayer, gzip. Sur ces logiciels, c'est important de bien utiliser l'utilisation du processeur parceque c'est lui qui est critique. Ce n'est pas le cas dans le noyaux ou dans ton window manager.

Je précise pour ceux qui lisent ce thread que gcc -O3 c'est dangereux. Si vous avec le moindre problème avec un soft compilé avec cette option, commencez par le recompiler avec -02. Le niveau d'optimisation n°2 préserve la sémantique du code au moins...