GHC est autant un interpréteur qu'un compilateur. Dans ton cas tu as compilé ton code Haskell en code natif. Cependant le code Haskell compilé avec GHC vient avec un "runtime" qui gère, entre autre, les entrée / sorties, l'allocation de mémoire, le ramasse miette, le parallélisme, ..., et presque tous ces points sont nécessaires même pour le plut petit programme.
Ce qui disqualifie Haskell dans des environnement aux ressources limités, mais dans un contexte plus classique, Haskell (et GHC) sont capable de générer du code natif assez performant. Dans mes applications habituelles, je suis, dans le pire des cas, 3x plus lent que du code de calcul C++ pure, mais souvent je suis dans les 10/15% plus lent. À voir si c'est suffisant ou pas.
Ceci étant dis, si tu veux continuer ton expérience Haskell, je te conseille de regarde "stack" qui s'occupera de la compilation / strip / gestion des dépendances pour toi.
[^] # 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.
GHC est autant un interpréteur qu'un compilateur. Dans ton cas tu as compilé ton code Haskell en code natif. Cependant le code Haskell compilé avec GHC vient avec un "runtime" qui gère, entre autre, les entrée / sorties, l'allocation de mémoire, le ramasse miette, le parallélisme, ..., et presque tous ces points sont nécessaires même pour le plut petit programme.
Ce qui disqualifie Haskell dans des environnement aux ressources limités, mais dans un contexte plus classique, Haskell (et GHC) sont capable de générer du code natif assez performant. Dans mes applications habituelles, je suis, dans le pire des cas, 3x plus lent que du code de calcul C++ pure, mais souvent je suis dans les 10/15% plus lent. À voir si c'est suffisant ou pas.
Ceci étant dis, si tu veux continuer ton expérience Haskell, je te conseille de regarde "stack" qui s'occupera de la compilation / strip / gestion des dépendances pour toi.