Le problème de la discussion que nous avons c'est que tu ne veux pas accepter qu'un interpreteur, ou un langage avec un gros runtime (comme Haskell) peut donner de très bonnes performances.
Certains langages de haut niveau permettent d'exposer des optimisations qui ne sont pas possibles dans d'autres langages, comme la fusion en Haskell.
D'autres langages interprétés, comme python, java, php, lua, javascript, utilisent la compilation à la volée pour générer à l’exécution du code natif performant. Cela marche assez bien.
Alors oui, on ne battra surement jamais de l'assembleur optimisé à la main pour un problème précis par un spécialiste (bonjour le niveau du spécialiste), mais est-ce que cela vaut le coup ? Si avec un code robuste / portable / maintenable de 10 lignes tu fais "juste" 10% mois vite qu'un code de 200000 lignes non portable et que personne sans 4 PhD ne peux comprendre, est-ce que cela vaut le coup ?
[^] # Re: Haskell pour les nuls
Posté par Guillaum (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 5.
Le problème de la discussion que nous avons c'est que tu ne veux pas accepter qu'un interpreteur, ou un langage avec un gros runtime (comme Haskell) peut donner de très bonnes performances.
Certains langages de haut niveau permettent d'exposer des optimisations qui ne sont pas possibles dans d'autres langages, comme la fusion en Haskell.
D'autres langages interprétés, comme python, java, php, lua, javascript, utilisent la compilation à la volée pour générer à l’exécution du code natif performant. Cela marche assez bien.
Alors oui, on ne battra surement jamais de l'assembleur optimisé à la main pour un problème précis par un spécialiste (bonjour le niveau du spécialiste), mais est-ce que cela vaut le coup ? Si avec un code robuste / portable / maintenable de 10 lignes tu fais "juste" 10% mois vite qu'un code de 200000 lignes non portable et que personne sans 4 PhD ne peux comprendre, est-ce que cela vaut le coup ?