Écrit à l'origine par Richard Stallman, le logiciel GCC (GNU Compiler Collection) est le compilateur de référence du monde du logiciel libre. Il accepte des codes source écrits en C, C++, Objective-C, Fortran, Java et Ada et fonctionne sur une multitude d'architectures.
La sortie de GCC 4.4 a été grandement retardée par des questions d'ordre juridiques. En effet la FSF a dû se prononcer sur la nouvelle "Runtime Library Exception" qui autorise le passage des diverses bibliothèques sous licence GPLv3 ainsi que l'arrivée prochaine des greffons dans l'architecture de GCC. La FSF étant connue pour sa hâte toute relative sur les questions juridiques il a fallu patienter ce qui a provoqué un certain mécontentement chez plusieurs développeurs. Néanmoins le comité directeur de GCC a préféré jouer la prudence (better safe than fast) et attendre d'avoir l'aval des juristes de la FSF avant d'autoriser la sortie tant attendue.
Dans la suite de la dépêche, vous pourrez découvrir les nouveautés et les optimisations mises en œuvre dans cette version 4.4 de GCC.
NdM : pour l'anecdote, cette dépêche a été initialement soumise le 18 décembre 2008, a attendu la sortie officielle de GCC 4.4, et à ce titre remporte le titre de dépêche restée le plus longtemps en modération (le record précédent étant de 70 jours). Nouvel allocateur de registres
Un nouvel allocateur de registres sophistiqué est incorporé dans la version 4.4 de GCC.
L'allocation de registres est une tâche très importante qu'effectue le compilateur. En effet il doit arriver à assigner aux variables du programme un « endroit » où elles seront stockées pour exécution. Ce sont les registres du processeur qui vont accueillir ces variables mais, petit problème, ces registres sont fort peu nombreux alors que les variables d'un programme sont souvent très nombreuses. Typiquement un processeur x86 possède seulement 8 registres, la variante x86-64 en possède 16 et un processeur PowerPC jouit de 32 registres.
Pour trouver la solution optimale afin de « masquer » ce faible nombre de registres le compilateur doit s'appuyer sur des algorithmes très complexes souvent liés à la théorie des graphes et notamment au coloriage de graphes.
Le compilateur GCC 4.4 propose l'allocateur IRA (Integrated Register Allocator) qui est le résultat de plusieurs d'années d'expérimentation avec la branche YARA (Yet Another Register Allocator) par le développeur Vladimir Makarov qui travaille pour Red Hat.
Cet allocateur intégré ultra-moderne permet de choisir entre plusieurs algorithmes et plusieurs paramètres (avec les options -fira-algorithm et -fira-region).
En ce qui concerne les choix de -fira-algorithm on peut opter pour "CB" qui est un allocateur basé sur l'algorithme de Chaitin-Briggs ou pour "Priority" qui utilise l'algorithme de Chow. "CB" est utilisé par défaut.
Pour la région il est possible de choisir entre "All", "One" et "Mixed". L'option "All" fonctionne bien avec les processeurs n'ayant que peu de registres alors que l'option "One" considère toute la fonction comme une seule région et est bien adaptée aux architectures dotées d'un grand nombre de registres. Le troisième choix est un mélange des deux précédents (ce qui explique son nom "Mixed") et c'est celui qui est utilisé par défaut puisqu'il propose les meilleures performances dans la plupart des cas et sur la plupart des architectures de processeurs.
Pour avoir une idée du gain en performances il est possible de consulter cet article au format pdf de Vladimir Makarov. Les considérations techniques sont extrêmement absconses mais le paragraphe 3 propose un graphe comparant les scores des allocateurs de "Chaitin-Briggs" (sans région), de "Callahan-Koblenz" et du nouvel allocateur de GCC 4.4 (nommé "Regional" dans l'article). Que ce soit en terme de rapidité ou de taille de code la victoire du nouvel allocateur IRA est sans appel.
Branche Graphite
Après IRA la seconde grande nouveauté de GCC 4.4 est l'intégration de la branche "Graphite" qui permet d'optimiser l'exécution des boucles de code.
Cette étape d'optimisation des boucles effectuée par le compilateur est une tâche importante puisque le bénéfice en terme de temps d'exécution est souvent très visible. Du fait de ces optimisations savantes effectuées par le compilateur la pression sur la mémoire cache peut être réduite et le travail peut être mieux distribué entre les processeurs.
L'orientation choisie par la branche Graphite relève de la méthode des polytopes qui est une approche très mathématisée de la théorie des compilateurs. Pour résumer ce soubassement théorique on peut dire que cela consiste à transformer les boucles de code en figures géométriques complexes afin de trouver des optimisations puis à transformer à nouveau les figures en code optimisé.
Plus techniquement : un polygone est une figure fermée sur le plan et qui est délimitée par des segments de droite, un polyèdre c'est la même chose en trois dimensions et un polytope c'est la même chose en dimension n.
La méthode des polytopes consiste à transformer les boucles des programmes en polytopes (les itérations d'une boucle de code sont représentées comme des points à la "surface" de la figure multidimensionnelle), appliquer diverses opérations mathématiques sur ces polytopes (des transfomations affines) puis à transformer à nouveau les polytopes en boucles sémantiquement équivalentes aux boucles initiales mais super-optimisées.
On voit bien que le sujet est complexe et on ne s'étonnera donc pas que cette méthode ait surtout été développée par des universitaires dans diverses bibliothèques de programmes. Ainsi la bibliothèque Graphite qui est intégré dans GCC 4.4 est décrite en détail dans ce fichier pdf par des chercheurs de l'École des mines de Paris, de L'INRIA et de l'université d'Orsay. Selon ce document, GCC 4.4 est le tout premier compilateur de production au monde qui intègre une optimisation par la méthode des polytopes.
Les passes d'optimisation qui sont prises en charge par Graphite se déroulent quand le code source a été transformé dans la représentation générique GIMPLE. On fait ainsi une transformation GIMPLE -> Graphite -> GIMPLE pour optimiser toutes les boucles avec la méthode des polytopes ce qui explique le nom choisi pour Graphite (GIMPLE Represented as Polyhedra with Interchangeable Envelopes).
Actuellement ces passes d'optimisations sont mises en œuvre à l'aide des commandes "-floop-block", "-floop-interchange", "-floop-stripmine" et "-fgraphite" mais la discussion a été vive afin de trouver les conventions de nommages les plus explicites.
Le résultat brut est très impressionnant puisque selon Sebastian Pop (premier auteur de l'article sur Graphite et auteur de plusieurs autres présentations) le gain apporté par cette optimisation est inégalé (test effectué sur le benchmark spécifique swim du comparatif standard SPEC2000) : "Comparé aux performances du meilleur compilateur disponible, PathScale EKOPath (V2.1) avec l'option d'optimisation peak-SPEC, notre outil permet d'obtenir un gain de vitesse de 32% sur Athlon XP et de 38% sur Athlon 64. Nous ne sommes pas au courant d'un autre projet d'optimisation - manuel ou automatique - qui permettrait au benchmark swim d'atteindre ce niveau de performance sur processeur x86".
D'autres nouveautés en bref...
- La nouvelle version 3 d'OpenMP (sortie en mai 2008) est gérée par GCC 4.4. OpenMP est une interface de programmation permettant d'écrire des programmes parallèles et cette version 3 apporte de nombreuses nouveautés (dont le très attendu tasking évoqué ici avec un comparatif des performances).
- En ce qui concerne le langage C++ le travail sur le support de la future norme ISO C++0x continue vigoureusement et GCC 4.4 améliore encore la compatibilité avec ce nouveau standard. Ces nouvelles fonctions sont activables avec -std=c++0x et les progrès peuvent être suivis sur la page spéciale consacrée à C++0x du site GCC.
- Côté Fortran on note l'amélioration du support de la norme Fortran 2003 avec l'introduction, par exemple, des entrées/sorties asynchrones ou des entrées/sorties en UTF-8. GCC 4.4 apporte également le tout début du support de Fortran 2008 (accessible avec -std=f2008) et on peut donc utiliser, entre autres, les nouvelles primitives mathématiques (ASINH, ACOSH, ATANH, BESSEL, etc).
- En utilisant __attribute__ on peut profiter de nombreuses extensions spécifiques à GCC. La version 4.4 introduit la possibilité de changer le niveau d'optimisation pour certaines fonctions bien spécifiques dans son code. Il suffit d'utiliser pour ces fonctions l'attribut optimize et de spécifier un niveau d'optimisation. Cela peut être très utile pour optimiser dans son code une fonction qui est appelée fréquemment afin qu'elle s'exécute plus rapidement (-O3) alors qu'on préfère que les autres fonctions soient optimisées pour la taille (-Os).
- Les processeurs Intel Itanium profitent, quand on sélectionne le niveau d'optimisation -O3, d'un tout nouvel ordonnanceur d'instructions. On sait que l'architecture VLIW est très sensible à la qualité du code généré par le compilateur car tout le pari de cette architecture est de simplifier la partie hardware pour déporter la complexité coté génération de code. Le nouvel ordonnanceur permet de mieux fusionner les instructions, de renommer les registres et de faire de la spéculation d'exécution pendant la phase d'ordonnancement.
- GCC 4.4 apporte le support des dernières nouveautés du monde des processeurs. L'accélération matérielle du chiffrage AES est accessible (en ayant pour cible les processeurs Intel récents) avec l'option -maes tandis que les futures instructions vectorielles 256 bits AVX d'Intel, qui seront disponibles avec l'architecture Sandy Bridge prévue pour 2010/2011, sont accessibles avec l'option -mavx.
- Le code généré pour l'architecture de processeur ARM est largement optimisé par rapport aux versions antérieures. Il est maintenant possible d'optimiser spécifiquement pour des cibles telles que la version ARM Cortex-A9 (dont le support a été introduit dans le dernier noyau 2.6.29) ou la version Cortex-R4(F).
- Le support de l'architecture MIPS est significativement amélioré dans cette nouvelle version de GCC. Outre la génération de code pour les processeurs R10K, R12K, R14K et R16K on peut noter la possibilité d'optimiser le binaire pour les processeurs Cavium Octeon et pour les Loongson 2E/2F (du type de ceux qui se trouvent dans l'ultra-portable Gdium).
- Les processeurs de type Picochip font leur entrée dans la très longue liste des architectures supportées par GCC. Picochip est un processeur 16 bits multi-cœur qui regroupe plusieurs centaines de cœurs DSP sur une seule puce afin d'accélérer les traitements réseaux.
- Comme d'habitude avec chaque nouvelle version de GCC, la tolérance envers un code fautif est diminuée et le compilateur générera maintenant des erreurs alors que de simples alertes étaient signalées précédemment. On citera par exemple la sensibilité accrue du préprocesseur (chargé de lire les directives d'inclusions) qui refuse maintenant les #elif sans argument. Le développeur Debian Martin Michlmayr a listé les changements du préprocesseur ainsi que les nouveaux tests des includes manquants. Si vous êtes le mainteneur d'un paquet Debian alors Martin a déjà fait pour vous la déclaration de ces bugs triviaux (plus de 220 on été ouverts) et il ne vous reste plus qu'à corriger votre paquet pour que la compilation avec GCC 4.4 se déroule normalement.
L'infrastructure du projet...
La ferme de compilation du projet GCC a grandement augmenté ces derniers mois sa couverture des architectures supportées par le compilateur libre. Ce sont maintenant 12 architectures différentes qui sont représentées et on peut noter la présence de plusieurs bêtes de guerre (serveurs x86-64 bi-quad-cores avec 16 Go de mémoire vive).
Laurent Guerby est très impliqué dans la mise en place et l'organisation de cette ferme de compilation alors n'hésitez pas à prendre contact avec lui si vous pouvez faire un don de matériel ou obtenir des rabais auprès de vendeurs. Des machines puissantes en architecture mips, arm, powerpc64 ou sparc64 sont recherchées.
Pour finir...
Le compte rendu complet du sommet annuel GCC 2008 permet d'avoir une bonne idée du travail en cours sur le compilateur libre et de connaître à l'avance les nouveautés qui rentreront dans les futures versions. Les articles (très techniques) au format PDF sont disponibles sur le site du projet Fedora.
On y trouve notamment l'utilisation de GCC en tant qu'outil de vérification statique du code par les développeurs de Mozilla (Using GCC Instead of Grep and Sed), le travail sur la compilation incrémentale afin d'accélérer le cycle de développement (Incremental Compilation for GCC) ou encore l'inclusion de règles de codage directement dans le compilateur afin d'interdire la compilation de code non conforme aux normes édictées par un projet (Adding Coding Rule Checking Capabilities to the GCC Toolchain).
Aller plus loin
- Les nouveautés de GCC 4.4 (37 clics)
- La branche Graphite (14 clics)
- L'allocateur IRA (pdf) (4 clics)
- DLFP : Conférence Parinux : Le compilateur GCC vu de l'intérieur, et son évolution (7 clics)
- DLFP : Sortie de GCC 4.3 (24 clics)
# Bravo
Posté par med . Évalué à 9.
[^] # Re: Bravo
Posté par BAud (site web personnel) . Évalué à 2.
depuis au moins le 18 décembre 2008 que la dépêche est dans les tuyaux...
[^] # Re: Bravo
Posté par plagiats . Évalué à 4.
[^] # Re: Bravo
Posté par BAud (site web personnel) . Évalué à 3.
M'enfin c'est annoncé sur news.google hein, du sérieux : http://news.google.fr/news?pz=1&ned=fr&hl=fr&q=g(...)
[^] # Re: Bravo
Posté par Philippe F (site web personnel) . Évalué à 10.
Depuis le 4.0 et ces derniers temps en particuliers, le compilateur a repris du poil de la bête. En plus, ca le fait trop d'avoir une optimisation unique au monde à la pointe de la recherche, qui explose de 30% des benchmarks !
Longue vie à gcc alors. Et sinon, le code interne est toujours aussi atroce ? Des dires de ce qui avaient regardé, ca faisait plutôt peur.
# POISSON D'AVRIL !!!!!!
Posté par Mouns (site web personnel) . Évalué à 5.
[^] # Re: POISSON D'AVRIL !!!!!!
Posté par Nÿco (site web personnel) . Évalué à 2.
(Bon, on va pouvoir parler du 755 maintenant...)
# Gains de performance
Posté par seginus . Évalué à 4.
Les gains de performances de 32 et 38% annoncé pour les athlons sont bien des temps de « rapidité » à l'exécution des programmes ? Cela me semble énorme. Cela veut-il dire qu'en recompilant par exemple une distribution source avec le nouveau compilateur, le gain de vitesse se fera vraiment ressentir au niveau du système ? ou est-ce des optimisations qui sont à utiliser lors de la programmation.
[^] # Re: Gains de performance
Posté par Martin Peres (site web personnel) . Évalué à 2.
J'attend que Arch Linux sorte le paquet pour GCC 4.4 pour me recompiler toute mon architecture graphique !
[^] # Re: Gains de performance
Posté par patrick_g (site web personnel) . Évalué à 10.
Jai pourtant bien pris soin de faire une importante précision : "test effectué sur le benchmark spécifique swim du comparatif standard SPEC2000".
L'ampleur du gain n'est donc pas généralisable.
[^] # Re: Gains de performance
Posté par gasche . Évalué à 5.
En gros, c'est une manière de dire : "Pour ce petit programme très spécialisé, mon optimisation tue tout ce qu'on sait faire pour l'instant, donc c'est une super optimisation". Ça veut pas dire que les gains seront tellement énorme en pratique (peut-être, mais ne rêve pas trop).
[^] # Re: Gains de performance
Posté par Adrien . Évalué à 1.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Sur debian, seuls quelques paquets sont optimisés pour l'architecture, pour 90% des logiciels, cela ne change rien (et je suis gentils sur le 90%).
Je crois que mplayer détecte maintenant tout seul le type de processeur et optimise de lui même le code à charger... Il n'y a même plus besoin d'avoir plusieurs versions.
Bref, comme dans un code de calcul, on connait plus ou moins les goulots d'étranglement sur un poste de travail. Cabler l'AES dans le microprocesseur plus ajouter du traitement du signal vidéo pour le H264 vont à mon avis éliminer une bonne partie des ralentissements du poste de madame michu.
[^] # Re: Gains de performance
Posté par Fabimaru (site web personnel) . Évalué à 3.
- le temps de compil avec un gcc compilé avec gcc4.4
- une compression de vidéo
- un benchmark DB et web (ou les deux à la fois, tiens)
Demain sur Phoronix peut-être :-)
[^] # Re: Gains de performance
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
[^] # Re: Gains de performance
Posté par M . Évalué à 4.
[^] # Re: Gains de performance
Posté par Frédéric COIFFIER . Évalué à 2.
[^] # Re: Gains de performance
Posté par Gniarf . Évalué à 5.
sauf que tu bouffes 100 fois plus de RAM à la compil
c'est ça le progrès, ma bonne dame !
[^] # Re: Gains de performance
Posté par Cédric Bastoul . Évalué à 10.
[^] # Re: Gains de performance
Posté par lasher . Évalué à 1.
[^] # Re: Gains de performance
Posté par Cédric Bastoul . Évalué à 8.
Haha, même pas mal, je suis tellement susceptible que maintenant je fais mon boulot dans le privé aux US. Ça fait mal au coeur que ce soient les ricains qui fassent du blé avec la recherche académique française mais comment pourrait-il en être autrement avec les guign... Argh tu m'as eu !!!
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
En fait, je suis curieux des bêtises étatiques en dehors du fait que les caisses sont vides et qu'il rabote partout ou ils peuvent. Quel genre d'absurdité d'organisation, peut-on trouver ?
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Ontologia (site web personnel) . Évalué à 3.
Par exemple, Inria transfert, qui s'occupe de valoriser industriellement des technos développées au sein de l'inria, n'a pas la possibilité, le droit, d'embaucher en CDI un chercheur qui les intéresse au sein de l'Inria. Il doit passer par le concours classique, ou seul le théorique compte, sans compter les petites histoires existantes au sein de ce petit monde...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 2.
Des trucs hallucinants y'en a des tonnes, mais la je vois pas...
[^] # Re: Gains de performance
Posté par Ontologia (site web personnel) . Évalué à 4.
La recherche fondamentale et appliquée sont complémentaires, pas opposées.
Je vois pas ce qui te dérange...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 3.
Pour rebondir sur ta réponse; embaucher des mecs pour faire de la recherche fondamentale dans les deux premières années ce n'est pas forcement la meilleure idée... Ça ne veut pas dire non plus qu'un chercheur ne peut pas se retrouver sur un poste "industriel" si il en a l'envie et les compétences.
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 3.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Laurent A. . Évalué à 4.
J'avoue que je ne vois absolument pas de quoi vous parlez...
[^] # Re: Gains de performance
Posté par Anonyme . Évalué à 5.
[^] # Re: Gains de performance
Posté par Cédric Chevalier (site web personnel) . Évalué à 2.
Comme quoi finalement c'est cohérent.
[^] # Re: Gains de performance
Posté par Etienne Bagnoud (site web personnel) . Évalué à 3.
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Par contre, l'état réduit de ~1 milliard les i mpots directs, file une prime pour les voitures, construit des lignes TGC, des autoroutes, etc... C'est ce genre de mesure qui coute.
Quand à l'export des cerveaux, cela concerne en fait très peu de monde.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par med . Évalué à 10.
Pour le moment je bosse aux USA. Dans mon domaine, d'après un papier que j'ai lu, le rapport thèses/postes est de 2 (en France il est de 5), les profs ne font pas plus d'une centaine d'heures d'enseignement par an (même moins s'ils rachètent leurs enseignements grâce aux bourses qu'ils ont obtenues), le salaire d'embauche c'est au minimum 70k$/an (dans une université publique, souvent plus dans une université privée), le budget recherche c'est au minimum 10000$/an et souvent beaucoup plus (j'ai mon collègue de bureau qui s'est reçu 60000$ pour un petit projet).
Donc voilà au final j'ai coûté cher à la France mais comme la France ne veut pas de moi (pour l'instant du moins), je fais le bonheur des USA. C'est pas un hasard si les USA sont la première puissance économique mondiale, ils investissent dans la recherche. Regardez aussi les Chinois qui se développent à vitesse grand V, ils investissent beaucoup dans la recherche. Il y a 10 ou 15 ans on les voyait pas, maintenant ils sortent plein de bons papiers. Et encore je suis dans de la recherche fondamentale.
¹ : d'ailleurs pour ma thèse, quand j'ai demandé à avoir un ordinateur on m'a rétorqué qu'il n'y avait pas de budget pour ça² (donc soit le directeur paie sur son budget soit l'étudiant n'a pas d'ordi à lui) et que donc je travaillerai sur une antique station sun. Comme il en était hors de question, j'ai fini par trouver un vieux PC de 10 ans d'âge qui traînait par là sur lequel j'ai mis linux. J'ai fini par craquer et m'acheter un portable pour réussir à travailler correctement.
² : heureusement, ça a changé un peu plus tard.
[^] # Re: Gains de performance
Posté par madrunner . Évalué à 4.
- davantage de recrutement de chercheurs purs (même si c'est une erreur a mon sens... 64h eq TD/an ca ne fait pas de mal et ça permet de revenir dans le monde réel).
- des vrais moyens pour la recherche (loin au dela des 1000 euros évoqués et même au dela des 10000/personne si un projet tient un peu la route... Perso j'ai rentré 190k pour 3 ans).
- La possibilité extrêmement facilitée de fonder une start up. Il est possible de conserver son salaire payé par l'état pendant un an (donc pas besoin d'être recruté), conservation de son statut de chercheur et possibilités à la discrétion du chef de centre d'obtenir d'autres aides.
Bref, c'est pas mal... Reste un soucis effectivement : le salaire. Ridiculement bas face aux compétences. Même en cette période de crise il est facile de se faire embaucher ailleurs pour un salaire au moins du double de celui proposé... Du coup, pas si facile d'attirer les jeunes les plus brillants.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 4.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Il faudrait savoir ce qui reste en net. C'est très différent la manière de compter entre public et privé. Mais dans l'absolu, c'est pas terrible... pour ne pas dire risible.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par gpe . Évalué à 2.
Actuellement un débutant en info industrielle en SSII doit négocier serré pour avoir plus de 25k€ brut et avoir plus de 30k€ tient quasi du miracle. Alors avoir le double de 23k€ je n'y crois pas un instant. Un ingé avec 10 ans d'exp tourne entre 45 et 55k€ en moyenne je dirais.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par lasher . Évalué à 3.
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 4.
Oui faire du 45K€ en moins de 5 ans c'est possible. En poussant les bonnes portes tu peux même faire beaucoup mieux pour un job pas forcement dégueu... Demande à des @(google|ms|sap|oracle|apple|cisco|ebay) combien ils gagnent.
Y'a pas si longtemps, les écoles d'ingés te vendaient un salaire de sortie à 20KF/mois...
[^] # Re: Gains de performance
Posté par gpe . Évalué à 2.
[^] # Re: Gains de performance
Posté par ckyl . Évalué à 1.
BTW, si tu acceptes d'être aussi mal payé avec une qualification élevée, devient chercheur en France t'auras au moins les avantages du statut de fonctionnaire...
[^] # Re: Gains de performance
Posté par gpe . Évalué à 3.
Le rapport est que Madrunner disait qu'il était facile de se faire embaucher au moins au double de ce que propose l'INRIA. Moi je dis que c'est très loin d'être évident actuellement.
PS: l'info indus ce n'est pas que l'automatisme, c'est l'info temps réel, l'info embarquée, etc.
BTW, si tu acceptes d'être aussi mal payé avec une qualification élevée, devient chercheur en France t'auras au moins les avantages du statut de fonctionnaire...
On parlait d'ingé. Dans l'info, l'ingé c'est un peu l'OS des chaînes de montage...
Si tu veux vraiment commencer à t'en mettre plein les fouilles il faut quitter la technique et passer dans le management.
[^] # Re: Gains de performance
Posté par Antoine . Évalué à 5.
Et c'est bien malheureux. A cause de ça, on a une "industrie de l'informatique" limitée à des SSII spécialisées dans le moins-disant et l'exploitation à bas prix d'informaticiens démotivés par des commerciaux incompétents.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par M . Évalué à 2.
A 10 ans d'experience, je pense que ca varie beaucoup plus suivant ton parcours...
[^] # Re: Gains de performance
Posté par gpe . Évalué à 1.
Je parle d'info indus pas d'info de gestion qui rapporte bien plus.
[^] # Re: Gains de performance
Posté par Jul (site web personnel) . Évalué à 7.
La Recherche & Développement implique que les entreprises embauchent, or nos chercheurs ne sont pas chers (et plutô bons) donc ce ne sont pas eux le problème.
Si ils n'embauchent pas, ils n'ont pas d'excuses. Après ils se plaignent que l'état ne leur donne pas d'argent et des crédits, mais ils sont drôles : avant de demander de l'argent, il faudrait peut être avoir des projets et une stratégie.
Si nos entreprises sont vieillissantes et aussi peu innovantes, c'est avant tout de leur responsabilité : ça s'appelle le capitalisme, tu prends le risque de gagner, et tu gagnes, tu fais rien, t'investit pas et bien tu crèves comme l'industrie du disque.
Ce sont les entreprises qui sont le problème, pas l'état. Et pour elles, vae victis. Si elles ont pas voulu de nos chercheurs, et bien qu'elles ne viennent pas pleurer.
Bonne chance aux expatriés :)
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Mathias Bavay (site web personnel) . Évalué à 8.
Devinez ce que j'ai choisi...
J'ai maintenant quitte les US pour venir travailler en Suisse, ou je gagne beaucoup plus que si j'etais en France, ou nous avons de tres bonnes conditions de travail, ou nous avons des moyens financiers pour notre recherche et ou l'on peut monter projet sur projet (avec le financement qui va bien). Et autant j'apprecie rentrer en France pour les vacances, autant il ne faut pas compter sur moi pour revenir y travailler! (et je conseille a tous mes collegues qui travaillent en France de faire la meme chose: si les chercheurs sont trop chers pour le pays, autant ne pas se facher, rester en bons termes et partir travailler ailleurs!)
/ma_vie
Mathias
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par med . Évalué à 5.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
5 ou 6 pour la Suisse. 2.9% du PIB, 25 400 chercheurs, 7 479.2 m$, 0,29 m$/c
9/1000 au USA, 2.6% du PIB, 1 387 882 chercheurs, 343 747.5 m$, 0,25 m$/c
Si on veut un ratio de 0.25m$/c il faut passer à un budget de 50M$ soit +20% (!) soit tomber à 165 744 chercheurs à budget constant.
Le problème est sans doute dans la contraction du nombre de postes avant de contraindre le nombre de doctorant.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par med . Évalué à 4.
Pour les budgets, il faudrait aussi voir quelle fraction part dans l'administration. Je soupçonne que la recherche française avec ses multiples strates juxtaposées (auxquelles les étrangers ne comprennent d'ailleurs rien) n'est pas forcément très bien placée de ce point de vue. J'aimerais aussi voir les chiffres pour la recherche scientifique. Je doute qu'un enseignant-chercheur en anglais disons nécessite les mêmes moyens qu'un biologiste ou un physicien.
Pour les USA il faut aussi voir ce qu'ils comptent dans le budget. Par exemple un prof dans un “liberal arts college” ne fait pas beaucoup de recherche (et a souvent un salaire un peu inférieur) et coûte donc moins cher qu'un prof dans une “research university”. Enfin tout ça pour dire que c'est difficile de faire une comparaison avec quelques chiffres. Mais toujours est-il qu'en sciences dures, dans une “research university” l'écart paraît bien plus élevé que ça.
[^] # Re: Gains de performance
Posté par Cédric Bastoul . Évalué à 8.
Le principal problème vient du manque de transfert de notre recherche vers nos entreprises dont la R&D est insuffisante. Nous produisons (à un rapport qualité/prix imbattable) de bons résultats qui sont trop rarement exploités en France (voir le nombre de dépôts de brevets ridicule). Nous formons de bons docteurs qui s'ils ne trouvent pas une des rares places dans le publique doivent s'expatrier pour poursuivre leur recherche, ou se recycler. C'est un gâchis incroyable. En gros, et je caricature à peine, on finance la recherche américaine !
Le transfert technologique peut se faire de deux manières :
- Les entreprises font de la R&D et embauchent des docteurs ou des chercheurs consultants.
- Les chercheurs montent des start-ups pour valoriser leur travail.
Le premier cas ne fonctionne pas bien car il y a trop peu de recherche privée en France, pas assez pour absorber ni les nouvelles idées ni les nouveaux chercheurs. Il y a des raisons profondes et la première d'entre elles est la méconnaissance des deux parties. Un exemple bien connu est le clivage Grandes Écoles (où les étudiants, futurs décideurs en puissance, ne sont pas assez en contact avec la recherche) et universités (où se fait la recherche et où les contacts avec les entreprises sont limités) dont on est malheureusement pas près de se débarrasser... Alors que l'État devrait se faire un devoir de créer des ponts (il y a eu des tentatives timides récentes comme le monitorat en entreprise pour les doctorants), tout ce qu'il trouve à faire est de cracher (et le mot est faible) sur ses chercheurs. Voir le discours présidentiel du 22 janvier 2009, retentissant dans notre milieu. Bref, au lieu d'inviter les deux mondes à se rencontrer, on nous colle une image complètement à côté de la plaque de fonctionnaires parasites incompétents pour les chercheurs titulaires et d'étudiants glandeurs attardés pour les doctorants. Avec ça c'est sûr que les entreprises françaises ont envie de nous rencontrer ou de nous embaucher.
Le cas de la création de start-up est encore pire selon l'expérience de mes malheureux collègues qui ont tenté le coup. En fait c'est très simple, dès qu'on met le doigt là dedans on est pris pour un suspect par tout le monde. Les tutelles (université, centres de recherche) qui veulent leur part tout d'abord. Tout ce qu'un chercheur d'une université développe appartient à son université, s'il veut monter une entreprise et réutiliser son travail commence un vrai parcours du combattant. L'État aussi coupe les vivres rapidement : forcément, on est maintenant dans son entreprise donc plus besoin de son travail d'origine ni de sa paie. L'autorisation de cumul (que l'on doit demander avec dossier et qui peut être refusée bien entendu) vaut pour un an renouvelable une fois (toujours sur dossier). Ensuite il faut choisir. C'est beaucoup trop court, trop compliqué, trop risqué. Les chercheurs ne sont pas des entrepreneurs et ne sont pas payés suffisamment pour avoir de quoi se lancer dans un projet à risque. Plutôt que de nous aider on nous enfonce, et des projets, à la pelle, meurent dans l'oeuf tant le découragement est grand.
Bref, voilà ce que je reproche aux politiques. Le plus navrant c'est que tout peut se résoudre à leur niveau... Et qu'ils font tout le contraire : nous diviser du monde de l'entreprise et nous coller des bâtons dans les roues pour exploiter notre travail.
[^] # Re: Gains de performance
Posté par khivapia . Évalué à 3.
On peut si je ne me trompe pas cumuler auto-entrepreneur et emploi dans la fonction publique ou ailleurs. Ne serait-ce pas une solution pour commencer à monter une boîte, continuant à être payé d'un côté et gardant le lien avec les instituts de recherche, et commençant à se développer de l'autre ? Le chiffre d'affaire maximum de l'auto-entrepreneur est de 32K€ par an dans les services, ça laisse un peu de marge ? Ou bien alors je n'ai aucun sens des réalités, ce qui est possible aussi...
[^] # Re: Gains de performance
Posté par Cédric Bastoul . Évalué à 5.
Pour ce qui concerne les (enseignants-)chercheurs, il y a trois possibilités (je résume, hein) :
- Cumul à titre accessoire (temps et rémunération ne peuvent dépasser la moitié du temps de travail et le salaire du chercheur), soumis à autorisation de l'administration. Cela sert le plus souvent à donner des cours à l'extérieur de son établissement ou faire du consulting. La création d'entreprise est définie comme non-accessoire (pas possible d'utiliser ce type de cumul).
- Cumul pour la création, la reprise ou a poursuite d'activité en entreprise (le cas qui nous intéresse), toujours soumis à autorisation de l'administration et cette fois de la commission de déontologie (pour éviter les conflits d'intérêt). On peut cumuler pendant un an renouvelable une fois, puis on peut choisir de prendre une disponibilité pour création d'entreprise pour deux ans maximum (cela revient à mettre en pause son travail de fonctionnaire : pas de salaire, d'avancement ou de cotisations retraite, mais on peut demander à être réintégré). En tout après 1 ou 2 ans on a plus que son salaire de l'entreprise et au bout 3 ou 4 ans au maximum il faut quitter la fonction publique.
- Cumul si on ne travaille pas à plein temps, là encore on ne peut pas dépasser son temps de travail ou son salaire à 100% ni être dans une situation de conflit d'intérêt.
Le cumul est beaucoup plus facile pour un chercheur pur (plus rare que l'enseignant-chercheur) qui n'a pas de cours à donner ou de responsabilités pédagogiques (ils pourraient décharger les enseignants de cours durant la période). Être obligé d'abandonner définitivement son poste (qu'on a souvent bien ramé pour obtenir) en 3 ou 4 ans c'est rude, la viabilité de l'entreprise est probablement encore largement incertaine (aller jusqu'à 6 ans ne semble pas intolérable). Et je ne parle pas des dossiers administratifs à monter qui chaque année peuvent se faire bouler pour une raison ou une autre, ajoutant à l'incertitude (plutôt que d'accepter les renouvellements et la disponibilité sur demande dès que le premier dossier a été accepté).
Disons que c'est moyennement incitatif pour des gens ayant un métier qu'ils aiment et/ou la sécurité de l'emploi.
[^] # Re: Gains de performance
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Diminuer le nombre de doctorant et pour augmenter le nombre de poste ?
Régler le problème de ratio thèse/poste de 5 à 2 comme au US, si on a pas d'argent publique pour les nouveaux postes, il reste le moyen de diminuer le nombre d'étudiant. Mais je ne pense pas que cela soit accepté.
Tu critiques la vision des ingénieurs, sur les chercheurs mais l'inverse est vrai aussi. Un chercheur est souvent très dédaigneux sur le travail d'un ingénieur. En informatique, un code propre maintenable même énorme n'a aucune valeur pour eux, et encore, si il considère qu'une implémentation à un intérêt par rapport à simplement la description d'une idée dans un article.
J'avais vu par exemple la hiérarchisation entre les différentes branches de mathématiciens. Tout en haut était les maths abstraites qui ont permis de faire l'arme atomique des années 60, et tout en bas, les maths appliqués qui peuvent amener à d'extraordinaire chose une fois mis dans un programme.
"La première sécurité est la liberté"
[^] # Re: Gains de performance
Posté par Cédric Bastoul . Évalué à 2.
Diminuer le nombre de doctorant et pour augmenter le nombre de poste ?
Le gouvernement a mis un tas d'argent dans la recherche privée avec le crédit impôt recherche. Je trouve ça très bien. Par contre (1) c'est (encore une fois) un chèque en blanc, une telle passoire administrative que les entreprises s'en servent à tout sauf à la recherche (facile de trouver des articles là dessus). Et (2) il n'y a aucune disposition claire et quantifiable pour des ponts entre public et privé. Pourtant c'était facile à imaginer :
côté entreprise :
- salaire d'un nouveau docteur recruté en crédit impôt recherche,
- consulting d'un (enseignant-)chercheur du publique en crédit impôt recherche,
- financement de partenariats publique-privé en crédit impôt recherche,
- ...
[Mais bien fait, hein, avec un vrai calcul sinon ça ne sert à rien]
Côté chercheurs :
- entrer un certain nombre d'heures de travail en entreprise dans le décompte du service contre décharge du nombre d'heures d'enseignement,
- défiscalisation du consulting (peut être un peu rude, là :-D !),
- que sais-je...
Tu critiques la vision des ingénieurs, sur les chercheurs mais l'inverse est vrai aussi.
Je ne critique rien de tel ??? En fait je ne fais que déplorer le fait qu'ils ne se connaissent pas, c'est tout. Mais je parlais des diplômés issus des Grandes Écoles (X, ENS, Mines, Ponts, Centrale et peut-être une autre que j'oublie), pas des ingénieurs en général.
Un chercheur est souvent très dédaigneux sur le travail d'un ingénieur.
[En dehors du fait que ça me semble totalement gratuit...] Les deux ne font pas le même métier, que les deux soient capables de pisser du code n'y change rien. Il faudrait peut-être juste qu'ils l'apprennent et/ou le comprennent...
[^] # Re: Gains de performance
Posté par Diagonale de Cantor (site web personnel) . Évalué à 3.
Si je peux me permettre les gens des ENS connaissent bien le monde de la recherche ( même mieux que le monde ingénieur), étant donné qu'ils deviennent, pour une grande partie d'entre eux, des (enseignents/)chercheurs.
Mais ils est vrai qu'elles font exceptions dans la paysage français et c'est vraiment quelque chose de dommage.
[^] # Re: Gains de performance
Posté par bengo (site web personnel) . Évalué à 1.
http://www.zeitgeistmovie.com
http://www.thezeitgeistmovement.com
# Record
Posté par patrick_g (site web personnel) . Évalué à 10.
Ahahaha ! Avec une performance aussi titanesque que celle-là je ne risque pas d'être battu et j'emporterai le record dans ma tombe !
PS : Interdiction aux petits malins de poster dès demain une news sur la sortie de Debian Squeeze...ce serait de la triche pure et simple ;-)
[^] # Re: Record
Posté par thedidouille . Évalué à 2.
Je sais pas si il y aura de grosses différences pour les performances des binaires produit pour nos distributions, étant donné qu'il y a très peu de boucles vraiment complexe dans un code généraliste, et que les processeurs supportant l'architecture x86 est bardée d'optimisation pour la gestion des registre (à part ceux consommant peu d'énergie), mais la beauté du travaille fourni vaut tout les résultats en "elapsed time" qu'on veut.
Il faudrait faire un benchmark en comparant les résultats d'un firefox 3.0.8 builder avec ces optim, et comparer avec le build Windows exécuter sous Wine (qui est construit à partir d'un profile feedback ...).
Voir :
http://www.tuxradar.com/content/benchmarked-firefox-javascri(...)
[^] # Re: Record
Posté par balzane . Évalué à 10.
Tant pis, on va se rabattre sur GNU/Hurd...
OK, --> []
[^] # Re: Record
Posté par rhys . Évalué à 3.
Il y'a plus de chance que la France gagne la prochaine coupe de monde.
[^] # Re: Record
Posté par imalip . Évalué à 6.
Et puis on n'est jamais a l'abris de surprise, si on m'avait dit en janvier qu'on ferait un double devant Honda, j'aurais classe ca dans la categorie SF aussi...
[^] # Re: Record
Posté par patrick_g (site web personnel) . Évalué à 2.
[^] # Re: Record
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Record
Posté par patrick_g (site web personnel) . Évalué à 4.
[^] # Re: Record
Posté par imalip . Évalué à 5.
Vivement le nouveau diffuseur...
[^] # Re: Record
Posté par imalip . Évalué à 4.
[^] # Re: Record
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 1.
Et tu peux rajouter candidat au titre aussi...
En tout cas un grand bravo, la voiture est magnifique, Vettel impressionnant... et j'espere qu'avec Brawn, vous tiendrez bon cette année face aux grosses!
[^] # Re: Record
Posté par dyno partouzeur de drouate . Évalué à 5.
# Polyhèdre vs Polytope
Posté par ribwund . Évalué à 3.
Par exemple: http://en.wikipedia.org/wiki/Polyhedron#General_polyhedra
[^] # Re: Polyhèdre vs Polytope
Posté par Dup (site web personnel) . Évalué à 5.
Pour une fois je n'ose cliquer sur les liens m'attendant à avoir quelquechose d'incompréhensible pour ma personne, on verra demain si je m'ennuie au boulot.
[^] # Re: Polyhèdre vs Polytope
Posté par JoeltheLion (site web personnel) . Évalué à 4.
http://en.wikipedia.org/wiki/Polytope_model
http://www.infosun.fim.uni-passau.de/cl/loopo/doc/loopo_doc/(...)
# Optimisations...
Posté par Christophe Merlet (site web personnel) . Évalué à 2.
L'allocateur IRA utilise l'algorithme de Chaitin-Briggs au lieu Callahan-Koblenz ou Regional. J'ai pas bien compris :/
Et l'optimiseur de boucle GRAPHITE n'est pas non plus activé par défaut :(
En plus de ça, il me semble que la vectorisation du code n'est toujours pas automatique...
# Jamais content
Posté par Sytoka Modon (site web personnel) . Évalué à 9.
Si tu commences à péter des gros projets parce que les options pas défaut ont trop changé, tu fait fuir les gens de ton projet. Si tu obliges les gens à modifier leur chaine de compilation car le compilateur merde car optimise trop, tu es mal. J'ai vu des codes de calcul qui donnent des résultats faux selon les paramêtres d'optimisation. Trop vouloir optimiser ne donnent pas toujours un résultat juste.
Je penses que tu n'as aucune conscience de la responsabilité et du stress que prennent les développeur de GCC a chaque version...
[^] # Re: Jamais content
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
S'il y a un admin dans le coin qui sais déplacer un commentaire, il est le bienvenue ;-)
[^] # Re: Jamais content
Posté par Cédric Bastoul . Évalué à 6.
Pour les codes de calcul si on pousse les optimisations un peu fort, on autorise le compilateur à considérer que l'addition ou la multiplication sont commutatives, ce qui peut faire au final de gros écarts de précision voire des overflows (certains codes assez malins sont organisés par exemple pour intercaler des additions de nombres positifs et négatifs pour éviter les dépassements, et il suffit d'un bête échange d'opération qui semble anodin pour faire un overflow)... Là encore il faut être prudent et ce n'est pas toujours la faute au compilateur.
[^] # Re: Jamais content
Posté par lasher . Évalué à 4.
Juste une petite remarque : sur un processeur tel que le x86 ou le PowerPC, intercaler ce genre d'opération ne garantit absolument rien quant à l'ordre des opérations, vu que le système out-of-order va choisir dans quel ordre émettre les instructions (en fonction de la place restante dans la station de réservation). Ce qui pourrait presque rendre « caduque » certaines transformations du compilateur d'ailleurs. Tout dépend du coup de la chaîne de dépendances qui existe entre les registres (i.e. plus j'ai des registres dont le contenu sert à mettre à jour d'autres registres, moins l'exécution dans le désordre aura d'effet ... mais du coup plus on sera potentiellement limité dans le parallélisme d'instruction).
[^] # Re: Jamais content
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: Jamais content
Posté par lasher . Évalué à 1.
[^] # Re: Jamais content
Posté par meuh31 . Évalué à 5.
[^] # Re: Jamais content
Posté par Cédric Bastoul . Évalué à 4.
[^] # Re: Jamais content
Posté par M . Évalué à 1.
Oui mais bon, avant de changer de compilo tu es aussi censé evaluer celui-ci et verifier qu'il ne casse rien. Parce que tu n'es jamais a l'abris d'un bug/regression dans gcc (il y a qu'a regarder le nombre de bug dans leur bugzilla).
[^] # Re: Jamais content
Posté par Troy McClure (site web personnel) . Évalué à 4.
# Distribs
Posté par Aurélien Bompard (site web personnel) . Évalué à 1.
Je ne suis au courant que pour Fedora, qui va bien avoir GCC 4.4 pour la prochaine version (F11).
[^] # Re: Distribs
Posté par Rémi Birot-Delrue . Évalué à 3.
[^] # Re: Distribs
Posté par Laurent Carlier . Évalué à 2.
http://packages.debian.org/experimental/devel/gcc-4.4
# BRAVO
Posté par Mehdi Saada . Évalué à 1.
Ca a l'air balèze Graphite, franchement.
Espérons que cela ne va pas couler LLVM :-P, espérons qu'ils pourront réutiliser ce travail :-(.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.