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 :-)
[^] # 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 :-)