[FreeBSD 4.10] reboot tout seul

pornin

19/11/2004 à 13:01

According to Michel Talon :

C'est clair que cette optimisation énormément améliorée prend du
temps de compilation. [...] La complexité dont tu parles, c'est aussi
en grande partie le prix à payer pour avoir un compilateur multi
architectures, et qui peut faire la compilation croisée de toutes ces
architectures.

Ça, c'est la théorie officielle ; mais, après avoir longuement réfléchi
sur le sujet, programmé pendant des heures et m'être abondamment
documenté, je suis arrivé à la conclusion que non, décidément, je ne
peux pas y croire.

Il est vrai que faire du code plus optimisé prend du temps. Mais
ce temps ne devrait être pris que lorsque, justement, on active
l'optimiseur. gcc 3.x prend vraiment trois de temps que gcc 2.95 _même
en désactivant explicitement toutes les optimisations_.

Quant au support de beaucoup d'architectures, il peut prendre du temps
de développement du compilateur, mais ne devrait pas en prendre à
l'exécution du compilateur lui-même. Un point par exemple, c'est que
lors d'une cross-compilation, on doit évaluer les expressions constantes
selon les règles de l'architecture-cible (donc en 64 bits si on fait
du code Alpha même si on compile depuis une machine 32 bits). Quand
on programme ça correctement, on fait ça avec un support générique
pour l'évaluation des opérateurs, support qui prend la forme de macros
qui font "ce qu'il faut". Quand on a un compilateur natif, les macros
deviennent les simples opérateurs du C et l'évaluation est aussi rapide
que possible. Un tel jeu de macros est un peu technique à mettre au
point mais c'est possible (je le sais parce que je l'ai fait -- et c'est
disponible avec une licence libre BSD-like dans le préprocesseur C que
j'ai écrit, cf http://pornin.nerim.net/ucpp/ ).

