en fait apres avoir posté j'ai approfondi et compris l'article mais j'avais paas envie de reposter.
[quote]
Alignement sur la plus longue possible qui ne pose pas de problèmes même sur du 32 bits, ça doit même pouvoir être mieux.
[/quote]
mmmh gné? pas tout compris.. sur x86 les opcodes ont une taille variable, en nb d'octets entier...
[quote]
C'est pourtant simple (en théorie) : si l'instruction résultante est plus rapide que celle de départ, qui elle est plus générique.
[/quote]
.. et moins rapide qu'elle meme, sans NOPS.
oui oui. ça revient à justifier l'activation de cette technique, si elle est présente ^^. la question est pourquoi utiliser ceci plutot que deux codes compilés différents. sans doute que c'est parce que (comme je l'ignore) le noyau n'est pas fait avec des DLL. auquel cas on peut switcher entre deux noyaux entiers. (mais pas pendant que ça tourne à cause de l'état des variables etc)
pendant que j'y pense: un autre enorme argument en faveur de la compil specifique est que les regles d'optim des compilos varient d'une famille de pross à l'autre ( c'est pas juste une histoire d'utiliser, ou non, les nouvelles instructions). et ça, c'est pas patchable. et je pense que la recherche de performance du code présent dans le kernel n'est pas à négliger...
bien sur probablement que windows aussi par exemple utilise le plus petit denominateur commun admis pour le systeme (quoique c'est pas si sur...) ; ce truc est bien sur intéressant techniquement, mais je pense que c'est faire (tres) à moitié ce qu'on voulait faire.
[quote]
CPU hotplug, gestion des pertes de CPU, distributions avec kernel générique.
[/quote]
ça n'est valable que si le CPU que tu plugge est différent du précédent au point d'avoir une ISA différente. à supposer que ce soit le cas (sachant que le CPU est mis sur le meme socket, mais c'est possible surement, SSE tout ça)
1.on rajoute un CPU qui n'etait pas là ou on en change un qui a claqué: je suppose que c'est de la RAM partagée et que le code est exécuté par un autre CPU, différent...oh my god! :D
[ceci dit, je ne sais pas exactement comment tout ça se passe et je suis preneur de toute explication/lien...]
2. on change le seul CPU (qui marchait): la, ça a l'air de se tenir, mais il faut avoir reussi a arreter tout le bazar de maniere cohérente.
distributions avec kernel générique: argument valable.
Cependant, on est sur d'avoir presque tout le temps un truc sub-optimal.
juste une note: bien que ça n'enleve rien a leur intéret (ou pas?) , tous les commentaires plus haut sous "optim du temps de boot" n'ont strictement rien a voir avec ce sujet
mes pensees la dessus s'arretent la ce soir, les enfants. daysolay si j'ai pu paraitre hautain.
[^] # Re: optimisation du noyau
Posté par helloworld256 . En réponse à la dépêche Sortie du noyau Linux 2.6.17. Évalué à 1.
[quote]
Alignement sur la plus longue possible qui ne pose pas de problèmes même sur du 32 bits, ça doit même pouvoir être mieux.
[/quote]
mmmh gné? pas tout compris.. sur x86 les opcodes ont une taille variable, en nb d'octets entier...
[quote]
C'est pourtant simple (en théorie) : si l'instruction résultante est plus rapide que celle de départ, qui elle est plus générique.
[/quote]
.. et moins rapide qu'elle meme, sans NOPS.
oui oui. ça revient à justifier l'activation de cette technique, si elle est présente ^^. la question est pourquoi utiliser ceci plutot que deux codes compilés différents. sans doute que c'est parce que (comme je l'ignore) le noyau n'est pas fait avec des DLL. auquel cas on peut switcher entre deux noyaux entiers. (mais pas pendant que ça tourne à cause de l'état des variables etc)
pendant que j'y pense: un autre enorme argument en faveur de la compil specifique est que les regles d'optim des compilos varient d'une famille de pross à l'autre ( c'est pas juste une histoire d'utiliser, ou non, les nouvelles instructions). et ça, c'est pas patchable. et je pense que la recherche de performance du code présent dans le kernel n'est pas à négliger...
bien sur probablement que windows aussi par exemple utilise le plus petit denominateur commun admis pour le systeme (quoique c'est pas si sur...) ; ce truc est bien sur intéressant techniquement, mais je pense que c'est faire (tres) à moitié ce qu'on voulait faire.
[quote]
CPU hotplug, gestion des pertes de CPU, distributions avec kernel générique.
[/quote]
ça n'est valable que si le CPU que tu plugge est différent du précédent au point d'avoir une ISA différente. à supposer que ce soit le cas (sachant que le CPU est mis sur le meme socket, mais c'est possible surement, SSE tout ça)
1.on rajoute un CPU qui n'etait pas là ou on en change un qui a claqué: je suppose que c'est de la RAM partagée et que le code est exécuté par un autre CPU, différent...oh my god! :D
[ceci dit, je ne sais pas exactement comment tout ça se passe et je suis preneur de toute explication/lien...]
2. on change le seul CPU (qui marchait): la, ça a l'air de se tenir, mais il faut avoir reussi a arreter tout le bazar de maniere cohérente.
distributions avec kernel générique: argument valable.
Cependant, on est sur d'avoir presque tout le temps un truc sub-optimal.
juste une note: bien que ça n'enleve rien a leur intéret (ou pas?) , tous les commentaires plus haut sous "optim du temps de boot" n'ont strictement rien a voir avec ce sujet
mes pensees la dessus s'arretent la ce soir, les enfants. daysolay si j'ai pu paraitre hautain.