Si tu veux des références plus précises, peux-tu en dire plus sur ce que tu cherches ? (Quel genre de code ?)
Un langage de haut niveau qui va vite.
En général, les langages "rapides" laissent tout le boulot au codeur (asm, c, c++, fortran). C++ avec les templates proposent un moyen de mettre la complexité en library avec le prix d'une grosse difficulté et des messages d'erreur abscons (et donc des bugs). Ce genre de langage trop bas niveau fournis un code rapide sur une machine, mais qui peut être plus lent sur un autre (intel vs amd ou vs ARM), multicore ou pas, SIMD ou pas.
Les compilateurs C/C++ vont très loin dans les optimisations mais sont bridés par le langage lui-même : gestion mémoire basique et explicite (il faut une grande rigueur pour gérer des pools de mémoires et éviter la fragmentation), layout mémoire fixée dans les structures (optimisation par structures de tableaux au lieu de tableaux de structures impossible), code IEE754 immodifiable (sans changer le résultat final), pointeur trop générique qui nécessite un gros travail "d'analyse de vie" pour éviter l'aliasing. Le SIMD est de mieux en mieux géré, mais le multicore reste complexe sauf avec openMP. Par contre utiliser directement les GPU restent encore très expérimental : il suffit de voir la tronche du code opencl avec des string à envoyer au driver de la carte graphique !
Rust permet une bien meilleur gestion mémoire, mais compile moins bien que gcc. "tensor flow" semble pouvoir décrire du code rapide pour plusieurs architectures très différentes, mais cela n'est pas un langage.
On peut aussi parler des optimisations par propagation de constantes qui se limitent aux littéraux basiques, mais pas au 'string' (utile pour les regexp ou même un code SQL embarqué), et je ne parle pas de container constant (AST, lecture de fichier externe, genre configuration en XML, image embarquées ou même un DSL quelconque).
[^] # Re: Le cerveau n'est pas logique
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Un langage de haut niveau qui va vite.
En général, les langages "rapides" laissent tout le boulot au codeur (asm, c, c++, fortran). C++ avec les templates proposent un moyen de mettre la complexité en library avec le prix d'une grosse difficulté et des messages d'erreur abscons (et donc des bugs). Ce genre de langage trop bas niveau fournis un code rapide sur une machine, mais qui peut être plus lent sur un autre (intel vs amd ou vs ARM), multicore ou pas, SIMD ou pas.
Les compilateurs C/C++ vont très loin dans les optimisations mais sont bridés par le langage lui-même : gestion mémoire basique et explicite (il faut une grande rigueur pour gérer des pools de mémoires et éviter la fragmentation), layout mémoire fixée dans les structures (optimisation par structures de tableaux au lieu de tableaux de structures impossible), code IEE754 immodifiable (sans changer le résultat final), pointeur trop générique qui nécessite un gros travail "d'analyse de vie" pour éviter l'aliasing. Le SIMD est de mieux en mieux géré, mais le multicore reste complexe sauf avec openMP. Par contre utiliser directement les GPU restent encore très expérimental : il suffit de voir la tronche du code opencl avec des string à envoyer au driver de la carte graphique !
Rust permet une bien meilleur gestion mémoire, mais compile moins bien que gcc. "tensor flow" semble pouvoir décrire du code rapide pour plusieurs architectures très différentes, mais cela n'est pas un langage.
On peut aussi parler des optimisations par propagation de constantes qui se limitent aux littéraux basiques, mais pas au 'string' (utile pour les regexp ou même un code SQL embarqué), et je ne parle pas de container constant (AST, lecture de fichier externe, genre configuration en XML, image embarquées ou même un DSL quelconque).
"La première sécurité est la liberté"