D'ailleurs, il y a quelques années, lcc compilait du C ANSI trois fois
plus vite que le gcc 2.7.2 (qui lui-même était plus rapide que gcc-2.8,
qui était plus rapide que gcc-2.95 -- j'ai personnellement mesuré tout
ça à l'époque), en produisant un code plus efficace que celui produit
par gcc sans optimisation, et ce malgré l'utilisation par lcc d'un
préprocesseur naze (sans optimisation pour les inclusions multiples du
même fichier) et bien que lcc marchait en tant que cross-compilateur
pour une floppée d'architectures (au moins x86, Mips, Sparc et Alpha)
avec toutes les combinaisons acceptées.

Et puis il me semble que gcc-3.4 support _moins_ d'architectures que
gcc-2.95. Alors bof en fait.

En bref, s'il est vrai que gcc 3.4.2 produit du code plus optimisé que
le gcc 2.95 (ce qui n'a d'importance que dans environ 1% des cas au
mieux, mais bon, dans ces cas-là c'est bien cool), qu'il tourne sur
beaucoup d'architectures différentes (ce qui est bien cool aussi), et
qu'il supporte mieux le C99 et le C++ récent, ça n'explique en rien la
lenteur de gcc-3.4.2 par rapport à gcc-2.95. Ça peut la "compenser" si
on en est à choisir entre les deux (c'est ce qui fait que FreeBSD a
choisi gcc-3.4.2) mais ça n'est pas la cause. Cette cause est ailleurs,
et, de mon point de vue, c'est un symptôme assez fiable du fait que
le code source de gcc a trop grossi pendant trop longtemps, que sa
structure interne est pourrie et qu'il serait grand temps de faire ce
qu'on fait habituellement en informatique, à savoir un bon rm -rf et
réécrire le tout à partir de zéro.

Sauf que c'est un boulot monstre et que l'interopérabilité avec ce que
produit le compilateur actuel est quasiment impossible, puisque rien
n'est décemment documenté dans tout le bouzin.

Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

En l'occurrence, on ne compare pas gcc avec icc, mais plutôt gcc avec ce
qu'il pourrait être _et qu'il a été dans le passé d'ailleurs_. Il y a eu
des améliorations depuis (par exemple, il est plus difficile de faire
partir gcc-3.4.2 que gcc-2.7.2.3 en vrille sur une "internal compiler
error") mais avec un prix à payer élevé, prix qui par ailleurs n'est
pas logiquement corrélé avec les améliorations (cf supra). C'est cette
absence de lien logique qui est le fond de ma critique.

--Thomas Pornin

According to Michel Talon <talon@lpthe.jussieu.fr>:

C'est clair que cette optimisation énormément améliorée prend du
temps de compilation. [...] La complexité dont tu parles, c'est aussi
en grande partie le prix à payer pour avoir un compilateur multi
architectures, et qui peut faire la compilation croisée de toutes ces
architectures.

Ça, c'est la théorie officielle ; mais, après avoir longuement réfléchi
sur le sujet, programmé pendant des heures et m'être abondamment
documenté, je suis arrivé à la conclusion que non, décidément, je ne
peux pas y croire.

Il est vrai que faire du code plus optimisé prend du temps. Mais
ce temps ne devrait être pris que lorsque, justement, on active
l'optimiseur. gcc 3.x prend vraiment trois de temps que gcc 2.95 _même
en désactivant explicitement toutes les optimisations_.

Quant au support de beaucoup d'architectures, il peut prendre du temps
de développement du compilateur, mais ne devrait pas en prendre à
l'exécution du compilateur lui-même. Un point par exemple, c'est que
lors d'une cross-compilation, on doit évaluer les expressions constantes
selon les règles de l'architecture-cible (donc en 64 bits si on fait
du code Alpha même si on compile depuis une machine 32 bits). Quand
on programme ça correctement, on fait ça avec un support générique
pour l'évaluation des opérateurs, support qui prend la forme de macros
qui font "ce qu'il faut". Quand on a un compilateur natif, les macros
deviennent les simples opérateurs du C et l'évaluation est aussi rapide
que possible. Un tel jeu de macros est un peu technique à mettre au
point mais c'est possible (je le sais parce que je l'ai fait -- et c'est
disponible avec une licence libre BSD-like dans le préprocesseur C que
j'ai écrit, cf http://pornin.nerim.net/ucpp/ ).

D'ailleurs, il y a quelques années, lcc compilait du C ANSI trois fois
plus vite que le gcc 2.7.2 (qui lui-même était plus rapide que gcc-2.8,
qui était plus rapide que gcc-2.95 -- j'ai personnellement mesuré tout
ça à l'époque), en produisant un code plus efficace que celui produit
par gcc sans optimisation, et ce malgré l'utilisation par lcc d'un
préprocesseur naze (sans optimisation pour les inclusions multiples du
même fichier) et bien que lcc marchait en tant que cross-compilateur
pour une floppée d'architectures (au moins x86, Mips, Sparc et Alpha)
avec toutes les combinaisons acceptées.

Et puis il me semble que gcc-3.4 support _moins_ d'architectures que
gcc-2.95. Alors bof en fait.

En bref, s'il est vrai que gcc 3.4.2 produit du code plus optimisé que
le gcc 2.95 (ce qui n'a d'importance que dans environ 1% des cas au
mieux, mais bon, dans ces cas-là c'est bien cool), qu'il tourne sur
beaucoup d'architectures différentes (ce qui est bien cool aussi), et
qu'il supporte mieux le C99 et le C++ récent, ça n'explique en rien la
lenteur de gcc-3.4.2 par rapport à gcc-2.95. Ça peut la "compenser" si
on en est à choisir entre les deux (c'est ce qui fait que FreeBSD a
choisi gcc-3.4.2) mais ça n'est pas la cause. Cette cause est ailleurs,
et, de mon point de vue, c'est un symptôme assez fiable du fait que
le code source de gcc a trop grossi pendant trop longtemps, que sa
structure interne est pourrie et qu'il serait grand temps de faire ce
qu'on fait habituellement en informatique, à savoir un bon rm -rf et
réécrire le tout à partir de zéro.

Sauf que c'est un boulot monstre et que l'interopérabilité avec ce que
produit le compilateur actuel est quasiment impossible, puisque rien
n'est décemment documenté dans tout le bouzin.

Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

En l'occurrence, on ne compare pas gcc avec icc, mais plutôt gcc avec ce
qu'il pourrait être _et qu'il a été dans le passé d'ailleurs_. Il y a eu
des améliorations depuis (par exemple, il est plus difficile de faire
partir gcc-3.4.2 que gcc-2.7.2.3 en vrille sur une "internal compiler
error") mais avec un prix à payer élevé, prix qui par ailleurs n'est
pas logiquement corrélé avec les améliorations (cf supra). C'est cette
absence de lien logique qui est le fond de ma critique.

--Thomas Pornin

Vous avez filtré cet utilisateur ! Consultez son message

According to Michel Talon :

C'est clair que cette optimisation énormément améliorée prend du
temps de compilation. [...] La complexité dont tu parles, c'est aussi
en grande partie le prix à payer pour avoir un compilateur multi
architectures, et qui peut faire la compilation croisée de toutes ces
architectures.

Ça, c'est la théorie officielle ; mais, après avoir longuement réfléchi
sur le sujet, programmé pendant des heures et m'être abondamment
documenté, je suis arrivé à la conclusion que non, décidément, je ne
peux pas y croire.

Il est vrai que faire du code plus optimisé prend du temps. Mais
ce temps ne devrait être pris que lorsque, justement, on active
l'optimiseur. gcc 3.x prend vraiment trois de temps que gcc 2.95 _même
en désactivant explicitement toutes les optimisations_.

Quant au support de beaucoup d'architectures, il peut prendre du temps
de développement du compilateur, mais ne devrait pas en prendre à
l'exécution du compilateur lui-même. Un point par exemple, c'est que
lors d'une cross-compilation, on doit évaluer les expressions constantes
selon les règles de l'architecture-cible (donc en 64 bits si on fait
du code Alpha même si on compile depuis une machine 32 bits). Quand
on programme ça correctement, on fait ça avec un support générique
pour l'évaluation des opérateurs, support qui prend la forme de macros
qui font "ce qu'il faut". Quand on a un compilateur natif, les macros
deviennent les simples opérateurs du C et l'évaluation est aussi rapide
que possible. Un tel jeu de macros est un peu technique à mettre au
point mais c'est possible (je le sais parce que je l'ai fait -- et c'est
disponible avec une licence libre BSD-like dans le préprocesseur C que
j'ai écrit, cf http://pornin.nerim.net/ucpp/ ).

D'ailleurs, il y a quelques années, lcc compilait du C ANSI trois fois
plus vite que le gcc 2.7.2 (qui lui-même était plus rapide que gcc-2.8,
qui était plus rapide que gcc-2.95 -- j'ai personnellement mesuré tout
ça à l'époque), en produisant un code plus efficace que celui produit
par gcc sans optimisation, et ce malgré l'utilisation par lcc d'un
préprocesseur naze (sans optimisation pour les inclusions multiples du
même fichier) et bien que lcc marchait en tant que cross-compilateur
pour une floppée d'architectures (au moins x86, Mips, Sparc et Alpha)
avec toutes les combinaisons acceptées.

Et puis il me semble que gcc-3.4 support _moins_ d'architectures que
gcc-2.95. Alors bof en fait.

En bref, s'il est vrai que gcc 3.4.2 produit du code plus optimisé que
le gcc 2.95 (ce qui n'a d'importance que dans environ 1% des cas au
mieux, mais bon, dans ces cas-là c'est bien cool), qu'il tourne sur
beaucoup d'architectures différentes (ce qui est bien cool aussi), et
qu'il supporte mieux le C99 et le C++ récent, ça n'explique en rien la
lenteur de gcc-3.4.2 par rapport à gcc-2.95. Ça peut la "compenser" si
on en est à choisir entre les deux (c'est ce qui fait que FreeBSD a
choisi gcc-3.4.2) mais ça n'est pas la cause. Cette cause est ailleurs,
et, de mon point de vue, c'est un symptôme assez fiable du fait que
le code source de gcc a trop grossi pendant trop longtemps, que sa
structure interne est pourrie et qu'il serait grand temps de faire ce
qu'on fait habituellement en informatique, à savoir un bon rm -rf et
réécrire le tout à partir de zéro.

Sauf que c'est un boulot monstre et que l'interopérabilité avec ce que
produit le compilateur actuel est quasiment impossible, puisque rien
n'est décemment documenté dans tout le bouzin.

Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

En l'occurrence, on ne compare pas gcc avec icc, mais plutôt gcc avec ce
qu'il pourrait être _et qu'il a été dans le passé d'ailleurs_. Il y a eu
des améliorations depuis (par exemple, il est plus difficile de faire
partir gcc-3.4.2 que gcc-2.7.2.3 en vrille sur une "internal compiler
error") mais avec un prix à payer élevé, prix qui par ailleurs n'est
pas logiquement corrélé avec les améliorations (cf supra). C'est cette
absence de lien logique qui est le fond de ma critique.

--Thomas Pornin

Marwan Burelle

19/11/2004 à 14:35

On Fri, 19 Nov 2004 09:45:02 +0000 (UTC)
(Michel Talon) wrote:

Outre le problème du C++, je vois surtout l'optimiseur qui a fait
des progrés considérables avec gcc3. Sur des programmes de calcul,
j'ai vu le compilateur Intel produire des exécutables jusqu'à deux
fois plus rapides que gcc2. Avec un gcc3 récent l'écart s'est
considérablement réduit. C'est clair que cette optimisation énormément
améliorée prend du temps de compilation. Aprés tout la compilation on
ne la fait qu'une seule fois, et avec des machines comme l'Athlon64
elle finit par passer rapidement. A la rigueur il y a des trucs
pour rendre la compilation plus rapide pour les gens qui en font
beaucoup, genre distcc. Par contre optimiser au maximum bénéficie
tout le temps, à tout le monde. La complexité dont tu parles, c'est
aussi en grande partie le prix à payer pour avoir un compilateur
multi architectures, et qui peut faire la compilation croisée de
toutes ces architectures. Et ça c'est un autre avantage décisif de
gcc. Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

Ah oui, mais non (© et tout ce qui va bien ;)

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
( | )

On Fri, 19 Nov 2004 09:45:02 +0000 (UTC)
talon@lpthe.jussieu.fr (Michel Talon) wrote:

Outre le problème du C++, je vois surtout l'optimiseur qui a fait
des progrés considérables avec gcc3. Sur des programmes de calcul,
j'ai vu le compilateur Intel produire des exécutables jusqu'à deux
fois plus rapides que gcc2. Avec un gcc3 récent l'écart s'est
considérablement réduit. C'est clair que cette optimisation énormément
améliorée prend du temps de compilation. Aprés tout la compilation on
ne la fait qu'une seule fois, et avec des machines comme l'Athlon64
elle finit par passer rapidement. A la rigueur il y a des trucs
pour rendre la compilation plus rapide pour les gens qui en font
beaucoup, genre distcc. Par contre optimiser au maximum bénéficie
tout le temps, à tout le monde. La complexité dont tu parles, c'est
aussi en grande partie le prix à payer pour avoir un compilateur
multi architectures, et qui peut faire la compilation croisée de
toutes ces architectures. Et ça c'est un autre avantage décisif de
gcc. Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

Ah oui, mais non (© et tout ce qui va bien ;)

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)

Vous avez filtré cet utilisateur ! Consultez son message

On Fri, 19 Nov 2004 09:45:02 +0000 (UTC)
(Michel Talon) wrote:

Outre le problème du C++, je vois surtout l'optimiseur qui a fait
des progrés considérables avec gcc3. Sur des programmes de calcul,
j'ai vu le compilateur Intel produire des exécutables jusqu'à deux
fois plus rapides que gcc2. Avec un gcc3 récent l'écart s'est
considérablement réduit. C'est clair que cette optimisation énormément
améliorée prend du temps de compilation. Aprés tout la compilation on
ne la fait qu'une seule fois, et avec des machines comme l'Athlon64
elle finit par passer rapidement. A la rigueur il y a des trucs
pour rendre la compilation plus rapide pour les gens qui en font
beaucoup, genre distcc. Par contre optimiser au maximum bénéficie
tout le temps, à tout le monde. La complexité dont tu parles, c'est
aussi en grande partie le prix à payer pour avoir un compilateur
multi architectures, et qui peut faire la compilation croisée de
toutes ces architectures. Et ça c'est un autre avantage décisif de
gcc. Icc peut trés bien compiler plus rapidement et produire des
exécutables plus rapides, il ne doit se soucier que de gérer une seule
architecture.

Ah oui, mais non (© et tout ce qui va bien ;)

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
( | )

Paul Gaborit

19/11/2004 à 15:01

À (at) Fri, 19 Nov 2004 14:35:53 +0100,
Marwan Burelle écrivait (wrote):

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

Il faut peut-être nuancé : les "langages" intermédiaires sont documentés. Il
suffit de lire gccint (gcc internal) pour s'en convaincre (même si tout n'est
pas à jour).

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

C'est la démarche adoptée dans gcc (nouvelle mouture: GNU Compiler
Collection).

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Je ne suis pas si pessimiste. Je pense qu'en fait l'ajout de C++,
d'Objective-C, de Fortran, d'ADA et même de Java a été le déclencheur pour
revoir l'architecture globale de gcc. Mais les forces ne sont pas suffisantes
pour mener de front :
- le nettoyage des erreurs du passé (souvenez-vous de 2.96 !)
- l'amélioration de l'architecture globale et du langage intermédiaire
- la prise en compte des spécificités des processeurs modernes
- l'amélioration de l'optimiseur
- l'évolution de C++ (la notion d'ABI standard)
- la prise en compte des nouvelles normes (C99, F90, etc.)

En fait, une fois les deux premiers points correctement réalisés (encore que
le troisième et le quatrième peuvent impacter beaucoup le second), tout le
reste est assez indépendant et pourra évoluer tranquillement. Mais le point 5
a monopolisé (et monopolise encore) beaucoup de monde. Je pense que ça va se
calmer (car le C++ semble se staibiliser)pour ramener un peu plus de sérénité
dans le projet et permettre de retrouver la qualité que nous attendons tous.

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

N'étant pas fondamentaliste, je préfère me taire ;-)

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>

À (at) Fri, 19 Nov 2004 14:35:53 +0100,
Marwan Burelle <burelle@lri.fr> écrivait (wrote):

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

Il faut peut-être nuancé : les "langages" intermédiaires sont documentés. Il
suffit de lire gccint (gcc internal) pour s'en convaincre (même si tout n'est
pas à jour).

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

C'est la démarche adoptée dans gcc (nouvelle mouture: GNU Compiler
Collection).

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Je ne suis pas si pessimiste. Je pense qu'en fait l'ajout de C++,
d'Objective-C, de Fortran, d'ADA et même de Java a été le déclencheur pour
revoir l'architecture globale de gcc. Mais les forces ne sont pas suffisantes
pour mener de front :
- le nettoyage des erreurs du passé (souvenez-vous de 2.96 !)
- l'amélioration de l'architecture globale et du langage intermédiaire
- la prise en compte des spécificités des processeurs modernes
- l'amélioration de l'optimiseur
- l'évolution de C++ (la notion d'ABI standard)
- la prise en compte des nouvelles normes (C99, F90, etc.)

