Poster sur le forum d'intel, en utilisant un wrapper autour de gcc, on peux maintenant compiler le kernel sans aucun patch:
http://softwareforums.intel.com/ids/board/message?board.id=16&m(...)
Il suffit d'utiliser kicc (le wrapper autour de icc) a dlder ici:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107913092300497&(...)
Pas tester chez moi, mais je suis impatient de voir des benchs.
Forum général.général Linux 2.6.9 compile avec icc 8.1 sans modifs!
2
nov.
2004
# Impressionnant
Posté par 007 . Évalué à -10.
Si Visual C compile Linux, fais nous signe. Surtout sur linuxfr.
[^] # Re: Impressionnant
Posté par TheBreton . Évalué à 4.
OK tous le monde n'utilise pas de x86 mais un linux 10 ou 15% plus veloce a l'execution sans changer de config materiel c'est interessant..
[^] # Re: Impressionnant
Posté par Edouard Gomez (site web personnel) . Évalué à 2.
A moins de recompiler toute ta distro avec, tu ne risques pas de voir de grandes différences de perf puisqu'en tant qu'utilisateur tu dépend surtout des applis userspace en terme de perf, non pas que le noyau n'y joue pas un role, mais c'est moins flagrant, car je doute que tu pousses ton noyau dans ses derniers retranchements et qu'il est primordial pour toi que le scheduler tourne en quelques cycles de moins, tout comme la VM ou les syscalls, ou les IRQ handlers ou...
[^] # Re: Impressionnant
Posté par TheBreton . Évalué à 4.
c'est le principe fondateur de gentoo non ?
(http://www.gentoo.org/(...))
le scheduler tourne en quelques cycles de moins
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.
Sur un calcul qui tourne plusieurs jours en gagner une heure ou deux est toujours interressant.
[^] # Re: Impressionnant
Posté par Edouard Gomez (site web personnel) . É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.
[^] # Re: Impressionnant
Posté par LeXav . Évalué à 2.
Déjà c'est l'algorithmique. On dit pas "les mathématies"...
Sinon, c'est vrai qu'un peu d'algo ça fait toujours du bien à l'exécution :)
Mais si la possibilité est donnée d'avoir un compilateur qui génère un code plus propre/performant, alors pourquoi s'en priver ?
[^] # Re: Impressionnant
Posté par dinomasque . Évalué à 3.
Il n'y a qu'à déplacer les applications dans le noyeau !
-> []
BeOS le faisait il y a 20 ans !
[^] # Re: Impressionnant
Posté par 007 . Évalué à 0.
Il est _parfois_ plus rapide mais aussi _parfois_ plus lent. Son intérêt est pour certains calculs flottant.
Si tu recompiles toute une distribution avec ICC, au mieux tu auras 2 % de gain.
Les applications critiques (type mplayer) utilisent déjà de l'assembleur (MMX, SSE, ...) et le noyau/libc utilisent de l'assembleur là où c'est nécessaire.
Pis ICC serait tout le temps plus rapide de 40 % que je resterai avec GCC.
[^] # Re: Impressionnant
Posté par 007 . Évalué à -3.
Bref, la langue de bois est très courrante ici...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.