En toute humilité je n'ai pas le niveau intellectuel suffisant pour avoir saisi, ne serait-ce que le sens général, du concept de fusion en Haskell à la lecture du lien. Certes l'exemple qui y est donné avec le module Data.Text me parle un peu plus car c'est pile dans le domaine que doit traiter un moteur de blog.
Mais, à ce que je suppose, on n'est plus dans le domaine du langage de programmation mais dans celui de l'optimisation par le compilateur. En ce cas, quel que soit le langage compilable en natif la question se pose à l'identique. Alors, toujours si j'ai bien compris, les langages compilables permettent usuellement d'ajouter des directives de compilation ; ainsi en fortran où l'on peut déclarer une fonction comme étant "pure", "elemental" ou même "impure" (et aussi, maintenant, la gestion du parallélisme).
Que Haskell soit tout à la fois un langage de programmation et un compilateur est une nouvelle donne. Et elle est intéressante car elle peut intégrer plus finement la phase d'optimisation. Le compilateur Fortran que j'utilise est GCC et suit à peu près le même processus que C dans le sens où il converti le source en Gimple puis en assembleur. Il s'en suit que l'on doit posséder de bonne base théorique en informatique pour produire un exécutable performant. Et ensuite c'est l'édition de lien et, là encore, le bagage intellectuel requis est assez lourd (du moins pour ma petite tête !). J'appréhende le jour où je devrai me plonger dans l'apprentissage du LTO...
Le gros avantage des interpréteurs est qu'ils lissent toutes ces contingences puisqu'ils créent leur univers et donc les règles qui leur sont propre ; c'est excellent pour la portabilité d'un logiciel. A contrario, en natif, la compilation et l'édition doivent être ajustées à la machine.
Donc, je suis (et je l'étais déjà avant) d'accord avec toi à 100% sur le fait qu'un langage interprété peu s'approcher de la performance globale d'un langage compilé non optimisé pour une machine donnée. Et je suis tout à fait conscient que l'optimisation "aux petits oignons" n'est guère portable et nécessite tout autant du temps et le bagage intellectuel adéquat. Et je suis pleinement d'accord qu'une perte de 10% de performance est acceptable et que c'est immensément compensé par la facilité de mise en production dans les délais les plus courts. Et je n'ignore pas non plus que absolument tous les exécutables sous Linux tournent sous l'interpréteur ELF...
Là où j'ai un souci avec les interpréteurs en général (mais je n'ai jamais essayé Haskell donc je n'ai pas d'opinion à son sujet) c'est quand on a à générer un très grand nombre de fichiers en lecture / écriture. En ce cas l'interpréteur doit sortir de son monde intérieur pour se tourner vers le système d'exploitation et il me semble bien que c'est une situation où les performances s'effondrent. (Là encore, je suis un modeste autodidacte et peut-être que je dis des sottises.) Alors oui, la parade consiste à charger en mémoire vive lesdits fichiers et les recracher en bloc après traitement. Mais ce n'est pas toujours possible s'ils sont très volumineux et nombreux. En ce cas, on tombe dans un traitement séquentiel par lot et la performance tombe à cause du double traitement des I/O (une fois dans l'interpréteur et l'autre dans l'appel système sous-jacent).
Dans le cas de mon moteur de blog, je me suis fixé comme règle que le nombre de fichiers de données traitables ne doit être limité que par le système de fichier. Ou, à tout le moins, de générer les billets de blog (stockés en fichiers plats) sur la base d'un post par jour pendant 30 ans. Ce qui fait dans les 10950 fichiers individuels pour les données. Et je fais mes tests sur cette base en générant un blog où toutes les pages contiennent la version HTML de la GPL. Sachant qu'un billet de blog a sa déclinaison en version imprimable, qu'il y a les pages d'indexation année par année et mois par mois, on arrive à nombre de fichiers à générer conséquent. Autre règle que je me suis fixé : une empreinte mémoire minimale. aussi n'ai-je en mémoire globale durant le traitement que les métadonnées des billets limitées aux dates et titres.
Ceci étant dit, je le répète, je n'ai pas d'opinion sur Haskell en particulier et je suis dans le flou le plus total quant à la performance des interpréteurs en lectures/écritures massives. Je ne sais même pas s'il est procédé des essais comparatifs sur des PC familiaux.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
En toute humilité je n'ai pas le niveau intellectuel suffisant pour avoir saisi, ne serait-ce que le sens général, du concept de fusion en Haskell à la lecture du lien. Certes l'exemple qui y est donné avec le module Data.Text me parle un peu plus car c'est pile dans le domaine que doit traiter un moteur de blog.
Mais, à ce que je suppose, on n'est plus dans le domaine du langage de programmation mais dans celui de l'optimisation par le compilateur. En ce cas, quel que soit le langage compilable en natif la question se pose à l'identique. Alors, toujours si j'ai bien compris, les langages compilables permettent usuellement d'ajouter des directives de compilation ; ainsi en fortran où l'on peut déclarer une fonction comme étant "pure", "elemental" ou même "impure" (et aussi, maintenant, la gestion du parallélisme).
Que Haskell soit tout à la fois un langage de programmation et un compilateur est une nouvelle donne. Et elle est intéressante car elle peut intégrer plus finement la phase d'optimisation. Le compilateur Fortran que j'utilise est GCC et suit à peu près le même processus que C dans le sens où il converti le source en Gimple puis en assembleur. Il s'en suit que l'on doit posséder de bonne base théorique en informatique pour produire un exécutable performant. Et ensuite c'est l'édition de lien et, là encore, le bagage intellectuel requis est assez lourd (du moins pour ma petite tête !). J'appréhende le jour où je devrai me plonger dans l'apprentissage du LTO...
Le gros avantage des interpréteurs est qu'ils lissent toutes ces contingences puisqu'ils créent leur univers et donc les règles qui leur sont propre ; c'est excellent pour la portabilité d'un logiciel. A contrario, en natif, la compilation et l'édition doivent être ajustées à la machine.
Donc, je suis (et je l'étais déjà avant) d'accord avec toi à 100% sur le fait qu'un langage interprété peu s'approcher de la performance globale d'un langage compilé non optimisé pour une machine donnée. Et je suis tout à fait conscient que l'optimisation "aux petits oignons" n'est guère portable et nécessite tout autant du temps et le bagage intellectuel adéquat. Et je suis pleinement d'accord qu'une perte de 10% de performance est acceptable et que c'est immensément compensé par la facilité de mise en production dans les délais les plus courts. Et je n'ignore pas non plus que absolument tous les exécutables sous Linux tournent sous l'interpréteur ELF...
Là où j'ai un souci avec les interpréteurs en général (mais je n'ai jamais essayé Haskell donc je n'ai pas d'opinion à son sujet) c'est quand on a à générer un très grand nombre de fichiers en lecture / écriture. En ce cas l'interpréteur doit sortir de son monde intérieur pour se tourner vers le système d'exploitation et il me semble bien que c'est une situation où les performances s'effondrent. (Là encore, je suis un modeste autodidacte et peut-être que je dis des sottises.) Alors oui, la parade consiste à charger en mémoire vive lesdits fichiers et les recracher en bloc après traitement. Mais ce n'est pas toujours possible s'ils sont très volumineux et nombreux. En ce cas, on tombe dans un traitement séquentiel par lot et la performance tombe à cause du double traitement des I/O (une fois dans l'interpréteur et l'autre dans l'appel système sous-jacent).
Dans le cas de mon moteur de blog, je me suis fixé comme règle que le nombre de fichiers de données traitables ne doit être limité que par le système de fichier. Ou, à tout le moins, de générer les billets de blog (stockés en fichiers plats) sur la base d'un post par jour pendant 30 ans. Ce qui fait dans les 10950 fichiers individuels pour les données. Et je fais mes tests sur cette base en générant un blog où toutes les pages contiennent la version HTML de la GPL. Sachant qu'un billet de blog a sa déclinaison en version imprimable, qu'il y a les pages d'indexation année par année et mois par mois, on arrive à nombre de fichiers à générer conséquent. Autre règle que je me suis fixé : une empreinte mémoire minimale. aussi n'ai-je en mémoire globale durant le traitement que les métadonnées des billets limitées aux dates et titres.
Ceci étant dit, je le répète, je n'ai pas d'opinion sur Haskell en particulier et je suis dans le flou le plus total quant à la performance des interpréteurs en lectures/écritures massives. Je ne sais même pas s'il est procédé des essais comparatifs sur des PC familiaux.