En fait, une fois les deux premiers points correctement réalisés (encore que
le troisième et le quatrième peuvent impacter beaucoup le second), tout le
reste est assez indépendant et pourra évoluer tranquillement. Mais le point 5
a monopolisé (et monopolise encore) beaucoup de monde. Je pense que ça va se
calmer (car le C++ semble se staibiliser)pour ramener un peu plus de sérénité
dans le projet et permettre de retrouver la qualité que nous attendons tous.

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

N'étant pas fondamentaliste, je préfère me taire ;-)

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>

Vous avez filtré cet utilisateur ! Consultez son message

À (at) Fri, 19 Nov 2004 14:35:53 +0100,
Marwan Burelle écrivait (wrote):

gcc souffre de beaucoup de problèmes internes, je ne connais pas de dev
de gcc, mais ce que j'en vois de l'extérieur, pour moi, c'est un foutoir
qui augmente de version en version, parce que personne n'a le courage de
faire le ménage. Un bon nombre de choses ne sont pas documentées
(notament le(s) langage(s) intermédiaire(s)) donc ni réutilisables, ni
"modulables".

Il faut peut-être nuancé : les "langages" intermédiaires sont documentés. Il
suffit de lire gccint (gcc internal) pour s'en convaincre (même si tout n'est
pas à jour).

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

