>comme souvent les programmes passe 80% de leur temps dans 20% de leur code gagner quelque cycles sur le task-switching provoque un gain de temps non negligable.
Premierement, le coup des 80/20 c du mythe, un programme bien conçue répartit le boulot de facon harmonieuse sur l'ensemble du code et n'aboutit jamais à de telles proportions, a moins d'avoir une vue macroscopique de ton appli.
Ces 80% dont tu parles n'ont rien a voir avec le task switching. Car à moins que ton appli soit mal concu et soit IO bound il n'y a aucune raison qu'elle passe son temps à switcher en mode noyau<->mode utilisateur. Une application IO bound n'est de toute facon pas optimisable, à moins de réduire les entrées sorties, ou d'optimiser les entrées sorties elles même.
De plus le task switching depend bcp de l'implémentation hardware pour sauvergarder/restaurer les contextes CPU/Memoire paginée.
>Sur un calcul qui tourne plusieurs jours en gagner une heure ou deux est toujours interressant.
Si tu sais que ton appli va tourner des jours, et est tres gourmande en CPU, la premiere chose a laquelle il faut penser c'est de parametrer le scheduler afin qu'il lui alloue des time slices plus grands, ou des time slice plus reguliers, nice est la pour ca. Des fois il faut même faire tourner la tache dans un mode non SCHED_NORMAL, genre SCHED_ISO (Patch Con kolivas, mode RT du pauvre :-) ), SCHED_RT (si tu veux vraiment que ta tache soit prioritaire vis a vis de toutes les taches NORMAL) ou SCHED_BATCH (Patch con kolivas, si ta tache est absolument non prioritaire, genre seti@home)...
Bref, l'important c'est 1) que le programme qui tourne soit optimisé 2) parametrer ton noyau pour donner plus d'importance à ce même programme. Et à moins que ton programme depende d'une entree sortie sur un quelconque périphérique, à même code noyau et machine et code user, le fait de changer de compilo pour le noyau n'apportera pas grand chose.
Exemple:
xvidcore 1.1-cvs sur un noyau vanilla (decompression d'une sequence mpeg4): 215s
xvidcore 1.1-cvs sur un noyau con kolivas buggé dans sa gestion des time slice (vers les 2.6.7-ckX): 187s
xvidcore 1.1-cvs noyau vanilla, les deux choses compilés avec des options "alacon" genre -O9 -fplein-de-trucs-toussa, 213s.
Le gain de perf n'etait pas du a un chgt de compilo, mais bien au fait que le scheduler allouait des timeslices trop importants aux taches gourmandes en CPU (laissant ainsi les autres taches sans CPU... il s'agissait d'un bug), mais c'est pour te montrer que l'algorithmie donne des résultats plus "voyants" que l'optimisation brute par chgt de compilo/options.
[^] # Re: Impressionnant
Posté par Edouard Gomez . En réponse au message Linux 2.6.9 compile avec icc 8.1 sans modifs!. Évalué à 4.
Premierement, le coup des 80/20 c du mythe, un programme bien conçue répartit le boulot de facon harmonieuse sur l'ensemble du code et n'aboutit jamais à de telles proportions, a moins d'avoir une vue macroscopique de ton appli.
Ces 80% dont tu parles n'ont rien a voir avec le task switching. Car à moins que ton appli soit mal concu et soit IO bound il n'y a aucune raison qu'elle passe son temps à switcher en mode noyau<->mode utilisateur. Une application IO bound n'est de toute facon pas optimisable, à moins de réduire les entrées sorties, ou d'optimiser les entrées sorties elles même.
De plus le task switching depend bcp de l'implémentation hardware pour sauvergarder/restaurer les contextes CPU/Memoire paginée.
>Sur un calcul qui tourne plusieurs jours en gagner une heure ou deux est toujours interressant.
Si tu sais que ton appli va tourner des jours, et est tres gourmande en CPU, la premiere chose a laquelle il faut penser c'est de parametrer le scheduler afin qu'il lui alloue des time slices plus grands, ou des time slice plus reguliers, nice est la pour ca. Des fois il faut même faire tourner la tache dans un mode non SCHED_NORMAL, genre SCHED_ISO (Patch Con kolivas, mode RT du pauvre :-) ), SCHED_RT (si tu veux vraiment que ta tache soit prioritaire vis a vis de toutes les taches NORMAL) ou SCHED_BATCH (Patch con kolivas, si ta tache est absolument non prioritaire, genre seti@home)...
Bref, l'important c'est 1) que le programme qui tourne soit optimisé 2) parametrer ton noyau pour donner plus d'importance à ce même programme. Et à moins que ton programme depende d'une entree sortie sur un quelconque périphérique, à même code noyau et machine et code user, le fait de changer de compilo pour le noyau n'apportera pas grand chose.
Exemple:
xvidcore 1.1-cvs sur un noyau vanilla (decompression d'une sequence mpeg4): 215s
xvidcore 1.1-cvs sur un noyau con kolivas buggé dans sa gestion des time slice (vers les 2.6.7-ckX): 187s
xvidcore 1.1-cvs noyau vanilla, les deux choses compilés avec des options "alacon" genre -O9 -fplein-de-trucs-toussa, 213s.
Le gain de perf n'etait pas du a un chgt de compilo, mais bien au fait que le scheduler allouait des timeslices trop importants aux taches gourmandes en CPU (laissant ainsi les autres taches sans CPU... il s'agissait d'un bug), mais c'est pour te montrer que l'algorithmie donne des résultats plus "voyants" que l'optimisation brute par chgt de compilo/options.