Sortie de la version 4.4 du compilateur GCC

Posté par (page perso) . Modéré par Mouns.
Tags :
38
21
avr.
2009
GNU
Aujourd'hui la sortie de la version 4.4 du compilateur GCC a été annoncée sur la liste de diffusion du projet.
É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).
  • # Bravo

    Posté par . Évalué à  9 .

    Aux développeurs de gcc pour tout le travail accompli et à patrick_g pour cette magnifique dépêche. Comme quoi tout vient à point à qui sait attendre. ;)
    • [^] # Re: Bravo

      Posté par (page perso) . Évalué à  2 .

      tout vient à point à qui sait attendre

      depuis au moins le 18 décembre 2008 que la dépêche est dans les tuyaux...
    • [^] # Re: Bravo

      Posté par (page perso) . Évalué à  10 .

      Il me semble qu'il y a quelques années, on percevait un essoufflement net dans le développement de gcc et on avait l'impression qu'il était plutôt à la ramasse sur pas mal de sujets (vitesse de compilation, temps d'exécution, ...).

      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 (page perso) . Évalué à  5 .

    en fait, c'est une blague que l'on a faite à patrick_g parmi les AMR ... GCC 4.4 n'est toujours pas sorti.
  • # Gains de performance

    Posté par . Évalué à  4 .

    Je n'ai que peu de connaissances en compilation, utilisant surtout des languages interprétés. Cependant, ayant utilisé longtemps Gentoo, cela compense un peu.

    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 (page perso) . Évalué à  2 .

      Normalement, une simple recompilation devrait permettre de profiter de ces améliorations ! C'est ça qui est magique :d

      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 (page perso) . Évalué à  10 .

      >>> 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 ?

      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 . Évalué à  5 .

      Il s'agit d'un gain observé sur un benchmark spécifique, c'est à dire un petit bout de code fait exprès pour tester intensivement certaines caractéristiques du compilateur. D'une part, ne t'attends pas à observer des gains similaires sur les "programmes normaux", et d'autre part les gains ne sont pas forcément spécifiques aux Athlon (la personne cité parle des Athlon, soit parce qu'il a testé dessus, soit parce que des particularités de l'architecture font que c'est une optimisation spécialement pertinente dessus, mais le code ne dépend pas de l'architecture).

      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 . Évalué à  1 .

        Il y a eu des tests sur de vrais logiciels pour voir le gain qu'on peut réellement avoir ?
        • [^] # Re: Gains de performance

          Posté par . Évalué à  4 .

          Spec utilise des vrais programmes.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

        • [^] # Re: Gains de performance

          Posté par (page perso) . Évalué à  8 .

          Il y a maintenant quelques années, il y avait un comparatif en une gentoo et une debian, la debian étant alors compilé pour du 486 (maintenant, c'est du 586 il me semble). Grosso modo, la debian allait plus vite en moyenne...

          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 (page perso) . Évalué à  3 .

      Sans regarder et sans vouloir faire le pessimiste, je suis prêt à parier que c'est sur un cas très spécifique. Ce qui m'intéresserait, c'est de voir le gain de perf par exemple sur:
      - 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 (page perso) . Évalué à  10 .

        Faut voir aussi que le meilleur compilateur du monde ne rendra pas un disque dur ou une carte réseau plus rapide. Le compilateur, ça peut accélérer les calculs, mais pas les I/Os, qui représentent quand même une partie pas négligeable du temps d'exécution d'un logiciel classique !
      • [^] # Re: Gains de performance

        Posté par . Évalué à  4 .

        Pour la video tu peux jeter un coup d'oeil sur http://multimedia.cx/eggs/icc-vs-gcc-smackdown-round-3/ . Mais c'est pas sur que toutes les optimisations aient été activées
        • [^] # Re: Gains de performance

          Posté par . Évalué à  2 .

          Avec GCC 4.4, on retrouve donc les perfs que l'on avait plus ou moins perdu depuis la fin de GCC 3.x ?
          • [^] # Re: Gains de performance

            Posté par . Évalué à  5 .

            > Avec GCC 4.4, on retrouve donc les perfs que l'on avait plus ou moins perdu depuis la fin de GCC 3.x ?

            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 (page perso) . Évalué à  10 .

      Les gains de performance apportés (et surtout à venir) grâce à GRAPHITE sont réels et sur des applications bien réelles... Mais effectivement aussi bien spécifiques. GRAPHITE vise avant tout les codes très réguliers avec beaucoup de boucles et de gros volumes de données accédées. Les premiers bénéficiaires sont par exemple les calculs scientifiques ou le traitement du signal. Sur certaines applications pointues les gains sont très sensibles (je fais plutôt dans le scientifique, je n'ai pas testé mais les filtres de GIMP ou autres traitements d'image ou de vidéo par exemple sont de très bons candidats pour en profiter), mais malheureusement il n'y aura pas de miracle (avec GRAPHITE) sur la compilation du kernel par exemple, qui est un code hautement irrégulier (plein de branchements imprévisibles dans tous les sens, pile ce que GRAPHITE a en horreur).
      • [^] # Re: Gains de performance

        Posté par . Évalué à  1 .

        Mmmmh, ça sent la propagande crypto-communiste d'un prof de fac ça ... O:-) Bon bon. Sinon, je corrobore ce que dit Cédric.
        • [^] # Re: Gains de performance

          Posté par (page perso) . Évalué à  8 .

          Mmmmh, ça sent la propagande crypto-communiste d'un prof de fac ça ...

          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 . Évalué à  4 .

            Les "guignols" a part être pingre, tu leur reproches quoi ?

            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 liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: Gains de performance

              Posté par (page perso) . Évalué à  3 .

              J'en ai une à raconter ! Et je suis pas chercheur, comme quoi...

              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...

              Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

              • [^] # Re: Gains de performance

                Posté par . Évalué à  2 .

                En même temps pourquoi voudrais tu que Inria-Transfert recrute un chercheur ?

                Des trucs hallucinants y'en a des tonnes, mais la je vois pas...
                • [^] # Re: Gains de performance

                  Posté par (page perso) . Évalué à  4 .

                  Pour bosser sur un projet qui donnerai lieu à la création d'une startup, par exemple.

                  La recherche fondamentale et appliquée sont complémentaires, pas opposées.

                  Je vois pas ce qui te dérange...

                  Un pays bien organisé est celui où le petit nombre fait travailler le grand nombre, est nourri par lui, et le gouverne - Voltaire

                  • [^] # Re: Gains de performance

                    Posté par . Évalué à  3 .

                    Ce n'est pas la mission de transfert que d'embaucher du personnel pour le compte des sociétés, ce n'est pas une agence d'interim ! Ils peuvent t'aider à trouver des fonds pour que tu puisses embaucher par contre. Mon propos n'était pas qu'un chercheur n'a rien à faire dans une startup. Simplement que ta remarque était invalide (et ce quel que soit le type de poste).

                    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 . Évalué à  3 .

                      Est-ce que ceux qui moinssent peuvent se justifier ? Pour info, je suis ex-ingé INRIA qui bosse dans une startup INRIA. Je pense pas que mon commentaire soit inutile ou ni complètement stupide...
                      • [^] # Re: Gains de performance

                        Posté par . Évalué à  3 .

                        Si Inria transfert à le droit d'embaucher des ingé pour faire des développements pour rendre une téchnologie plus utilisable, pourquoi devoir passer par le recrutement hautement théorique type chercheur ? C'est pas le même boulot.

                        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                        • [^] # Re: Gains de performance

                          Posté par . Évalué à  4 .

                          Je vois des ingés autour de moi qui ont été engagé pour une start-up à l'INRIA sans machin théorique à passer.
                          J'avoue que je ne vois absolument pas de quoi vous parlez...
            • [^] # Re: Gains de performance

              Posté par Anonyme . Évalué à  5 .

              c'est rigolo comme il est facile de trouver des milliards voir des trilliards pour les banques. Ne rien faire pour garder les moyens de productions en France (délocalisation) et faire aussi en sorte que les cerveaux aillent à l'étranger. Il va rester quoi à ce pauvre pays en dehors du tourisme (et encore vu l'accueil c'est pas gagné que cela continue) et des vieux politicards bourrés d'orgueil et de fric?
              • [^] # Re: Gains de performance

                Posté par (page perso) . Évalué à  2 .

                Ben des banques pour les touristes et les politicars !

                Comme quoi finalement c'est cohérent.
                • [^] # Re: Gains de performance

                  Posté par (page perso) . Évalué à  3 .

                  Non ça c'est perdu d'avance, on a déjà le monopole en Suisse (et au Liechtenstein) ... Et en plus vous risquez de finir sur une liste grise (souris ou anthracite) ou noire, expérience faites.

                  "It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell

              • [^] # Re: Gains de performance

                Posté par . Évalué à  2 .

                Trouves mieux comme argumentaire. L'argent des banques est un pret et garantie qui a déjà rapporté 1 milliard d'euro cette année. Tu veux que l'état prête les salaires des chercheurs ?

                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 liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

            • [^] # Re: Gains de performance

              Posté par . Évalué à  10 .

              L'absurdité c'est de former des chercheurs (ça coûte cher de former quelqu'un) et ne pas créer les postes de chercheur en nombre suffisant. L'absurdité c'est de surcharger les enseignant-chercheurs avec 192 heures équivalent-TD par an, les responsabilités pédagogiques et administratives et j'en passe, ce qui leur laisse bien peu de temps pour faire de la recherche. L'absurdité c'est de payer au lance-pierre des gens hautement qualifiés. L'absurdité c'est de leur donner des moyens de recherche totalement risibles (1000 euros de budget de recherche, la bonne blague, à peine de quoi remplacer son portable et le budget est vidé pour l'année¹).

              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 . Évalué à  4 .

                Bin justement dans le cas de la recherche en informatique, l'inria a quand même pas mal fait évolué les choses :
                - 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 . Évalué à  3 .

                  Salaire bas, c'est combien ? En net par mois, c'est plus facile de comparer (avec le nombre de mois).

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                  • [^] # Re: Gains de performance

                    Posté par . Évalué à  4 .

                    • [^] # Re: Gains de performance

                      Posté par . Évalué à  5 .

                      Ingénieur d'étude débutant: 23K€/an en brute.

                      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 liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                      • [^] # Re: Gains de performance

                        Posté par . Évalué à  2 .

                        Oui il faudrait voir le net.
                        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 . Évalué à  2 .

                          Cela a encore baissé :/ C'était à 30k€ en 2000, voir en 1990.

                          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                          • [^] # Re: Gains de performance

                            Posté par . Évalué à  3 .

                            En 2005-2007, c'était de l'ordre de 30-36 k€ bruts / an pour un ingé fraîchement sorti de l'école.
                        • [^] # Re: Gains de performance

                          Posté par . Évalué à  4 .

                          Les grosses boites ça paye vraiment beaucoup mieux que les SSII... Et généralement ceux qui recrutent les "hautes compétences" c'est pas vraiment les SSII. De plus ces profils sont en général mobiles (tu te déplaces la où la R&D est et tu ne cherches pas ta région).

                          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 . Évalué à  2 .

                            Les boîtes que tu cites ne sont pas des boîtes d'info industrielle. Et je ne parle pas d'«il y a pas si longtemps» mais du marché actuel. Il y a 1 à 2 ans 30 à 35k€ était courant pour un débutant. Quant à ce que vendent les écoles d'ingé c'est l'exception pas la généralité (qui fait beaucoup moins rêver). La concurrence de l'Inde et de la Chine se fait de plus en plus sentir...
                            • [^] # Re: Gains de performance

                              Posté par . Évalué à  1 .

                              C'est quoi le rapport entre les chiffres que tu sors sur l'info industrielle et ce dont on parlait avant ? Y'a quelques équipes d'automaticiens, mais c'est pas la foule non plus. Les employeurs potentiels des personnes dont on parle, ça reste les labs des grosses boites IT/hardware et les petites société innovantes IT. On compare les salaires pour un même boulot...

                              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 . Évalué à  3 .

                                C'est quoi le rapport entre les chiffres que tu sors sur l'info industrielle et ce dont on parlait avant ? Y'a quelques équipes d'automaticiens, mais c'est pas la foule non plus. Les employeurs potentiels des personnes dont on parle, ça reste les labs des grosses boites IT/hardware et les petites société innovantes IT. On compare les salaires pour un même boulot...

                                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 . Évalué à  5 .

                                  Si tu veux vraiment commencer à t'en mettre plein les fouilles il faut quitter la technique et passer dans le management.

                                  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 . Évalué à  3 .

                                    Dans un pays, où des boites réclament le droit d'utiliser le crédit d'impôt sur la recherche pour payer "l'innovation marketing" tu t'attends à quoi ?

                                    "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                          • [^] # Re: Gains de performance

                            Posté par . Évalué à  3 .

                            Si tu fais du java dans la banque ou l'assurance, cela paye chère. Si tu fais de l'embarqué ou de l'info industriel cela paye peu.

                            "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                        • [^] # Re: Gains de performance

                          Posté par . Évalué à  2 .

                          Je sais pas d'ou tu sors tes chiffres, mais il y a 4 ans le salaire d'embauche en ssii d'un débutant sur paris c'etait plutot 28/30k€ sans negocier (35/37 € avec nego).

                          A 10 ans d'experience, je pense que ca varie beaucoup plus suivant ton parcours...
                          • [^] # Re: Gains de performance

                            Posté par . Évalué à  1 .

                            Il y a 4 ans oui c'était effectivement ça. Aujourd'hui ce n'est plus ça...
                            Je parle d'info indus pas d'info de gestion qui rapporte bien plus.
              • [^] # Re: Gains de performance

                Posté par (page perso) . Évalué à  7 .

                L'absurdité, c'est d'avoir des chercheurs et de ne pas les embaucher.

                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 . Évalué à  1 .

                  tu attaques qui ? L'état ou les entreprises privés ? Je ne comprends pas ou tu veux en venir.

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: Gains de performance

                Posté par (page perso) . Évalué à  8 .

                Je confirme... pour apres ma these, j'avais deux options: rester en France, pour faire un postdoc (donc cdd) et etre paye moins que les secretaires du centre de recherche ou bien partir aux US et etre paye 5 fois plus... (oui, reellement 5 fois plus!).

                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 . Évalué à  2 .

                  Est-ce que tu connais le nombre de chercheur suisse pour un habitant ? C'est histoire d'avoir une idée de l'effort de chaque pays.

                  "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                  • [^] # Re: Gains de performance

                    Posté par . Évalué à  5 .

                    En Suisse il y a moins de chercheurs par habitant, en revanche ils investissent une fraction plus importante du PIB dans la recherche. Au final les chercheurs ont de biens meilleurs salaires et ont les moyens pour faire de la recherche. Quelques chiffres provenant de l'OCDE : http://www.oecd.org/dataoecd/49/45/24236156.pdf .
                    • [^] # Re: Gains de performance

                      Posté par . Évalué à  3 .

                      En gros, la situation serait de réduire les troupes en France, on est pas prêt de le faire...

                      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                    • [^] # Re: Gains de performance

                      Posté par . Évalué à  2 .

                      8 pour mille employés en France. 2.1% du pib, 204 484 chercheurs,41 436.2 m$, 0,20 m$/chercheur
                      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 liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                      • [^] # Re: Gains de performance

                        Posté par . Évalué à  4 .

                        J'ai ouïe-dire que le nombre de bourses offertes dans mon ex-DEA est en chute libre cette année. C'est une première phase à mon avis nécessaire si on veut diminuer un tant soit peu la pression au niveau des postes.

                        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 (page perso) . Évalué à  8 .

              Merci d'avoir posé la question :-), je vais essayer de faire aussi court que possible mais ce sera dur. Je parle en mon nom et seulement du monde de l'informatique (bien que cela doive s'étendre à d'autres domaines).

              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 . Évalué à  3 .

                Petite question dans la discussion, fort intéressante pour qui n'y connaît pas grand-chose (et vu de l'intérieur c'est toujours un regard particulier).

                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 (page perso) . Évalué à  5 .

                  C'est effectivement possible de cumuler pour certains corps de fonctionnaires, en particulier les (enseignants-)chercheurs, mais le principe général est l'interdiction de cumul, donc tout le monde ne peut pas.

                  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 . Évalué à  2 .

                Mais quel genre de solution tu vois à cout égal ?

                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 liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

                • [^] # Re: Gains de performance

                  Posté par (page perso) . Évalué à  2 .

                  Mais quel genre de solution tu vois à cout égal ?

                  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 (page perso) . Évalué à  3 .

                    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.

                    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 (page perso) . Évalué à  1 .

            A propos des ricains qui font du blé et des guignols au gouvernement et d'idees pour faire mieux:
            http://www.zeitgeistmovie.com
            http://www.thezeitgeistmovement.com
  • # Record

    Posté par (page perso) . Évalué à  10 .

    >>> 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

    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 . Évalué à  2 .

      Très beau boulot pour cette dépêche... Sincèrement, merci. Je promet de lire tous les liens que tu fournis dans l'article. Bravo aussi aux contributeurs de gcc, on comprend l'engouement soudain d'Intel pour gcc.

      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 . Évalué à  10 .

      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 ;-)

      Tant pis, on va se rabattre sur GNU/Hurd...

      OK, --> []
      • [^] # Re: Record

        Posté par . Évalué à  3 .

        Tu n'as pas le droit, il n'y a pas de rubrique science-fiction. Pourquoi pas MPlayer 1.0 stable ? :)
        Il y'a plus de chance que la France gagne la prochaine coupe de monde.
        • [^] # Re: Record

          Posté par . Évalué à  6 .

          Coupe du Monde ? Laquelle ? parce qu'en handball, ca ne me parrait pas inconcevable, vue que la France l'a gagnee il y a 3 mois a peine.

          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 (page perso) . Évalué à  2 .

            Ah au fait je voulais te dire bravo et félicitations. Avec la voiture qui semble très bonne et le petit Vettel vous avez vraiment un ticket gagnant.
            • [^] # Re: Record

              Posté par . Évalué à  3 .

              euh... Un peu d'explication serait le bien venue. Est-ce en rapport avec red bull ?

              "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

              • [^] # Re: Record

                Posté par (page perso) . Évalué à  4 .

                Oui. Imalip bosse pour l'écurie de F1 Red Bull qui a fait un magnifique doublé lors de la dernière course.
                • [^] # Re: Record

                  Posté par . Évalué à  5 .

                  Perso ce qui m'a le plus impressioné, c'est le calme de Vettel. Quand il a demandé par radio d'avoir un drapeau bleu pour la Force India devant lui, ca donnait l'impression qu'il était tranquilement assis dans son canapé, pas a moitié en aquaplanning a 150 km/h. J'ai des collegues plus nerveux que ca quand ils demandent un café.

                  Vivement le nouveau diffuseur...
              • [^] # Re: Record

                Posté par . Évalué à  4 .

                Comme l'a écrit patrick_g, Red Bull Racing est mon employeur. Donc apres une belle frayeur samedi a cause des arbres de transmission et beaucoup de tension dimanche matin, on a fait la fete tout l'apres-midi. Et on a eu droit au champagne et petits fours hier :)
          • [^] # Re: Record

            Posté par (page perso) . Évalué à  1 .

            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...

            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 (page perso) . Évalué à  5 .

      Si ça se trouve il y a une news sur la sortie de Duke Nukem Forever qui date de la première release date.
  • # Polyhèdre vs Polytope

    Posté par . Évalué à  3 .

    Pour la différence entre polyèdre et polytope ça dépend des écoles. On peut considérer les polytopes comme étant les polyhèdres bornés.

    Par exemple: http://en.wikipedia.org/wiki/Polyhedron#General_polyhedra
  • # Optimisations...

    Posté par (page perso) . Évalué à  2 .

    Donc si je comprends bien, les optimisations ne sont pas activés par défauts :(

    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 (page perso) . Évalué à  9 .

    Lorsque tu fait des grosses modifs comme cela, tu ne les mets pas obligatoire au début puis tu les rends pas défaut lorsqu'il y a du recul dessus.

    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 (page perso) . Évalué à  2 .

      Désolé, j'ai foiré ma réponse... C'était en réponse au post ci dessus de Christophe Merlet a propos Optimisations...

      S'il y a un admin dans le coin qui sais déplacer un commentaire, il est le bienvenue ;-)
    • [^] # Re: Jamais content

      Posté par (page perso) . Évalué à  6 .

      Tout à fait. D'ailleurs le compilateur est parfois le responsable mais pas le coupable dans cette histoire. J'ai vu des cas où des entreprises interdisent de compiler certains logiciels avec optimisations de peur que cela ne révèle un bug. La magie du C/C++ fait qu'une variable non initialisée voire un tableau un peu trop court ne sont pas toujours un soucis (jusqu'au jour où...). Mais si le compilateur se permet de réorganiser un peu trop (en particulier GRAPHITE peut-être vraiment très agressif), ça peut mettre très vite ce fragile équilibre par terre.

      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 . Évalué à  4 .

        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

        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 . Évalué à  6 .

          La dépendance entre registre est toujours respectée. Il n'y a pas d'utilisation de pseudo règle du style addition ou multiplication commutative.

          "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

          • [^] # Re: Jamais content

            Posté par . Évalué à  1 .

            C'est vrai, mais par exemple, un compilateur comme icc qui génère du code SSE assez facilement (ie du moment que le code est assez régulier pour le justifier, sans if ou while imbriqués) refusera systématiquement de générer ledit code SSE si on lui dit qu'on veut coller exactement à la norme IEEE 754 (ou son équivalent double précision). Il doit bien y avoir certaines hypothèses de commutativité donc (je passe sur le côté "sur x86 je stocke les nombres sur 80 bits en interne avant de les refoutre sur 64/32 bits") quand on demande au compilo d'optimiser.
        • [^] # Re: Jamais content

          Posté par . Évalué à  5 .

          Le fait que les instructions soient exécutées "out-of-order" ne signifie pas que le résultat de l'opération peut changer.
        • [^] # Re: Jamais content

          Posté par (page perso) . Évalué à  4 .

          Oui mais même en out-of-order on doit toujours attendre que les opérandes soient disponibles (en fait c'est même pour éviter de bloquer des instructions dont les opérandes sont déjà disponibles qu'on fait de l'out-of-order), les dépendances sont toujours respectées. Et il y a dépendance car le hardware ne fait pas d'hypothèse de commutativité. Par contre le compilateur, si on lui demande explicitement, le peut.
    • [^] # Re: Jamais content

      Posté par . Évalué à  1 .

      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.

      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 (page perso) . Évalué à  4 .

        Quand on y pense c'est quand même bien rare de tomber sur un bug de gcc (surtout les bugs du genre wrong code), si on prend en compte sa taille, sa complexité et la vitesse à laquelle il évolue, c'est surement un des logiciels libres qui a le moins de bugs !
  • # Distribs

    Posté par (page perso) . Évalué à  1 .

    Savez-vous quelles sont les distribs qui vont en disposer ?
    Je ne suis au courant que pour Fedora, qui va bien avoir GCC 4.4 pour la prochaine version (F11).
  • # BRAVO

    Posté par . Évalué à  1 .

    Pour tous le travail qu'ils ont fournis, merci beaucoup ;)
    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.