compiler avec ICC

Le
Revolver Onslaught
Bonjour à tous,


J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.
J'ai donc récupéré la dernière version d' ICC (gratuite pour
utilisation non commerciale).

Est-il possible d'utiliser ce compilateur pour :
- recompiler le kernel actuel ?
- les paquets avec apt-build ?

J'ai vu qu'en 2004, il existait KICC, un wrapper pour ICC mais ça fait 4 =
ans

Merci.

R.O.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Basile STARYNKEVITCH
Le #18102291
Revolver Onslaught wrote:
Bonjour à tous,


J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.



Les choses bougent beaucoup de part et d'autre dans les performances des
compilateurs et des processeurs. Attention à bien comparer des versions
récentes (GCC progresse pas mal, notamment avec GCC 4.3)

Sur de grosses applications qui ne sont pas extremement concentrées sur
quelques routines critiques (càd la majorité des applications pour
lesquelles plus des 3/4 du temps sont passés dans moins d'un 1/4 du
code, mais qui n'ont pas 1% du code où passe 95% du temps) :
* les choix algorithmiques sont déterminants.

* le choix des options d'optimisation (il y a autre chose que -O1 -O2 ou
-O3, tous les -f... de gcc par exemple) est peut-être plus important que
le choix du compilateur

* il faut comparer les compilateurs, mais généralement (il y a
évidemment des exceptions) les performances varieront peu (moins de 10%,
et souvent moins de 3%) d'un compilateur à un autre

* le noyau n'est pas déterminant, tout simplement parce que la plupart
des applications passent plus de 90% du temps en dehors du noyau, donc
meme en l'accélérant infiniment (c'est évidemment impossible) on
gagnerait tout au plus 10%

Il y a bien sûr des exceptions, et notamment:

* les gros codes de calcul scientifique, notamment par éléments finis ou
matriciels (mais c'est moins vrai pour des codes probabilistes, style
Monte Carlo)

* certains traitements audio/video ou photo

A mon avis, recompiler le noyau avec icc (ou même recompiler le noyau
juste par souci de performances) n'est pas très utile: la plupart des
applications passent leur temps hors du noyau.

Quelles est donc ton système, tes applications, tes besoins qui te font
vouloir recompiler le noyau et des applications par souci de
performance? A priori je suis en pratique sceptique (la recompilation
finement optimisée te prendra ton temps, et tu risques de gagner moins
de 4% en performance).

N'oublies pas que régler finement les paramètres d'optimisation (je
repète, il y a bien autre chose que -O3!) est en pratique délicat. Voir
http://unidapt.org/publications.html
http://www.fursin.net/research_publ.html http://www.milepost.eu/

Et à mon avis, ca ne sert pas à grand chose de choisir des optimisations fines dans le noyau (c'est difficile, et certaines optimisations peuvent y introduire des bogues) et surtout, puisque ton système passe la plus grande partie de son temps dans du code applicatif, ça ne sert pas à grand chose.


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3500 adhérents http://www.april.org

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
steve
Le #18102651
Le 10-12-2008, à 15:33:02 +0100, Basile STARYNKEVITCH () a écrit :


Sur de grosses applications qui ne sont pas extremement concentrées sur
quelques routines critiques (càd la majorité des applications pour
lesquelles plus des 3/4 du temps sont passés dans moins d'un 1/4 du
code, mais qui n'ont pas 1% du code où passe 95% du temps) :
* les choix algorithmiques sont déterminants.



Tout le monde a compris ?

Pour le reste, merci Basile pour cette explication sans équivoque.

Steve.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Xavier Brochard
Le #18102641
Le mercredi 10 décembre 2008 15:33:02 Basile STARYNKEVITCH, vous avez é crit :
Revolver Onslaught wrote:
> J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
> semble plus performant que GCC.
Et à mon avis, ca ne sert pas à grand chose de choisir des optimisati ons
fines dans le noyau (c'est difficile, et certaines optimisations peuvent y
introduire des bogues) et surtout, puisque ton système passe la plus gr ande
partie de son temps dans du code applicatif, ça ne sert pas à grand c hose.



Et d'ailleurs (pour ce que ça vaut) en 1996 j'ai fait l'expérience d'un
système "optimisé" comparé à un système "non-optimisé" mais ave c un disque dur
récent tournant beaucoup plus vite...
C'était sur du traitement d'image 3D.
Il y avait bien un écart de performance, faible certes, mais pas du tout dans
le sens attendu: la vitesse de rotation du disque était prépondérante
(l'application de traitement d'image créait des fichiers temporaires).
J'en ai définitivement conclu que plutôt qu'optimiser le compilo ou le système,
j'avais plus vite fait d'optimiser le matériel - pour pas cher en plus.

--
Xavier

09 54 06 16 26

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Revolver Onslaught
Le #18107911
2008/12/10 Basile STARYNKEVITCH
Revolver Onslaught wrote:

Bonjour à tous,


J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.



Les choses bougent beaucoup de part et d'autre dans les performances des
compilateurs et des processeurs. Attention à bien comparer des versions
récentes (GCC progresse pas mal, notamment avec GCC 4.3)

Sur de grosses applications qui ne sont pas extremement concentrées sur
quelques routines critiques (càd la majorité des applications pour
lesquelles plus des 3/4 du temps sont passés dans moins d'un 1/4 du cod e,
mais qui n'ont pas 1% du code où passe 95% du temps) :
* les choix algorithmiques sont déterminants.

* le choix des options d'optimisation (il y a autre chose que -O1 -O2 ou
-O3, tous les -f... de gcc par exemple) est peut-être plus important qu e le
choix du compilateur



L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par Google
à l'époque où j'étais sur Gentoo. Je n'ai plus le lien)


* il faut comparer les compilateurs, mais généralement (il y a évid emment
des exceptions) les performances varieront peu (moins de 10%, et souvent
moins de 3%) d'un compilateur à un autre



DAns mon cas, même 3% est toujours intéressant à prendre. ;o)


* le noyau n'est pas déterminant, tout simplement parce que la plupart des
applications passent plus de 90% du temps en dehors du noyau, donc meme e n
l'accélérant infiniment (c'est évidemment impossible) on gagnerait tout au
plus 10%

Il y a bien sûr des exceptions, et notamment:

* les gros codes de calcul scientifique, notamment par éléments finis ou
matriciels (mais c'est moins vrai pour des codes probabilistes, style Mon te
Carlo)

* certains traitements audio/video ou photo

A mon avis, recompiler le noyau avec icc (ou même recompiler le noyau j uste
par souci de performances) n'est pas très utile: la plupart des applica tions
passent leur temps hors du noyau.

Quelles est donc ton système, tes applications, tes besoins qui te font
vouloir recompiler le noyau et des applications par souci de performance? A
priori je suis en pratique sceptique (la recompilation finement optimis ée te
prendra ton temps, et tu risques de gagner moins de 4% en performance).



Mon système est un serveur postfix amélioré. Plus clairement, nous di sposons
de plusieurs dizaines de serveurs. Nous avons gagné plus de 30 points CPU sur
un ClamAV compilé avec ICC par rapport à la version compilée avec GC C.
Bien que ClamAV ne soit pas appellé la major partie du temps, ces quelque s
points de CPU gagnés ici et là nous amènent à économiser des mach ines.


N'oublies pas que régler finement les paramètres d'optimisation (je r epète,
il y a bien autre chose que -O3!) est en pratique délicat. Voir
http://unidapt.org/publications.html
http://www.fursin.net/research_publ.html http://www.milepost.eu/



Voir mon opinion sur -O3 plus haut. Je suis d'accord sur les options
de compilations determinantes.


Et à mon avis, ca ne sert pas à grand chose de choisir des optimisati ons
fines dans le noyau (c'est difficile, et certaines optimisations peuvent y
introduire des bogues) et surtout, puisque ton système passe la plus gr ande
partie de son temps dans du code applicatif, ça ne sert pas à grand c hose.



C'est noté mais je m'attendais à un gain, même lèger.

Merci pour tes réponses.



--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3500 adhérents http://www.april.org





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Basile STARYNKEVITCH
Le #18109381
Revolver Onslaught wrote:

L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par Google
à l'époque où j'étais sur Gentoo. Je n'ai plus le lien)



