Compilateur intelligent : proposition de l’Union Européenne et IBM Research

[Annaelle32]

Compilateur intelligent : proposition de l’Union Européenne et IBM Research
Le monde du développement des applications informatiques ne cesse chaque jour d’apporter son lot de nouveautés. Aujourd’hui, c’est IBM Research et l’Union Européenne qui proposent un compilateur intelligent livré en open source.

Sous l’égide de l’INRIA (Institut national de recherche en informatique et automatique), la conception de ce compilateur entre dans un grand projet de portées européennes, visant principalement à optimiser, d’une manière automatique, la compilation des codes sources écrits par différents développeurs. Le compilateur s’adresse notamment aux processeurs dont la configuration peut se prêter à une modification. Le principe s’appuie sur la technique de l’intelligence artificielle. Ce projet est également soutenu par l’Université d’Edimbourg et des équipes d’IBM Research.

Compilateur Milepost (Machine Learning for Embedded Programs Optimisation)
L’« intelligence » du compilateur Milepost se justifie surtout par le fait qu’il prend lui-même les initiatives pour décider des meilleurs traitements afin d’optimiser les performances des codes compilés. Ce même principe se rencontre également dans les procédures de factorisation relatives aux fonctions mathématiques ou dans les traitements des signaux audio ou vidéo. Autrement dit, le Milepost ramène le GCC en une suite d’outils.dont le training qui garantit l’analyse structurelle du programme à compiler et la recherche de la solution optimale. Cette démarche débouche, au final, sur un nouveau modèle qui intégrera Milepost GCC. Et, effectivement, les divers tests internes effectués attestent un gain avoisinant les 18%, sur les systèmes embarqués.

Milepost GCC 4.4.0
Ce compilateur particulier est donc désormais disponible dans sa version 4.4.0. Il se distingue également par le fait qu’il ne fait pas de distinctions sur les architectures cibles car l’ICI 2.0 (Interactive Compilation Interface) dont il est doté, lui permet d’agir au cœur même du GCC et de procéder aux modifications techniques adéquates, conformes à ses objectifs. Pour cela, l’ICI va se servir de la vaste base de connaissances (bases de données en intelligence artificielle) du CTC (Collective Tuning Center), lui-même constituant un autre volet du programme Milepost.

Avantages
Outre les bénéfices notables en termes de performances sur les traitements des ordinateurs ou même des téléphones portables, ce nouveau système entraîne, en plus, une baisse des coûts de l’énergie consommée car les processus prennent moins de temps à s’exécuter.

Bref, ce projet conjointement mené par IBM Research et l’Union Européenne, devrait ravir les développeurs et également les utilisateurs de leurs programmes. D’autant plus, qu’il opère indifféremment sur n’importe quelle architecture cible. Vivement donc les commentaires des premiers concernés : les développeurs ! Et si on commençait par...les vôtres?

Milepost GCC

Qu'en pensez-vous ?

[pseudocode]

Je pense qu'il y a déjà pas mal de boulot a faire du coté optimisation de code (approche de type LLVM) avant de se pencher sur l'optimisation du compilateur.

[gifffftane]

Cela me parait absolument génial, sauf que tant que c'est pas en java je peux pas trop approfondir, pas le temps : l'Union Européenne veut que je travaille pour gagner de l'argent, c'est la morale parait-il.

Attention toutefois que, selon le texte de la nouvelle, l'optimisation présentée me semble être une impasse ; l'optimisation vient toujours d'une association métier/algorithme, jamais de algorithme seul. Avec l'algorithme on optimise les benchmarks c'est à peu près tout. (mais comme les benchmarks sont des chiffres, donc considérés comme une réalité indiscutable, cela permet de justifier les investissements, donc les revenus, donc le travail, c'est vrai).

D'où l'importance des langages orienté métier.

[daniel06600]

Ne serre a rien du tout, car à mon avis l'électronique reprend du poil de la bête sur le software bas niveau et je pense que dans un très proche avenir nos microprocesseurs seront "auto compilateur" et donc ils seront alimentés directement par un langage de deuxième degré (un peu comme c, java, php etc...). Le deuxième point que je trouve très critique, c'est de laisser le pouvoir s'emparer à nouveau de l'informatique. L'expérience du passé semble renaître de ces cendres (Monopole, trust et compagnie...). Mais tout cela n'est que mon avis personnel.

[koala01]

Salut,

Envoyé par daniel06600

Ne serre a rien du tout, car à mon avis l'électronique reprend du poil de la bête sur le software bas niveau et je pense que dans un très proche avenir nos microprocesseurs seront "auto compilateur" et donc ils seront alimentés directement par un langage de deuxième degré (un peu comme c, java, php etc...).

Ce premier point est encore loin d'être acquis... pour deux raisons principales:

La première est qu'une instruction processeur est limitée en taille (bon an, mal an, nous pourrions l'estimer égale à la taille d'un registre)...

Les processeurs ont beau être de plus en plus puissants, et disposer de registres de plus en plus grands (64 bits deviennent presque la norme, du moins en informatique grand publique, mais pas encore forcément sur les pda et autres gsm qui permettent, aussi, de téléphoner), cette taille maximale reste une limite quant au type d'information qu'elle peut transmettre...

