Si on essaye de coder la même chose directement en C, étant donné que le C n'a pas de concept d'héritage et que son préprocesseur n'est pas assez puissant, on est obliger de chercher la fonction toto() à l'étape 3 (runtime), ce qui signifie qu'on se traine des pointeurs de fonctions, et qu'on ne peut pas inliner. Autrement dit, si tu veux gérer l'héritage, le problème "trouver toto" doit être résolu à une étape, et le C ne permet pas de le résoudre à l'étape 2. Si tu le résouds à l'étape 3, tu perds en performance. Il ne reste que l'étape 1 pour optimiser.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Comment faire un langage plus rapide que C ?
Posté par Ontologia (site web personnel) . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 2.
En langage clair, dans un langage de bas niveau, un humain aura tendance à faire des choix couteux en performances pour que son code, et sa représentation du problème soit humainement compréhensible.
Un compilateur n'a pas ce problème.
Un compilateur d'un langage de haut niveau peut donc produire un code C bourré d'optimisations qui rendent le code illisible.
Dans la prochaine version de Lisaac sera intégré un algo (dont l'origine vient de Linuxfr : j'ai compris le problème en lisant un post de qqun expliquant que les accès random en mémoire avaient un coût énorme. https://linuxfr.org/comments/628360.html#628360 ainsi que tout le fil. J'en profite en passant pour remercier les auteurs) qui va optimiser la mémoire de façon à ce que tous les objets de petites tailles utilisé dans un flux local de code, se retrouvent sur la même ligne de cache (64 octets).
Le but est d'éviter au maximum au processeur d'aller chercher des données un peu partout en mémoire et d'avoir en permanence ce qu'il a besoin sous la main.
Ce genre d'optim peut se faire en C : il suffit de faire un gros malloc et de gérer ses pointeurs à la main, c'est à dire à par exemple décider que de l'ofset 12356 à l'ofset 12485, on a une chaine. Là on range les ofset de sorte à ce que les données utilisées dans une boucle par exemple, soient les unes à côtés des autres.
Par contre, je souhaite bon courage au type qui veut faire un décodeur mpeg2 en C, avec des optimisations de ce genre (il me semble que mplayer le fait un peu).
Voilà l'intérêt d'un compilateur de langage haut niveau (TImaniac, parce que les autres ont compris) : optimiser plein de choses qui seraient vite ingérables pour un humain.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker