Bonjour à tous,
J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.
Bonjour à tous,
J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.
Bonjour à tous,
J'ai découvert ICC, le compilateur C++ d'Intel. D'après Google, il
semble plus performant que GCC.
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.
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.
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.
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.
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.
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.
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
* 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
* 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).
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/
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.
--
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
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
* 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
* 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).
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/
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.
--
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
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
* 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
* 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).
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/
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.
--
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
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 é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.
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 é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.
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 é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.
> * 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)
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.
> * 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)
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.
> * 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)
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.
Revolver Onslaught wrote:
L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par
à 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!
* 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.
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.
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!
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
Revolver Onslaught wrote:
L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par
à 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!
* 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.
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.
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!
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
Revolver Onslaught wrote:
L'utilisation de -O3 est à proscrire depuis GCC-4.3 (j'avais trouvé par
à 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!
* 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.
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.
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!
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