Ce que j'appelle un plugin, c'est une bibliothèque respectant une certaine API afin d'etre utilisée par un programme donné (on code la bib specifiquement pour ce programme là) qui la chargera et l'utilisera. par exemple, on peut citer les modules apaches qui sont des plugins pour apache, les drivers linux le sont aussi d'une certaine manière pour le noyau. pour résumer, un plugin est fait specifiquement pour un programme, contrairement à la bibliothèque partagée. Certes les 2 donnent la meme chose en terme de structure (un .so classique sur les unix), mais en terme de compilation globale c'est très différent, car dans le cas de plugins on connait le programme qui utilisera le plugin, et donc on peut avoir les contextes. est-ce moins obscur ?
Qu'appelez vous maintenabilité ? extensibilité du code ? facilité de compréhension pour le maintenir et corriger les bugs ? gestion d'un projet ? outils de debugging ?
si c'est l'aspect maintenance du code, etant un langage de haut niveau gerant tout seul la mémoire, il aura une maintenabilité plus aisée qu'un langage de bas niveau.
Il faut distinguer 2 types de modularité : modularité dans ton architecture logicielle et modularité binaire.
La modularité de l'architecture logicielle est bien sûre possible. Un exemple typique, ce sont les collections dans Lisaac. Un type abstrait COLLECTION[E], et ensuite tu ne passes que par là. Donc si ton framework est constituée d'un ensemble de prototypes dont tu as le code source, tu peux utiliser ton framework de maniere normale, avec ses interfaces. Le compilo fera le boulot d'aller voir ce qu'il y a derriere, via son analyse de flot. Coté concepteur (vu que c'est ce coté là qui t'interesse visiblement), tu ne verras rien, tu coderas en boite noire comme d'habitude.
La modularité binaire (ou compilation séparée) dans un contexte d'optimisation globale est bien plus dure que dans un contexte d'optimisation locale (comme en Java ou autres), mais là aussi il y a 2 niveaux : la modularité type plugin, et la modularité type bibliothèque partagée.
La modularité type plugin parait plus simple. Avec Benoit on avait quelques idées qui, à la fin, permettraient de garder une optimisation globale même pour les plugins.
La modularité type bibliothèque partagée est bien plus complexe, car la bibliothèque est compilée sans connaitre les contextes d'utilisation de ses fonctions, donc out l'optimisation globale.
Ce sont clairement des domaines de recherche actuelle.
Il faut bien voir que Lisaac a été construit avec en tête l'idée de ne jamais prendre la solution de facilité. Pour la compilation séparée, il y a une solution simple si on ne prend pas cet engagement : on pond une interface en C, sans aucune optimisation sur les contextes etc, et l'autre prog se lie dessus. Probleme : on perd enormement des benefices de l'optimisation globale, alors que c'est ca qui permet d'avoir des perfs proches du C, voir meilleures dans certains cas. Rien ne dis qu'au final c'est ce qui sera fait, mais ca sera pas avant une longue analyse de ce qui est faisable.
Comme tous les projets de recherche, Lisaac cherche avant tout à être au top. Ca amène quelques contraintes, mais au final c'est parce que des gens prennent le temps de tout examiner que la JRE va un peu plus vite qu'un escargot et que Lisaac arrive à avoir une approche très haut niveau et de très bonnes perfs :-)
Pire que ça, le cas embêtant c'est à chaque fois que tu veux définir une vraie méthode virtuelle
Lisaac simule des schemas d'executions et trace tous les types possibles. Meme si les types dépendent de données, il ne sont pas créés en fonction des données (il faudrait pouvoir definir des prototypes à la volée, en runtime). Tu as juste différent types prédefinis (ceux que tu as créés pour ton programme) qui sont utilisés en fonction de celles-ci, donc tu peux tracer.
Il serait intéressant de voir des benchs portant sur ce point plutôt que sur la rapidité.
Si tu parles de l'heritage (sinon j'ai mal compris et je m'en excuse ;) ), des benchs avait été fait par Xavier Oswald pour tester ces points là. En gros il y avait un bench sur l'heritage horizontal (une classe A et 500 classes filles directes par exemple) et vertical.
Pour le vertical, il prenait un proto du bas de l'arbre et faisait 2.000.000 appels sur des methodes codées dans un des parents, quelconque (ca allait de 25 à 500 parents). Voilà les chiffres, tirés d'un log irc ^^ :
xoswald: c++ croit rapidement 1.4s , 2.1s, 2.6s etc..
xoswald: alors que lisaac reste pratiquement stationnaire
xoswald: 0.7s a 1s
xoswald: et java met deja 5.7s pour 25 parents
le probleme ici c'est la compilation séparée. En effet, Lisaac fait de l'optimisation globale. En gros, la lib est recompilée et reoptimisée pour repondre aux besoins specifiques de chaque prog. Notamment, une methode dans un code lisaac peut en generer plusieurs, en fonction des types possibles qui peuvent arriver lors de l'appel par le programme principal par exemple. Il n'y a pas de correspondance 1:1 entre une methode lisaac et une methode correspondante dans le C généré. En plus avec l'inlining il n'est meme pas dit que tu aies une fonction C pour ta fonction de la lib lisaac.
"Sachant que l'un des intérêts de la programmation objet est la réutilisation de composants et souplesse de déploiement/configuration associée, dans beaucoup de cas il est techniquement impossible de connaître à l'avance le type réellement instanciés (suffit de voir les patterns IoC par exemple) : ce 96% me paraît intuitivement largement sur-estimé."
Je dirais que ca depend du contexte. Dans le cadre d'une appli fortement orientée plugin, pour l'instant on ne peut rien dire, la compilation séparée n'est pas encore gérée. Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections. Mais sinon, vu que tu as à ta disposition tout ce qui va être executé, et donc tous les chemins possibles, tu peux specialiser toutes les fonctions pour les types qu'elles vont pouvoir recevoir, et ainsi éviter le polymorphisme. Le chiffre de 96% sort des stats du compilo. Si je prends ce qu'il me sort pour le bootstrap du compilo lui meme, voila ce qu'il me met :
Polymorphic call : 0.8% (1996/231824)
"Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?"
A priori c'est celui qui revient le plus dans les bench shootout[1], et en plus c'est celui qu'on trouve très largement sur toutes les distros Linux. À mes yeux c'est déjà pas mal comme justification, mais il y en a peut être d'autres ;)
* la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
- très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
- conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
- La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
(cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
- tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
* concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
* interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 1.
Qu'appelez vous maintenabilité ? extensibilité du code ? facilité de compréhension pour le maintenir et corriger les bugs ? gestion d'un projet ? outils de debugging ?
si c'est l'aspect maintenance du code, etant un langage de haut niveau gerant tout seul la mémoire, il aura une maintenabilité plus aisée qu'un langage de bas niveau.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
La modularité de l'architecture logicielle est bien sûre possible. Un exemple typique, ce sont les collections dans Lisaac. Un type abstrait COLLECTION[E], et ensuite tu ne passes que par là. Donc si ton framework est constituée d'un ensemble de prototypes dont tu as le code source, tu peux utiliser ton framework de maniere normale, avec ses interfaces. Le compilo fera le boulot d'aller voir ce qu'il y a derriere, via son analyse de flot. Coté concepteur (vu que c'est ce coté là qui t'interesse visiblement), tu ne verras rien, tu coderas en boite noire comme d'habitude.
La modularité binaire (ou compilation séparée) dans un contexte d'optimisation globale est bien plus dure que dans un contexte d'optimisation locale (comme en Java ou autres), mais là aussi il y a 2 niveaux : la modularité type plugin, et la modularité type bibliothèque partagée.
La modularité type plugin parait plus simple. Avec Benoit on avait quelques idées qui, à la fin, permettraient de garder une optimisation globale même pour les plugins.
La modularité type bibliothèque partagée est bien plus complexe, car la bibliothèque est compilée sans connaitre les contextes d'utilisation de ses fonctions, donc out l'optimisation globale.
Ce sont clairement des domaines de recherche actuelle.
Il faut bien voir que Lisaac a été construit avec en tête l'idée de ne jamais prendre la solution de facilité. Pour la compilation séparée, il y a une solution simple si on ne prend pas cet engagement : on pond une interface en C, sans aucune optimisation sur les contextes etc, et l'autre prog se lie dessus. Probleme : on perd enormement des benefices de l'optimisation globale, alors que c'est ca qui permet d'avoir des perfs proches du C, voir meilleures dans certains cas. Rien ne dis qu'au final c'est ce qui sera fait, mais ca sera pas avant une longue analyse de ce qui est faisable.
Comme tous les projets de recherche, Lisaac cherche avant tout à être au top. Ca amène quelques contraintes, mais au final c'est parce que des gens prennent le temps de tout examiner que la JRE va un peu plus vite qu'un escargot et que Lisaac arrive à avoir une approche très haut niveau et de très bonnes perfs :-)
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 3.
Lisaac simule des schemas d'executions et trace tous les types possibles. Meme si les types dépendent de données, il ne sont pas créés en fonction des données (il faudrait pouvoir definir des prototypes à la volée, en runtime). Tu as juste différent types prédefinis (ceux que tu as créés pour ton programme) qui sont utilisés en fonction de celles-ci, donc tu peux tracer.
Si tu parles de l'heritage (sinon j'ai mal compris et je m'en excuse ;) ), des benchs avait été fait par Xavier Oswald pour tester ces points là. En gros il y avait un bench sur l'heritage horizontal (une classe A et 500 classes filles directes par exemple) et vertical.
Pour le vertical, il prenait un proto du bas de l'arbre et faisait 2.000.000 appels sur des methodes codées dans un des parents, quelconque (ca allait de 25 à 500 parents). Voilà les chiffres, tirés d'un log irc ^^ :
[^] # Re: sonntag
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 2.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 4.
Je dirais que ca depend du contexte. Dans le cadre d'une appli fortement orientée plugin, pour l'instant on ne peut rien dire, la compilation séparée n'est pas encore gérée. Mais dans le cadre d'applis avec une conception Objet mais dont le binaire est "monolithique" tu peux parfaitement le prevoir, le cas embetant étant les collections. Mais sinon, vu que tu as à ta disposition tout ce qui va être executé, et donc tous les chemins possibles, tu peux specialiser toutes les fonctions pour les types qu'elles vont pouvoir recevoir, et ainsi éviter le polymorphisme. Le chiffre de 96% sort des stats du compilo. Si je prends ce qu'il me sort pour le bootstrap du compilo lui meme, voila ce qu'il me met :
Polymorphic call : 0.8% (1996/231824)
"Vous comparez les perfs avec gcc, très bien, mais celui-ci n'est pas réputé pour produire du code ultra-performant, pourquoi ne pas plutôt comparer avec le compilo Intel ?"
A priori c'est celui qui revient le plus dans les bench shootout[1], et en plus c'est celui qu'on trouve très largement sur toutes les distros Linux. À mes yeux c'est déjà pas mal comme justification, mais il y en a peut être d'autres ;)
[1] http://shootout.alioth.debian.org/gp4/benchmark.php?test=all(...)
[^] # Re: license et divers points techniques
Posté par tarlack . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 7.
* la syntaxe, c'est clairement une question de goût. Je viens du C++, et quand je suis passé à Lisaac, clairement au début c'est dur. En développant le mod pour Kate, je me suis rendu compte qu'en fait cette syntaxe est geniale, pour plusieurs raisons à mes yeux :
- très peu de règles de grammaire. En 10 minutes tu connais toute la syntaxe, même les finesses.
- conceptuelle et stricte : certes c'est abstrait et tranché, mais une fois maitrisé tu obtiens une expressivité sans faille. L'aspect tranché est une force, car le langage ne part pas n'importe où, meme si ca peut deplaire.
- La sémantique est nette car limitée à quelques trucs (pas besoin d'apprendre des centaines de notions), tout le reste est de la lib, donc il suffit de lire le code ou regarder la doc générée. Par exemple, le fait que les blocs soient à evaluation tardive t'assure que si tu as :
(cond1) && {cond2}, en lisant le slot '&&' de BOOLEAN (et surtout de TRUE et FALSE), tu es certain que le bloc {cond2} ne sera evalué que si cond1 est vraie. Je ne fais reference à aucune spec, à aucune norme, mais à la lib.
- tu n'es limité quasiment que par ton imagination. Tu veux avoir telle construction specifique à ton projet en cours ? en general tu peux la faire. C'est limite si tu ne crées pas un langage vraiment dédié à chaque projet, dans un formalisme qui est celui du Lisaac. En cela Lisaac se rapproche de meta-langages, mais cela n'engage que moi bien sûr.
* concurrence : pour l'instant le modèle COP n'est pas encore implémenté, mais tu peux voir à quoi ca ressemble dans le manuel, il y est décrit. Donc tous les tests sont mono-proc, meme si executés sur du multi-coeur/proc.
* interaction avec les bibliothèques : tu peux écrire directement du code C en lisaac, mais ca fout l'analyse de flot en l'air donc c'est pas genial. En plus il y a des restrictions si je me souviens bien, pour le typage. Après pour l'intégration de bibliothèques ayant leurs propres structures de données, tu peux le faire en ecrivant les prototypes associés à ces structures, avec la section Mapping pour les membres. Cela dit, il faudrait tester cela plus avant pour voir jusqu'où ca peut aller.