Le compilateur arrive à retomber, à 96 % sur du code monomorphique
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 conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
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 ?
Quelques remarques : "Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style : "La spécification 0.2 apporte des innovations importantes"
Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.". "certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien) "Non content"[...]
Et j'en passe.
Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.
[^] # Re: seul compilateur objet au monde à réaliser une analyse de flot ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Lisaac 0.12 en GPL v3. Évalué à 6.
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 conçois que Lisaac ne soit pas destiné à faire des briques de composants logiciels comme on pourrait le faire en Java ou autre, mais quand même : chercher à résoudre statiquement les appels polymorphique revient à partir du principe que le code est pas vraiment modulaire et/ou réutilisable sous forme de composant, bref codé "ala C".
Quand on voit le résultat au niveau perf, je me demande également où est l'intérêt, c'est quand même très relatif comme gain, surtout quand tu vois les contraintes sur les ressources nécessaire à la compilation.
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 ?
Quelques remarques :
"Le Garbage Collector de Lisaac est certainement un des ramasses-miettes les plus rapides à l'heure actuelle. Il est basé sur une architecture de type "Mark and Sweep" améliorée. En effet un "Mark and Sweep" classique parcourt tous les pointeurs, considérant n'importe quoi comme une référence possible. Le compilateur Lisaac génère un GC qui connait le type des objets qu'il gère, ce qui permet d'accélérer le marquage. Plus précisément, le marquage oublie volontairement les entiers, les caractères et les NATIVE_ARRAY "
Les GC modernes font également cela. D'ailleur les types "primitifs" (entier, etc.) sont généralement alloués sur la pile et non le tas, et ne sont donc pas du tout manipulés par le GC.
Sinon de manière beaucoup plus subjective : évite ce ton prétentieux dans tes journaux/dépêche, c'est vraiment lourd et ne donne pas spécialement une bonne image de Lisaac. Du style :
"La spécification 0.2 apporte des innovations importantes"
Des améliorations oui, des innovations faut pas exagérer, je vois pas ce qu'il y a d'innovant à "Le mot clé Expanded remplace *.".
"certainement un des ramasses-miettes les plus rapides à l'heure actuelle." (sans chiffre ni rien)
"Non content"[...]
Et j'en passe.
Un peu de modestie ne ferait pas de mal si vous voulez attirer un minimum d'attrait du milieu des logiciels libres. Là on a l'impression que tu fais un discours marketing pompeux.