Si nous nous basons (vu que c'est la base des langages dits de troisième génération) sur des instructions de type "texte" (basées sur des chaines de caractères pour tout ce qui tient au noms de fonctions et de variables), nous sommes donc limités à... 8 caractères par instruction (plus les paramètres éventuels)

Au mieux, cela permettrait au processeur de comprendre des termes tels que for, while ou similaires, mais ca t'empêcherait d'écrire une fonction dont le nom est laFonctionInteressante, ce qui serait un sérieux bond en arrière du point de vue de la compréhension du code

La deuxième raison est que cela obligerait le programmeur à utiliser le langage pour la compréhension duquel le processeur a été écrit, et interdirait plus ou moins le fait d'utiliser un code écrit, par exemple, en C++ sur un processeur qui ne comprendrait que... le java...

Bref, alors que nous sommes dans une époque où la portabilité maximale est souvent de mise, cela nous ramènerait à une époque proche de celle des pionniers de l'informatique, où l'on écrivait encore le code à coup de 0 et de 1 (meme si, pour la cause, le code serait un peu plus compréhensible par l'humain )

Le deuxième point que je trouve très critique, c'est de laisser le pouvoir s'emparer à nouveau de l'informatique. L'expérience du passé semble renaître de ces cendres (Monopole, trust et compagnie...). Mais tout cela n'est que mon avis personnel.

L'intervention "étatique" (ou proche, vu que l'on parle ici de la CE) n'est pas forcément synonyme de retour aux temps (regrettés par certains) des grands monopoles et trusts...

On a vu récemment de nombreux gouvernements prendre des mesures pour "sauver" de grandes entreprises pourtant privées...

Ce qui n'empêche pas ces entreprises, même si les gouvernements demandent à ces entreprises d'avoir un minimum d'honnêteté en ne partageant pas les fonds donnés entre les actionnaires, de travailler en liberté

De plus, nous parlons donc d'un projet Open Source...

Il utilise *peut-être* une licence autre que GNU/GPL (quoi que, étant donné qu'il utilise semble-t-il gcc, nous pouvons estimer, à défaut d'aller lire les informations de licence du projet, qu'il l'utilise bel et bien), mais quoi qu'il en soit, une licence de se type assure la liberté d'utilisation, de distribution et de modification du code...

Nous sommes donc "simplement" face à un projet soutenu par la CE comme il en existe des milliers (tous domaines confondus)

[Alp]

Envoyé par pseudocode

Je pense qu'il y a déjà pas mal de boulot a faire du coté optimisation de code (approche de type LLVM) avant de se pencher sur l'optimisation du compilateur.

+1, à ceci près que dans leurs publis ils ont l'air d'avoir développé des techniques assez sympas. Faut voir si LLVM + Milepost ne pourrait pas donner un compilo assez intelligent

[Nebulix]

...les divers tests internes effectués attestent un gain avoisinant les 18%, sur les systèmes embarqués.

S'il n'y a que 18% à gagner, il vaut mieux utiliser sa réflexion à autre chose.

[pseudocode]

Envoyé par Alp

+1, à ceci près que dans leurs publis ils ont l'air d'avoir développé des techniques assez sympas. Faut voir si LLVM + Milepost ne pourrait pas donner un compilo assez intelligent

A ce propos, je viens de lire cela:

Posted by Miguel de Icaza on 16 Jul 2009 :

Mono from SVN is now able to use LLVM as a backend for code generation in addition to Mono's built-in JIT compiler.

This allows Mono to benefit from all of the compiler optimizations done in LLVM. For example the SciMark score goes from 482 to 610.

This extra performance comes at a cost: it consumes more time and more memory to JIT compile using LLVM than using Mono's built-in JIT, so it is not a solution for everyone.

Long running desktop applications like Banshee and Gnome-Do want to keep memory usage low and also would most likely not benefit from better code generation. Our own tests show that ASP.NET applications do not seem to benefit very much (but web apps are inherently IO-bound).

But computationally intensive applications will definitely benefit from this. Financial and scientific users will surely appreciate this performance boost

[ijk-ref]

Envoyé par koala01

La deuxième raison est que cela obligerait le programmeur à utiliser le langage pour la compréhension duquel le processeur a été écrit, et interdirait plus ou moins le fait d'utiliser un code écrit, par exemple, en C++ sur un processeur qui ne comprendrait que... le java...

Euh... tu connais pas CLI !?

[koala01]

Envoyé par ijk-ref

Euh... tu connais pas CLI !?

Heu...Tu sais que c'est tout sauf portable

[ijk-ref]

Envoyé par koala01

Heu...Tu sais que c'est tout sauf portable

T'entends quoi par "portable" ? En tous cas plus "portable" que ça :

La spécification définit un environnement qui permet d'utiliser de nombreux langages de haut niveau sur différentes plates-formes sans nécessité de réécrire le code pour des architectures spécifiques

[deadalnix]

Non mais justement, la tu écris un code et le compilo te sort du compilé aux petit oignon pour ta plateforme.

Une autre plateforme => Go ninja, on recompile.

Sinon, je ne comprend pas pourquoi vous opposez ces améliorations aux amélioration de type LLVM. Les deux approches ne s'excluent pas l'une l'autre a priori.

[pseudocode]

Envoyé par deadalnix

Non mais justement, la tu écris un code et le compilo te sort du compilé aux petit oignon pour ta plateforme.

Une autre plateforme => Go ninja, on recompile.

Sinon, je ne comprend pas pourquoi vous opposez ces améliorations aux amélioration de type LLVM. Les deux approches ne s'excluent pas l'une l'autre a priori.

Non, elle ne s'excluent pas l'une l'autre. Mais je pense qu'une petite amélioration au niveau code (LLVM) permet d'avoir des effets bien plus importants qu'une amélioration complexe au niveau du langage machine.

Par exemple paralléliser du code, ou pré-calculer des constantes, ...