C'est la démarche adoptée dans gcc (nouvelle mouture: GNU Compiler
Collection).

Ça marche pour d'autre langage, ça devrait marcher pour C,
malheureusement (et historiquement ?), gcc n'a pas été pensé comme ça et
il n'y a pas de dynamique suffisante pour mener un tel projet (il suffit
de regarder l'activité de tendra ... enfin tendra et ten15 maintenant
... )

Je ne suis pas si pessimiste. Je pense qu'en fait l'ajout de C++,
d'Objective-C, de Fortran, d'ADA et même de Java a été le déclencheur pour
revoir l'architecture globale de gcc. Mais les forces ne sont pas suffisantes
pour mener de front :
- le nettoyage des erreurs du passé (souvenez-vous de 2.96 !)
- l'amélioration de l'architecture globale et du langage intermédiaire
- la prise en compte des spécificités des processeurs modernes
- l'amélioration de l'optimiseur
- l'évolution de C++ (la notion d'ABI standard)
- la prise en compte des nouvelles normes (C99, F90, etc.)

En fait, une fois les deux premiers points correctement réalisés (encore que
le troisième et le quatrième peuvent impacter beaucoup le second), tout le
reste est assez indépendant et pourra évoluer tranquillement. Mais le point 5
a monopolisé (et monopolise encore) beaucoup de monde. Je pense que ça va se
calmer (car le C++ semble se staibiliser)pour ramener un peu plus de sérénité
dans le projet et permettre de retrouver la qualité que nous attendons tous.

Au risque de m'attirer les foudres des fondamentalistes, je rajouterais
que gcc est le le meilleur exemple du frein que peut représenter
le prosélitisme mélangé au logiciel libre (cf la remarque de Thomas.)

N'étant pas fondamentaliste, je préfère me taire ;-)

--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>

pornin

19/11/2004 à 15:03

According to Marwan Burelle :

Un bon nombre de choses ne sont pas documentées (notament le(s)
langage(s) intermédiaire(s))

Historiquement, c'est une feature : le langage intermédiaire est obscur
et non documenté parce que Stallman avait peur qu'une entreprise
fabrique (méchamment) un compilateur close-source qui réutiliserait le
back-end (ou le front-end, mais pas les deux) de gcc, en utilisant le
format du code intermédiaire (comme ce serait un format de fichier et
pas de l'édition de liens, la GPL ne pourrait pas viraliser le code
propriétaire dans cette situation).

C'est un assez joli exemple de choix technique discutable justifié par
une prise de position idéologique, et qui gonfle le monde des années
après.

--Thomas Pornin

Marwan Burelle

19/11/2004 à 15:33

On Fri, 19 Nov 2004 14:03:15 +0000 (UTC)
(Thomas Pornin) wrote:

Historiquement, c'est une feature : le langage intermédiaire est
obscur et non documenté parce que Stallman avait peur qu'une
entreprise fabrique (méchamment) un compilateur close-source qui
réutiliserait le back-end (ou le front-end, mais pas les deux) de gcc,
en utilisant le format du code intermédiaire (comme ce serait un
format de fichier et pas de l'édition de liens, la GPL ne pourrait pas
viraliser le code propriétaire dans cette situation).

