c'est quoi qui bouffe de l'espace dans Lisaac ?
D'après ce que j'ai compris de ce que m'a expliqué Benoit, c'est le graphe de dépendance, ou graphe de flot qui prend de la place en mémoire.
Faut pas oublier que Lisaac est pas un compilateur procédural mais objet.
En procédural, tu as deux dimensions : la variable globale et la variable locale.
En objet tu as la variable globale, locale, et l'objet en question (on peut instancier autant de fois qu"on veut), ça monte donc très très vite (les sous graphes se dupliquent très vite...).
Lisaac est un compilateur qui traduit ton code dans un langage élémentaire rassemblant , si je ne me trompe pas, les primitives suivantes :
Read
Write
Switch (branchement)
soustraction
multiplication
division
and
or
test =
>
Avec ça, il optimise tout, et reconstitue du C...
Sachant que la conditionnelle est défini dans la librairie pour être justement traduite dans ce mini langage, tu imagines bien que la granulité étant très fine, on arrive très vite à des graphes très volumineux. Prenons un simple
a,b : STRING;
a := STRING.create 64;
b := STRING.create 64;
a := "Esope reste ici".to_string;
b := " et se repose\n".to_string;
(a+b).print;
Là dedans, à part la primitive print, et les chaînes qu'on retrouvera tels quels dans le source C produit, ca fait déjà un beau graphe quand tu utilises des primitives aussi fines que celles décrites plus haut...
STRING est déjà un gros objet qui utilise lui même une cascade de code (gestion mémoire, initialisation, opération +, etc...).
Ya la gestion des contrats qui prend énormément de place aussi, car les contrats sont propagés dans tout le code.
Quand au moteur d'inférence, il fut implémenté (en 2001), mais mangeait 4 Go de mémoire pour 500 lignes de code (hors librairie), ils arrivaient à faire planter le calculateur du Loria avec, à l'époque (vers 2001).
C'est en réduisant la profondeur de l'analyse de flot que Lisaac est devenu réalité.
Un des principaux travaux de recherche des prochains mois de notre ami (maintenant qu'il a enfin un poste) va consister à réimplémenter une analyse profonde dans le compilateur, avec pour but d'améliorer la sécurité et la prise en charge des contrats, prouver le langage interne, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Compilation lente <=> Analyse de flot
Posté par Ontologia (site web personnel) . En réponse à la dépêche Lancement du projet GlobalGCC. Évalué à 6.
D'après ce que j'ai compris de ce que m'a expliqué Benoit, c'est le graphe de dépendance, ou graphe de flot qui prend de la place en mémoire.
Faut pas oublier que Lisaac est pas un compilateur procédural mais objet.
En procédural, tu as deux dimensions : la variable globale et la variable locale.
En objet tu as la variable globale, locale, et l'objet en question (on peut instancier autant de fois qu"on veut), ça monte donc très très vite (les sous graphes se dupliquent très vite...).
Lisaac est un compilateur qui traduit ton code dans un langage élémentaire rassemblant , si je ne me trompe pas, les primitives suivantes :
Read
Write
Switch (branchement)
soustraction
multiplication
division
and
or
test =
>
Avec ça, il optimise tout, et reconstitue du C...
Sachant que la conditionnelle est défini dans la librairie pour être justement traduite dans ce mini langage, tu imagines bien que la granulité étant très fine, on arrive très vite à des graphes très volumineux. Prenons un simple
a,b : STRING;
a := STRING.create 64;
b := STRING.create 64;
a := "Esope reste ici".to_string;
b := " et se repose\n".to_string;
(a+b).print;
Là dedans, à part la primitive print, et les chaînes qu'on retrouvera tels quels dans le source C produit, ca fait déjà un beau graphe quand tu utilises des primitives aussi fines que celles décrites plus haut...
STRING est déjà un gros objet qui utilise lui même une cascade de code (gestion mémoire, initialisation, opération +, etc...).
Ya la gestion des contrats qui prend énormément de place aussi, car les contrats sont propagés dans tout le code.
Quand au moteur d'inférence, il fut implémenté (en 2001), mais mangeait 4 Go de mémoire pour 500 lignes de code (hors librairie), ils arrivaient à faire planter le calculateur du Loria avec, à l'époque (vers 2001).
C'est en réduisant la profondeur de l'analyse de flot que Lisaac est devenu réalité.
Un des principaux travaux de recherche des prochains mois de notre ami (maintenant qu'il a enfin un poste) va consister à réimplémenter une analyse profonde dans le compilateur, avec pour but d'améliorer la sécurité et la prise en charge des contrats, prouver le langage interne, etc...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker