Le C est un peu une abstraction du langage machine des processeurs. Quand on code en C, on obtient naturellement un code très performant pour des logiciels qui se prêtent au langage C.
Du coup tu as un algorithme très simple pour contrer ce que tu dis :
tu prend le programme optimal dont tu parles, écrit en LISP, et tu joue les algorithmes de compilation utilisés dans SBCL en écrivant du C dont tu sais qu'il va produire le code natif générer par SBCL, en utilisant au passage des optimisations qui ne peuvent s'appliquer que dans le cas de l'algorithme à implémenter, s'il y en a.
Tu obtiens alors, soit un programme équivalent si tu n'as trouvé aucune optimisation supplémentaire, soit un programme plus rapide. La vitesse est donc supérieure ou égale.
Autre argument, le LISP est une bonne abstraction de la LISP machine, pas d'un processeur impératif, non fonctionnel. Avec un processeur classique, un appel de fonction coute très cher.
Etant développeur C avec un minimum d'expérience, je peux te garantir qu'un développeur C aguéri raisonne vraiement comme cela, quand il n'a pas d'autre choix que d'utiliser C.
Evidemment, cela pose le problème qu'une même personne doit maîtriser tous les tenants et aboutissants du compilateur LISP. L'intérêt d'utiliser directement LISP, c'est de gagner du temps à ne pas réinventer la roue à chaque fois (ou beaucoup moins) et d'avoir un code plus lisible à la fin.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...
[^] # Re: pourquoi le lip
Posté par iug . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 2.
Du coup tu as un algorithme très simple pour contrer ce que tu dis :
tu prend le programme optimal dont tu parles, écrit en LISP, et tu joue les algorithmes de compilation utilisés dans SBCL en écrivant du C dont tu sais qu'il va produire le code natif générer par SBCL, en utilisant au passage des optimisations qui ne peuvent s'appliquer que dans le cas de l'algorithme à implémenter, s'il y en a.
Tu obtiens alors, soit un programme équivalent si tu n'as trouvé aucune optimisation supplémentaire, soit un programme plus rapide. La vitesse est donc supérieure ou égale.
Autre argument, le LISP est une bonne abstraction de la LISP machine, pas d'un processeur impératif, non fonctionnel. Avec un processeur classique, un appel de fonction coute très cher.
Etant développeur C avec un minimum d'expérience, je peux te garantir qu'un développeur C aguéri raisonne vraiement comme cela, quand il n'a pas d'autre choix que d'utiliser C.
Evidemment, cela pose le problème qu'une même personne doit maîtriser tous les tenants et aboutissants du compilateur LISP. L'intérêt d'utiliser directement LISP, c'est de gagner du temps à ne pas réinventer la roue à chaque fois (ou beaucoup moins) et d'avoir un code plus lisible à la fin.
Le combat du "je suis plus rapide" ne s'applique pas aux langages de haut niveau : leur intérêt réside dans le gain de temps, de maintenance, ....
Un programme bien conçu qui ferait 100000 lignes de Lisp ou de Prolog ou de Caml ou autre n'est en fait pas possible à écrire en C. Il faudrait des dizaines de millions de lignes de code, le code ne serait pas maintenable,...