Bonjour tout le monde!
J'envisage, après 3 ans de Mandrake, d'essayer de passer à Gentoo.
C'est pour une utilisation Desktop classique, et mon problème c'est
qu'il y plein de choses installés dans la Mandrake dont je ne me sers
jamais, et plein de choses dont j'ai vraiment besoin qui ne sont pas
disponibles sur les CD....
J'ai assez l'habitude d'installer en compilant les sources, le principe
de Gentoo ne me dérange pas.
Je me demande simplement si ça vaut vraiment d'installer Gentoo à partir
du Stage1 (tout compiler) ?? Remarque t'on vraiment une hausse
sensible des performances ??
J'ai un AthlonXP 1800+, 512 de Ram et adsl 512, j'attends vos remarques
et conseils sur Gentoo, ou même une autre distrib que l'on peut mettre à
jour facilement...
Merci d'avance!
Et concretement, ça apporte quoi de recompiler les sources à chaque fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement
à
couper le souffle.
Tu as des preuves de ce que tu avances ?
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de l'essayer, tu ne crois pas? :-)
++
Tiscali
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires compilés pour être distribués utilisent du code machine qui marche à peut près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
++
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news:buc0b1$2k7t$4@asmodee.lpthe.jussieu.fr...
Sam Hocevar <sam+news@zoy.org> wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque
fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont
réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc
a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires
compilés pour être distribués utilisent du code machine qui marche à peut
près partout. Si tu compiles un binaire spécifiquement pour ton système,
celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires compilés pour être distribués utilisent du code machine qui marche à peut près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
++
talon
Tiscali wrote:
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires compilés pour être distribués utilisent du code machine qui marche à peut près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même passé pas mal de temps à étudier l'assembleur produit par le compilateur à différents niveaux d'optimisation et à benchmarker le résultat. Donc ma conviction, c'est que pour la plupart des programmes, aller au delà de -O est peu utile avec gcc-2.95. Par contre il est notoire que des bugs existent avec par exemple -march=P4 jusqu'à des versions trés récentes du compilo. Donc à toi l'honneur ...
++
--
Michel TALON
Tiscali <alexandrechatty@tiscali.fr> wrote:
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news:buc0b1$2k7t$4@asmodee.lpthe.jussieu.fr...
Sam Hocevar <sam+news@zoy.org> wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque
fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont
réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc
a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires
compilés pour être distribués utilisent du code machine qui marche à peut
près partout. Si tu compiles un binaire spécifiquement pour ton système,
celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même
passé pas mal de temps à étudier l'assembleur produit par le compilateur
à différents niveaux d'optimisation et à benchmarker le résultat. Donc
ma conviction, c'est que pour la plupart des programmes, aller au delà
de -O est peu utile avec gcc-2.95. Par contre il est notoire que des
bugs existent avec par exemple -march=P4 jusqu'à des versions trés
récentes du compilo. Donc à toi l'honneur ...
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires compilés pour être distribués utilisent du code machine qui marche à peut près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même passé pas mal de temps à étudier l'assembleur produit par le compilateur à différents niveaux d'optimisation et à benchmarker le résultat. Donc ma conviction, c'est que pour la plupart des programmes, aller au delà de -O est peu utile avec gcc-2.95. Par contre il est notoire que des bugs existent avec par exemple -march=P4 jusqu'à des versions trés récentes du compilo. Donc à toi l'honneur ...
++
--
Michel TALON
Irvin Probst
On 2004-01-17, Tiscali wrote:
Tu as des preuves de ce que tu avances ?
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu près la meme époque et je pense pas mal me débrouiller en compilation, donc pour ce qui est d'essayer j'ai déjà fait rassure toi. Dois-je préciser que je n'ai jamais remarqué de différence de performances "à couper le souffle" (sauf dans le cas d'un Makefile mal fait) ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
On 2004-01-17, Tiscali <alexandrechatty@tiscali.fr> wrote:
Tu as des preuves de ce que tu avances ?
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de
l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu
près la meme époque et je pense pas mal me débrouiller en compilation,
donc pour ce qui est d'essayer j'ai déjà fait rassure toi.
Dois-je préciser que je n'ai jamais remarqué de différence de
performances "à couper le souffle" (sauf dans le cas d'un Makefile mal
fait) ?
--
Irvin Probst
There are 10 types of people in the world... those who understand binary
and those who don't.
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu près la meme époque et je pense pas mal me débrouiller en compilation, donc pour ce qui est d'essayer j'ai déjà fait rassure toi. Dois-je préciser que je n'ai jamais remarqué de différence de performances "à couper le souffle" (sauf dans le cas d'un Makefile mal fait) ?
-- Irvin Probst There are 10 types of people in the world... those who understand binary and those who don't.
Tiscali
"Irvin Probst" a écrit dans le message de news:
On 2004-01-17, Tiscali wrote:
Tu as des preuves de ce que tu avances ?
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu près la meme époque et je pense pas mal me débrouiller en compilation, donc pour ce qui est d'essayer j'ai déjà fait rassure toi. Dois-je préciser que je n'ai jamais remarqué de différence de performances "à couper le souffle" (sauf dans le cas d'un Makefile mal fait) ?
je parlais de Gentoo pour les performances, pas d'un programme isolé.
++
"Irvin Probst" <irvin@trinity.irvinig.org> a écrit dans le message de
news:slrnc0jjr6.qlg.irvin@trinity.irvinig.org...
On 2004-01-17, Tiscali <alexandrechatty@tiscali.fr> wrote:
Tu as des preuves de ce que tu avances ?
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de
l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu
près la meme époque et je pense pas mal me débrouiller en compilation,
donc pour ce qui est d'essayer j'ai déjà fait rassure toi.
Dois-je préciser que je n'ai jamais remarqué de différence de
performances "à couper le souffle" (sauf dans le cas d'un Makefile mal
fait) ?
je parlais de Gentoo pour les performances, pas d'un programme isolé.
Je pourrais m'amuser à ça, mais le plus simple, ça reste quand même de l'essayer, tu ne crois pas? :-)
Et bien écoute, j'utilise Linux depuis 1996, je fais du C depuis à peu près la meme époque et je pense pas mal me débrouiller en compilation, donc pour ce qui est d'essayer j'ai déjà fait rassure toi. Dois-je préciser que je n'ai jamais remarqué de différence de performances "à couper le souffle" (sauf dans le cas d'un Makefile mal fait) ?
je parlais de Gentoo pour les performances, pas d'un programme isolé.
++
Tiscali
heu, désolé, je ne sais pas trop quoi enlever là dedans...
"Michel Talon" a écrit dans le message de news:buchik$2r4d$
Tiscali wrote:
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque
fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc
a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires
compilés pour être distribués utilisent du code machine qui marche à peut
près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même passé pas mal de temps à étudier l'assembleur produit par le compilateur à différents niveaux d'optimisation et à benchmarker le résultat. Donc ma conviction, c'est que pour la plupart des programmes, aller au delà de -O est peu utile avec gcc-2.95. Par contre il est notoire que des bugs existent avec par exemple -march=P4 jusqu'à des versions trés récentes du compilo. Donc à toi l'honneur ...
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo, maintenant, je reconnais que ça devient compliqué à lire. Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles. A mon avis c'est bien là l'interêt de compiler soit-même les sources. Et pour ne pas avoir à écrire [HS] dans l'objet, je dirais en conclusion que c'est un avantage de Gentoo que de combiner simplicité de prise en main et installation à partir des sources.
++
heu, désolé, je ne sais pas trop quoi enlever là dedans...
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news:buchik$2r4d$1@asmodee.lpthe.jussieu.fr...
Tiscali <alexandrechatty@tiscali.fr> wrote:
"Michel Talon" <talon@lpthe.jussieu.fr> a écrit dans le message de
news:buc0b1$2k7t$4@asmodee.lpthe.jussieu.fr...
Sam Hocevar <sam+news@zoy.org> wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à
chaque
fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont
réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque
gcc
a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les
binaires
compilés pour être distribués utilisent du code machine qui marche à
peut
près partout. Si tu compiles un binaire spécifiquement pour ton système,
celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de
spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même
passé pas mal de temps à étudier l'assembleur produit par le compilateur
à différents niveaux d'optimisation et à benchmarker le résultat. Donc
ma conviction, c'est que pour la plupart des programmes, aller au delà
de -O est peu utile avec gcc-2.95. Par contre il est notoire que des
bugs existent avec par exemple -march=P4 jusqu'à des versions trés
récentes du compilo. Donc à toi l'honneur ...
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
maintenant, je reconnais que ça devient compliqué à lire.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante
et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait
aux instructions CPU utilisées par le binaire. Si on compile un soft pour
être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC,
maintenant si on compile ce même soft pour i686, il exploitera des
instructions CPU plus sophistiquées mais ne marchera que sur des machines
compatibles. A mon avis c'est bien là l'interêt de compiler soit-même les
sources. Et pour ne pas avoir à écrire [HS] dans l'objet, je dirais en
conclusion que c'est un avantage de Gentoo que de combiner simplicité de
prise en main et installation à partir des sources.
heu, désolé, je ne sais pas trop quoi enlever là dedans...
"Michel Talon" a écrit dans le message de news:buchik$2r4d$
Tiscali wrote:
"Michel Talon" a écrit dans le message de news:buc0b1$2k7t$
Sam Hocevar <sam+ wrote:
On Sat, 17 Jan 2004 17:47:55 +0100, Tiscali wrote:
Et concretement, ça apporte quoi de recompiler les sources à chaque
fois
excepté une perte de temps ?
La perte de temps est vite récompensée, les performances sont réellement à
couper le souffle.
La différence est en effet impressionnante, je confirme : lorsque gcc
a fini de tourner, la machine est 10 fois plus rapide.
Le scheduler de Linux est si mauvais que ça?
Ce n'est pas une question de scheduler, c'est simplement que les binaires
compilés pour être distribués utilisent du code machine qui marche à peut
près partout. Si tu compiles un binaire spécifiquement pour ton système, celui-ci bénéficie des particularités de ton CPU.
Ce n'est pas "d'optimisation" dont il s'agit, mais bien de spécialisation.
Je ne suis pas sur que tu sois absolument en phase avec Sam.
Sinon l'histoire des particularités du CPU, oui je connais, j'ai même passé pas mal de temps à étudier l'assembleur produit par le compilateur à différents niveaux d'optimisation et à benchmarker le résultat. Donc ma conviction, c'est que pour la plupart des programmes, aller au delà de -O est peu utile avec gcc-2.95. Par contre il est notoire que des bugs existent avec par exemple -march=P4 jusqu'à des versions trés récentes du compilo. Donc à toi l'honneur ...
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo, maintenant, je reconnais que ça devient compliqué à lire. Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles. A mon avis c'est bien là l'interêt de compiler soit-même les sources. Et pour ne pas avoir à écrire [HS] dans l'objet, je dirais en conclusion que c'est un avantage de Gentoo que de combiner simplicité de prise en main et installation à partir des sources.
++
Sam Hocevar
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien demander à GCC de générer du code optimisé pour i686 qui fonctionnera toujours très bien sur n'importe quel i386. C'est juste le pipeline et l'utilisation des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des mécanismes déjà tous faits pour les applications qui ont besoin d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler pour différents types de CPU. Et ça ne veut sûrement pas dire que cette compilation ne peut pas être faite par le distributeur. Par exemple quand on compile OpenSSL on peut lui demander de générer des binaires pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme lui-même ; et si MPlayer semble être l'exemple le plus couramment donné pour justifier cette manie de compiler soi-même ses programmes, c'est uniquement parce que ses développeurs n'étaient pas foutus de coder un code de détection de CPU correct.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps
à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante
et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait
aux instructions CPU utilisées par le binaire. Si on compile un soft pour
être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC,
maintenant si on compile ce même soft pour i686, il exploitera des
instructions CPU plus sophistiquées mais ne marchera que sur des machines
compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien
demander à GCC de générer du code optimisé pour i686 qui fonctionnera
toujours très bien sur n'importe quel i386. C'est juste le pipeline et
l'utilisation des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les
sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher
de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des
mécanismes déjà tous faits pour les applications qui ont besoin
d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou
ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il
n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler
pour différents types de CPU. Et ça ne veut sûrement pas dire que cette
compilation ne peut pas être faite par le distributeur. Par exemple
quand on compile OpenSSL on peut lui demander de générer des binaires
pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par
exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul
chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme
lui-même ; et si MPlayer semble être l'exemple le plus couramment donné
pour justifier cette manie de compiler soi-même ses programmes, c'est
uniquement parce que ses développeurs n'étaient pas foutus de coder un
code de détection de CPU correct.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien demander à GCC de générer du code optimisé pour i686 qui fonctionnera toujours très bien sur n'importe quel i386. C'est juste le pipeline et l'utilisation des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des mécanismes déjà tous faits pour les applications qui ont besoin d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler pour différents types de CPU. Et ça ne veut sûrement pas dire que cette compilation ne peut pas être faite par le distributeur. Par exemple quand on compile OpenSSL on peut lui demander de générer des binaires pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme lui-même ; et si MPlayer semble être l'exemple le plus couramment donné pour justifier cette manie de compiler soi-même ses programmes, c'est uniquement parce que ses développeurs n'étaient pas foutus de coder un code de détection de CPU correct.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
Sam Hocevar
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien demander à GCC de générer du code optimisé pour i686 qui fonctionnera toujours très bien sur n'importe quel i386. C'est juste l'utilisation du pipeline et des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des mécanismes déjà tous faits pour les applications qui ont besoin d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler pour différents types de CPU. Et ça ne veut sûrement pas dire que cette compilation ne peut pas être faite par le distributeur. Par exemple quand on compile OpenSSL on peut lui demander de générer des binaires pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme lui-même ; et si MPlayer semble être l'exemple le plus couramment donné pour justifier cette manie de compiler soi-même ses programmes, c'est uniquement parce que ses développeurs n'étaient pas foutus de coder un code de détection de CPU correct.
Sam. -- Sam Hocevar <http://sam.zoy.org/>
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps
à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante
et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait
aux instructions CPU utilisées par le binaire. Si on compile un soft pour
être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC,
maintenant si on compile ce même soft pour i686, il exploitera des
instructions CPU plus sophistiquées mais ne marchera que sur des machines
compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien
demander à GCC de générer du code optimisé pour i686 qui fonctionnera
toujours très bien sur n'importe quel i386. C'est juste l'utilisation du
pipeline et des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les
sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher
de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des
mécanismes déjà tous faits pour les applications qui ont besoin
d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou
ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il
n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler
pour différents types de CPU. Et ça ne veut sûrement pas dire que cette
compilation ne peut pas être faite par le distributeur. Par exemple
quand on compile OpenSSL on peut lui demander de générer des binaires
pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par
exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul
chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme
lui-même ; et si MPlayer semble être l'exemple le plus couramment donné
pour justifier cette manie de compiler soi-même ses programmes, c'est
uniquement parce que ses développeurs n'étaient pas foutus de coder un
code de détection de CPU correct.
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
On Sun, 18 Jan 2004 02:15:37 +0100, Tiscali wrote:
Apparement Sam et moi sommes d'accord au sujet des performances de Gentoo,
Non, au contraire. Si j'avais une gentoo, mon CPU passerait son temps à compiler des packages, ça rendriat ma machine inutilisable.
Je suis assez d'accord en ce qui concerne l'option -O. Elle est suffisante et sans risque. Mais ce n'est pas à ça que je pensais, je pensais en fait aux instructions CPU utilisées par le binaire. Si on compile un soft pour être compatible i386, on peut être sûr qu'il fonctionnera sur tous les PC, maintenant si on compile ce même soft pour i686, il exploitera des instructions CPU plus sophistiquées mais ne marchera que sur des machines compatibles.
Ça dépend de ce que tu appelles « pour i686 ». Tu peux très bien demander à GCC de générer du code optimisé pour i686 qui fonctionnera toujours très bien sur n'importe quel i386. C'est juste l'utilisation du pipeline et des registres qui sera un peu changée.
A mon avis c'est bien là l'interêt de compiler soit-même les sources.
Croyance populaire. Compiler soi-même les sources ne sert qu'à gâcher de l'électricité, détruire les forêts et tuer des bébés ours. Il y a des mécanismes déjà tous faits pour les applications qui ont besoin d'exploiter au maximum les capacités du CPU, que ce soit sur x86 ou ailleurs.
Il est bien connu qu'on passe 95% de son temps dans 5% du code, il n'y a donc que ces 5% qu'il faut factoriser et éventuellement compiler pour différents types de CPU. Et ça ne veut sûrement pas dire que cette compilation ne peut pas être faite par le distributeur. Par exemple quand on compile OpenSSL on peut lui demander de générer des binaires pour chaque architecture, qui iront se mettre dans /usr/lib/i686 par exemple. Et -- oh, magie -- le dynamic linker de Linux ira tout seul chercher la bonne version.
Mais on peut très bien mettre cette fonctionnalité dans le programme lui-même ; et si MPlayer semble être l'exemple le plus couramment donné pour justifier cette manie de compiler soi-même ses programmes, c'est uniquement parce que ses développeurs n'étaient pas foutus de coder un code de détection de CPU correct.