Intéressant comme concept ...

Ce qui est amusant, c'est que ça empèche aussi d'utiliser des parties de
gcc dans un projet "libre". Xavier Leroy (l'un des pères de caml) m'a
(enfin, c'était en école d'été ... ) expliqué qu'ils avaient fait leur
propre backend et n'avais pas utilisé celui de gcc justement à cause de
cette histoire de langage non documenté (pour info, il a pris un truc
standard, le langage défini dans le dragon à peu de chose près, ce
n'était pas pour des raisons techniques ... )

C'est un assez joli exemple de choix technique discutable justifié par
une prise de position idéologique, et qui gonfle le monde des années
après.

Après certains prétendent que la BSDl (est son côté non-virale ;) est
mauvaise pour le logiciel libre ...

--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
( | )

talon

19/11/2004 à 15:48

Marwan Burelle wrote:

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

C'est exactement à ça que je pensais quand je disais que la complexité
était probablement causée par le coté multiplateforme. C'est
évident que le langage intermédiaire de gcc est et a toujours été
abominablement compliqué, imbaisable, etc. ce qui constitue un frein
considérable au fait que les gens regardent ce qui ne va pas, soit
du coté de l'optimiseur soit de la lenteur de compilation.

--

Michel TALON

Eric Masson

19/11/2004 à 15:56

"Marwan" == Marwan Burelle writes:

Marwan> Ça marche pour d'autre langage, ça devrait marcher pour C,
Marwan> malheureusement (et historiquement ?), gcc n'a pas été pensé
Marwan> comme ça et il n'y a pas de dynamique suffisante pour mener un
Marwan> tel projet (il suffit de regarder l'activité de tendra ...
Marwan> enfin tendra et ten15 maintenant ... )

Faut croire que les bonnes idées ne sont pas forcément celles qui sont
retenues.

Dommage qu'une partie de l'énergie déployée dans l'évolution de gcc ne
soit pas utilisée sur des projets concurrents qui améneraient une réelle
émulation au niveau des compilateurs C.

Marwan> Au risque de m'attirer les foudres des fondamentalistes, je
Marwan> rajouterais que gcc est le le meilleur exemple du frein que
Marwan> peut représenter le prosélitisme mélangé au logiciel libre (cf
Marwan> la remarque de Thomas.)

Pas mieux, c'est probablement pour cela qu'ANDF et les compilos qui
l'exploitent ne décolleront jamais vraiment, dommage.

Éric Masson

--
in fr.bio.canauxioniques:
LC> y a quelqu'un ?
LC> encore un site voué a la destruction!
-+- in : GNU - Le silence des espaces infinis m'effraie -+-

Miod Vallat

19/11/2004 à 16:02

La problématique de maintenir un compilateur multiplateforme, même pour
le langage C, conciste à choisir le bon backend (en gros un langage
intermédiaire adapté) et à rendre indépendante l'évolution de la partie
concernant le passage langage source vers langage intermédiaire et
production de code spécifique.

Ça marche pour d'autre langage, ça devrait marcher pour C,

Ça marche pour tout langage compilable, en fait.

Et les développeurs de gcc s'en rendent compte, puisque dans gcc 4, le
travail sur la représentation SSA porte ses fruits et devrait, passé
l'étape de nettoyage et de retrait des branches mortes dans le code,
redonner des temps de compilation plus proches de ceux des versions 2.x.

Miod Vallat

19/11/2004 à 16:07

Historiquement, c'est une feature : le langage intermédiaire est obscur
et non documenté parce que Stallman avait peur qu'une entreprise
fabrique (méchamment) un compilateur close-source qui réutiliserait le
back-end (ou le front-end, mais pas les deux) de gcc, en utilisant le
format du code intermédiaire (comme ce serait un format de fichier et
pas de l'édition de liens, la GPL ne pourrait pas viraliser le code
propriétaire dans cette situation).

Oui. C'est d'ailleurs pour cela que gcc ne peut pas donner une sortie en
rtl, qui serait réutilisable.

On peut cependant reconstruire le RTL à la main à partir de 20 fichiers
de déboguage obtenus avec gcc -d. Merci bien.

C'est un assez joli exemple de choix technique discutable justifié par
une prise de position idéologique, et qui gonfle le monde des années
après.

Le deuxième problème, qui y est fortement lié, c'est que toutes les
parties basses de gcc qui ne traitent que de la manipulation du rtl
(donc essentiellement un interpréteur lisp pour traiter les fichiers
.md et écrire du code assembleur en sortie) sont très mal documentées (je
parle ici du code, pas seulement de gccint.texi), et écrites de façon
suffisamment touffue et hermétique pour que personne, parmi les
développeurs actuels de gcc, n'ose y toucher, de peur de provoquer des
dommages collatéraux sans s'en rendre compte...

Eric Masson

19/11/2004 à 16:32

"Miod" == Miod Vallat writes:

'Lut,

Miod> Le deuxième problème, qui y est fortement lié, c'est que toutes
Miod> les parties basses de gcc qui ne traitent que de la manipulation
Miod> du rtl (donc essentiellement un interpréteur lisp pour traiter
Miod> les fichiers .md et écrire du code assembleur en sortie)

Il y tient à sa marotte le père stallman...

Éric Masson

--
Subject: hors-sujet
Etudiant1 de Formatique> c'est quoi ce message!!c'est
Etudiant1 de Formatique>i ncompréhensible............plus clair!!!!!!!
-+- in: GNU - Le méta-neuneu fou a (est) encore frappé -+-

[FreeBSD 4.10] reboot tout seul

10 réponses

Veuillez sélectionner un problème