Ah ouai je viens de regarder le fameux lisaac.c c'est assez affreux à voir ^^.
En fait ce qu'on peut-dire aussi c'est que Lisaac dépend du compilateur C, et donc qu'un code en lisaac ne peut donner un programme plus rapide que ce que peut donner ce même compilateur C, quelque soit le langage à la base et les étapes de transcription.
Je pense donc que Lisaac est plus dépendant du compilateur C que du langage C lui même (qui est assez bas-niveau pour pouvoir être torturé dans tout les sens).
En fait c'est bien là où pèche la rhétorique : c'est qu'il doit être possible de faire à peu près tout en C (sans prendre en compte les critères de lisibilité, clarté, concision, maintenabilité...) donc forcément tout code, même s'il ne passait pas par l'étape C à la compilation comme Lisaac, pourrait avoir un équivalent en C aussi rapide que lui.
Conclusion : améliorons toujours gcc. :)
Je pense qu'il faut voir le code C produit par Lisaac comme une étape de précompilation : ce n'est déjà plus le source. Écrire un programme en C aussi rapide qu'un programme en C pourrait revenir à programmer un programme directement en binaire avec éditions de liens et tout et tout, et qui soit aussi rapide que celui en assembleur. c'est possible, certains l'ont fait peut-être, mais bon...
D'ailleurs, si j'ai bien, deux langages turing-complets doivent pouvoir être retranscrit dans l'un ou dans l'autres des langages avec un comportement final identique, à l'instruction près, où alors ils ne seraient pas turing-complets. Donc il est possible d'écrire un code Lisaac qui soit aussi lent qu'un code C. (qui veut écrire le compilateur ? XD).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Ton titre se démonte en 1 minute top chrono.
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Lisaac plus rapide que le C !. Évalué à 2.
En fait ce qu'on peut-dire aussi c'est que Lisaac dépend du compilateur C, et donc qu'un code en lisaac ne peut donner un programme plus rapide que ce que peut donner ce même compilateur C, quelque soit le langage à la base et les étapes de transcription.
Je pense donc que Lisaac est plus dépendant du compilateur C que du langage C lui même (qui est assez bas-niveau pour pouvoir être torturé dans tout les sens).
En fait c'est bien là où pèche la rhétorique : c'est qu'il doit être possible de faire à peu près tout en C (sans prendre en compte les critères de lisibilité, clarté, concision, maintenabilité...) donc forcément tout code, même s'il ne passait pas par l'étape C à la compilation comme Lisaac, pourrait avoir un équivalent en C aussi rapide que lui.
Conclusion : améliorons toujours gcc. :)
Je pense qu'il faut voir le code C produit par Lisaac comme une étape de précompilation : ce n'est déjà plus le source. Écrire un programme en C aussi rapide qu'un programme en C pourrait revenir à programmer un programme directement en binaire avec éditions de liens et tout et tout, et qui soit aussi rapide que celui en assembleur. c'est possible, certains l'ont fait peut-être, mais bon...
D'ailleurs, si j'ai bien, deux langages turing-complets doivent pouvoir être retranscrit dans l'un ou dans l'autres des langages avec un comportement final identique, à l'instruction près, où alors ils ne seraient pas turing-complets. Donc il est possible d'écrire un code Lisaac qui soit aussi lent qu'un code C. (qui veut écrire le compilateur ? XD).
ce commentaire est sous licence cc by 4 et précédentes