Je crois plutôt que le problème vient du compilateur C. Je ne sais pas si la norme le permet, mais le compilateur devrait être capable, si c'est possible, de transformer les algorithme récursifs les plus simples en algorithmes itératifs. Je pense notamment à la récursivité terminale.
C'est plutôt le problème des langages fonctionnels qui ne "connaissent pas la boucle", vu que la récursivité terminale, c'est comment transformer une boucle en appel récursif et vice-versa.
Ce n'est vraiment pas le but du compilateur C de chercher à optimiser la structure du programme.
Le but c'est quand même d'avoir un "macro assembleur" qui te garantisse que les séquences d'intructions écrites seront executées dans le même ordre (en dehors des optimisations qui généralement sont trés locale pré-chargement de registre pendant un long calcul pour que la donnée soit disponible au moment ou le décodeur en a besoin par exemple).
Pour moi, le C, c'est quand même le contrôle le plus direct sur ta machine après l'assembleur. Ce n'est pas fait pour être agréable, c'est fait pour faire ce que tu lui dit de faire (quoique des fois on se le demande :-)
La comparaison est mauvaise : la principale raison pour laquelle le C a gagné est que l'assembleur n'est pas portable et qu'un langage assembleur est censé avoir une durée de vie limitée.
C'est grosso modo ce qui se passe avec le C actuellement. Ton code n'est plus dépendant d'un processeur, mais d'un ensemble OS+librairies. Si sur du matos obscur ta librairie préférée n'est pas porté, tu peux toujours t'assoir sur la portabilité du C (sans aller jusque là, un programme écrit sur win3.1 en MFC, je ne crois pas qu'il soit trop portable).
Le plus drôle, c'est qu'on est un peu coincé avec l'architecture x86 parce que justement les constructeurs veulent garder cette sacro sainte comptabilité binaire, et en plus on a toujours le bios merdique remaquillé de 82 (à l'époque c'était peut être pas merdique, mais maintenant ça l'est!) avec tous les extensions un peu bidouille pour supporter le matériel moderne avec des spécifcation de 82.
(C'est un peu pareil avec les autres ISA).
Cela dit, il y a quand même un point qui me gêne. Comment justifier cette surenchère de couches alors qu'il y a de nombreuses tâches qui ne sont pas parallélisables
Pratiquement partout sur cette page, tout le monde que le top, c'est l'association ASM+C+(langage de haut niveau)+langage de script en même temps, ce sont des couches "conceptuelles", puisque in fine, c'est toujours une séquence de code ASM (de plus en plus grosse) qui est executée.
Tu devrais jeter un coup d'oeil sur ISAAC (j'avoue, à part la démo, je ne suis pas allé beaucoup plus loin pour l'instant).
En résumé, le principe est que tu conçois ton application en haut niveau, et le compilo ISAAC se "démerde" pour transformer le bousin en code C super optimisé (faisant sauter toutes les couches d'abstraction justement) difficilement lisible pour un être humain.
L'interêt, c'est que tu obtiens 95% de la performance d'un programme C écrit par LE génie du C et de l'algo qui a amoureusement optimisé en PalucheProcessing(TM) chaque ligne de code et chaque algo et qui a passé des heures à le faire.
Avec Lisaac, tu ne t'occupe plus de la mémoire, tu as pleins d'algo haut-niveau pour penser plus conceptuel, du coup tu es plus productif, et ton code généré n'aura pas d'erreurs techniques (gestion mémoire principalement). Evidemment si on te demande de coder 2+3 et que tu code 2+2, aucun langage ne peut t'aider :-)
On peut faire le // avec mon exemple de Fibonacci, ou le même code "naïf" est plus rapide en JAVA qu'en C, car la JVM stocke des données intermédiaires sans te le dire.
On peut toujours rendre le code C plus rapide, la question, c'est à quel prix et au bout de combien de temps ?
[^] # Re: Comment casser le mythe de rapidité de Fibonacci :-)
Posté par darkleon . En réponse à la dépêche Erlang/OTP R11B supporte les architectures multiprocesseur. Évalué à 3.
C'est plutôt le problème des langages fonctionnels qui ne "connaissent pas la boucle", vu que la récursivité terminale, c'est comment transformer une boucle en appel récursif et vice-versa.
Ce n'est vraiment pas le but du compilateur C de chercher à optimiser la structure du programme.
Le but c'est quand même d'avoir un "macro assembleur" qui te garantisse que les séquences d'intructions écrites seront executées dans le même ordre (en dehors des optimisations qui généralement sont trés locale pré-chargement de registre pendant un long calcul pour que la donnée soit disponible au moment ou le décodeur en a besoin par exemple).
Pour moi, le C, c'est quand même le contrôle le plus direct sur ta machine après l'assembleur. Ce n'est pas fait pour être agréable, c'est fait pour faire ce que tu lui dit de faire (quoique des fois on se le demande :-)
C'est grosso modo ce qui se passe avec le C actuellement. Ton code n'est plus dépendant d'un processeur, mais d'un ensemble OS+librairies. Si sur du matos obscur ta librairie préférée n'est pas porté, tu peux toujours t'assoir sur la portabilité du C (sans aller jusque là, un programme écrit sur win3.1 en MFC, je ne crois pas qu'il soit trop portable).
Le plus drôle, c'est qu'on est un peu coincé avec l'architecture x86 parce que justement les constructeurs veulent garder cette sacro sainte comptabilité binaire, et en plus on a toujours le bios merdique remaquillé de 82 (à l'époque c'était peut être pas merdique, mais maintenant ça l'est!) avec tous les extensions un peu bidouille pour supporter le matériel moderne avec des spécifcation de 82.
(C'est un peu pareil avec les autres ISA).
Pratiquement partout sur cette page, tout le monde que le top, c'est l'association ASM+C+(langage de haut niveau)+langage de script en même temps, ce sont des couches "conceptuelles", puisque in fine, c'est toujours une séquence de code ASM (de plus en plus grosse) qui est executée.
Tu devrais jeter un coup d'oeil sur ISAAC (j'avoue, à part la démo, je ne suis pas allé beaucoup plus loin pour l'instant).
En résumé, le principe est que tu conçois ton application en haut niveau, et le compilo ISAAC se "démerde" pour transformer le bousin en code C super optimisé (faisant sauter toutes les couches d'abstraction justement) difficilement lisible pour un être humain.
L'interêt, c'est que tu obtiens 95% de la performance d'un programme C écrit par LE génie du C et de l'algo qui a amoureusement optimisé en PalucheProcessing(TM) chaque ligne de code et chaque algo et qui a passé des heures à le faire.
Avec Lisaac, tu ne t'occupe plus de la mémoire, tu as pleins d'algo haut-niveau pour penser plus conceptuel, du coup tu es plus productif, et ton code généré n'aura pas d'erreurs techniques (gestion mémoire principalement). Evidemment si on te demande de coder 2+3 et que tu code 2+2, aucun langage ne peut t'aider :-)
On peut faire le // avec mon exemple de Fibonacci, ou le même code "naïf" est plus rapide en JAVA qu'en C, car la JVM stocke des données intermédiaires sans te le dire.
On peut toujours rendre le code C plus rapide, la question, c'est à quel prix et au bout de combien de temps ?