A mon avis, c'est faux. -O3 fonctionne bien sur du code qui suit très
précisément les normes. Et par expérience, ça fonctionne bien sur un
grand nombre de logiciels libres (comme emacs, make, bash, ...). Essaies
donc de recompiler ton application actuelle avec un gcc récent (4.3) en -O3!

* il faut comparer les compilateurs, mais généralement (il y a évidemment
des exceptions) les performances varieront peu (moins de 10%, et souvent
moins de 3%) d'un compilateur à un autre




DAns mon cas, même 3% est toujours intéressant à prendre. ;o)

Mon système est un serveur postfix amélioré. Plus clairement, nous disposons
de plusieurs dizaines de serveurs. Nous avons gagné plus de 30 points CPU sur
un ClamAV compilé avec ICC par rapport à la version compilée avec GCC.
Bien que ClamAV ne soit pas appellé la major partie du temps, ces quelques
points de CPU gagnés ici et là nous amènent à économiser des machines.



J'ai quand même du mal à comprendre la réalité économique de la chose.
Imaginons que tu passes une semaine à peaufiner la compilation de
plusieurs logiciels pour gagner 3% (donc, si tu as un parc de 30
machines, ça économise une machine). J'ignore combien tu coûtes à ton
employeur, mais le chiffre usuel du coût total d'un ingénieur est 150k€
par an (c'est par exemple ce que facturerait une SSII; je parle bien
d'un coût total, pas de ton salaire seul!). Pour une semaine de travail,
ca fait nettement plus cher qu'une machine. Même si tu coûtais deux fois
mois cher (donc seulement 75k€/an) ça ne vaudrait pas forcément le coup.

Optimiser aussi finement (cad pour gagner quelques pourcents) n'est
économiquement rentable que dans des cas très particuliers, où on
déploie sur beaucoup de machines (cad des milliers), ou bien où on a une
application très gourmande sur des très grosses machines.

Le cas extrême, c'est Google (dont la taille du parc est tenu secret,
mais on parle de centaines de milliers). Là, augmenter de quelques
pouillèmes les performances de GCC justifie (et c'est le cas chez
Google) des équipes de plus d'une dizaine de développeurs extrêmement
qualifiés travaillant sur GCC (et aussi binutils), notamment Diego
Novillo & Ian Taylor.

Mais j'aurais tendance à penser que si ton management te demande de
passer une semaine à optimiser clamav pour seulement 30 machines (et
donc dans l'espoir d'en gagner tout au plus une seule), ce n'est pas un
très bon management. En plus, il pourrait être possible qu'un simple
changement de configuration (au sens sysadmin) fasse l'affaire.

Si tu as le temps, racontes nous tes résultats d'optimisation, en terme
de gains de performances. Et si tu utilises GCC, n'oublies pas d'en
prendre une version récente: GCC 4.3 optimise bien mieux que 4.0 ou 3.4!

Cordialement

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3500 adhérents http://www.april.org

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Yves Rutschle
Le #18109951
On Wed, Dec 10, 2008 at 11:11:52PM +0100, Revolver Onslaught wrote:
> * le choix des options d'optimisation (il y a autre chose que -O1 -O2 ou
> -O3, tous les -f... de gcc par exemple) est peut-être plus important que le
> choix du compilateur

L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par Google
à l'époque où j'étais sur Gentoo. Je n'ai plus le lien)



(Pour Basile: Je pense qu'ici il ne parle que de la
compilation du noyau, qui est connu effectivement pour être
un peu "touchy" au niveau des options: pendant toute une
période on disait qu'il fallait utiliser -O2, ni plus, ni
moins... le code du noyau poussant souvent le compilateur
dans ses retranchements. Je ne sais pas si c'est toujours le
cas aujourd'hui).

Mon système est un serveur postfix amélioré. Plus clairement, nous disposons
de plusieurs dizaines de serveurs. Nous avons gagné plus de 30 points CPU sur
un ClamAV compilé avec ICC par rapport à la version compilée avec GCC.
Bien que ClamAV ne soit pas appellé la major partie du temps, ces quelques
points de CPU gagnés ici et là nous amènent à économiser des machines.



Faut regarder la "big picture": un serveur de mail va passer
son temps à attendre le matériel (disque d'un coté, réseau
de l'autre). Ce qui peut utiliser du CPU dans un serveur de
mail, c'est effectivement les scans: anti-virus et
spamassassin, et peut-être les classements automatiques
(sans doute de façon négligeable).

AMHA, tu as déjà optimisé tout ce qui était optimisable de
ce coté là.

Y.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Revolver Onslaught
Le #18110661
2008/12/11 Basile STARYNKEVITCH
Revolver Onslaught wrote:

L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par
Google
à l'époque où j'étais sur Gentoo. Je n'ai plus le lien)




A mon avis, c'est faux. -O3 fonctionne bien sur du code qui suit très
précisément les normes. Et par expérience, ça fonctionne bien sur un grand
nombre de logiciels libres (comme emacs, make, bash, ...). Essaies donc d e
recompiler ton application actuelle avec un gcc récent (4.3) en -O3!






"Using -O3 is not recommended for gcc 4.x."
(http://www.gentoo.org/doc/en/gcc-optimization.xml)
A tester, effectivement.



* il faut comparer les compilateurs, mais généralement (il y a év idemment
des exceptions) les performances varieront peu (moins de 10%, et souven t
moins de 3%) d'un compilateur à un autre




DAns mon cas, même 3% est toujours intéressant à prendre. ;o)

Mon système est un serveur postfix amélioré. Plus clairement, nous
disposons
de plusieurs dizaines de serveurs. Nous avons gagné plus de 30 points CPU
sur
un ClamAV compilé avec ICC par rapport à la version compilée avec GCC.
Bien que ClamAV ne soit pas appellé la major partie du temps, ces quel ques
points de CPU gagnés ici et là nous amènent à économiser des m achines.



J'ai quand même du mal à comprendre la réalité économique de la chose.
Imaginons que tu passes une semaine à peaufiner la compilation de plusi eurs
logiciels pour gagner 3% (donc, si tu as un parc de 30 machines, ça
économise une machine). J'ignore combien tu coûtes à ton employeur, mais le
chiffre usuel du coût total d'un ingénieur est 150k€ par an (c'est par
exemple ce que facturerait une SSII; je parle bien d'un coût total, pas de
ton salaire seul!). Pour une semaine de travail, ca fait nettement plus c her
qu'une machine. Même si tu coûtais deux fois mois cher (donc seulemen t
75k€/an) ça ne vaudrait pas forcément le coup.



Effectivement, sur 30 machines, ça vaut pas le coup, mais à notre
échelle et au prix du serveur, là, ça vaut le coup.


Optimiser aussi finement (cad pour gagner quelques pourcents) n'est
économiquement rentable que dans des cas très particuliers, où on d éploie
sur beaucoup de machines (cad des milliers), ou bien où on a une applic ation
très gourmande sur des très grosses machines.



C'est la cas. Clam est consommateur et les machines sont des bêtes de cou rse.


Le cas extrême, c'est Google (dont la taille du parc est tenu secret, m ais
on parle de centaines de milliers). Là, augmenter de quelques pouillè mes les
performances de GCC justifie (et c'est le cas chez Google) des équipes de
plus d'une dizaine de développeurs extrêmement qualifiés travaillan t sur GCC
(et aussi binutils), notamment Diego Novillo & Ian Taylor.

Mais j'aurais tendance à penser que si ton management te demande de pas ser
une semaine à optimiser clamav pour seulement 30 machines (et donc dans
l'espoir d'en gagner tout au plus une seule), ce n'est pas un très bon
management. En plus, il pourrait être possible qu'un simple changement de
configuration (au sens sysadmin) fasse l'affaire.

Si tu as le temps, racontes nous tes résultats d'optimisation, en terme de
gains de performances. Et si tu utilises GCC, n'oublies pas d'en prendre une
version récente: GCC 4.3 optimise bien mieux que 4.0 ou 3.4!



Pas de soucis et merci.


Cordialement

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
membre de l'APRIL "promouvoir et défendre le logiciel libre"
Rejoignez maitenant pplus de 3500 adhérents http://www.april.org





--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/DebFrFrenchLists
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"

To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Publicité
Poster une réponse
Anonyme