Les tests sont intéressants, même si il faut les prendre avec des pincettes. Ca donne un aperçu du potentiel.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 3.
Un autre indice que le C n'est pas la panacée est arrivé par python. La version .NET de python (IronPython) est arrivé soit à égalité, soit a été légèrement plus rapide que la version en C de l'interpréteur python sur une série de benchmark officiels.
Ca veut bien dire que on peut faire plus vite que du C. Je pense que c'est vrai en particulier sur des projets complexes, où le compilateur peut prendre une décision plus informée que l'être humain.
Sinon pour lisaac, si je me souviens bien, lisaac analyse l'ensemble du programme pour en optimiser tous ses aspects. Ca veut dire que sur un petit programme, il peut enlever des contraintes que le programmeur en C garderait. Après, sur un très gros programme, on peut imaginer qu'il pourra enlever beaucoup moins de contraintes et donc aura plus de mal à générer du code performant. Ou peut-être au contraire, il découvrira des optimisations inaperçues à la vue du programmeur.
L'absence de notion de bibliothèque est aussi un problème. Si j'ai bien compris les dernières explications sur le sujet, la notion de bibliothèque va justement réduire les capacités d'optimisation de lissac, puisque celui-ci ne pourra pas optimiser la partie du code externe.
Si tout le monde migrait a lissac, ce serait un peu comme passer à une gentoo en stage 1. Un truc de geek quoi.