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 [...]
C'est un mécanisme qui permet de supprimer des opérations intermédiaires lors d'un calcul. Ainsi un calcul décrit avec de nombreuses structures de donnée temporaires peut au final ne rien allouer.
Que Haskell soit tout à la fois un langage de programmation et un compilateur est une nouvelle donne.
Pour différents langages, il existe différents moyen de faire exécuter le programme par un processeur. On peut interpréter ce code, ou le compiler en natif pour la machine ciblée. Pour de nombreux langage, il existe autant d’interpréteur que de compilateur. Il existe des interpréteurs Haskell et des compilateurs Haskell, il existe des interpréteurs C et des compilateurs C. En fait, tous les langages qui ont un frontend pour LLVM ont un interpréteur et un compilateur qui s'appelle LLVM. Ainsi, il existe des interpréteurs pour C, C++, Fortran, ...
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 ;
Je ne comprend rien 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)
Tu as bien compris que Haskell n'est qu'un langage qui peut être compilé ou interprété en fonction des besoins ?
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.
Quand tu lis un fichier, que ce soit en python, en Haskell, ou en C, ton dénominateur commun c'est l'appel système et à peu de choses près, tes performances dépendent de cet appel système.
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).
Mais l’interpréteur ne fait RIEN de plus que faire un appel système. Il y a des fois une surcouche pour réaliser l'appel, mais celle-ci ne coûte souvent presque rien comparé au coût de l'appel système.
Tu as des benchmark à l'appui pour ce que tu dis ? Je serais vraiment interessé.
[^] # 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é à 6.
C'est un mécanisme qui permet de supprimer des opérations intermédiaires lors d'un calcul. Ainsi un calcul décrit avec de nombreuses structures de donnée temporaires peut au final ne rien allouer.
Pour différents langages, il existe différents moyen de faire exécuter le programme par un processeur. On peut interpréter ce code, ou le compiler en natif pour la machine ciblée. Pour de nombreux langage, il existe autant d’interpréteur que de compilateur. Il existe des interpréteurs Haskell et des compilateurs Haskell, il existe des interpréteurs C et des compilateurs C. En fait, tous les langages qui ont un frontend pour LLVM ont un interpréteur et un compilateur qui s'appelle LLVM. Ainsi, il existe des interpréteurs pour C, C++, Fortran, ...
Je ne comprend rien là.
Tu as bien compris que Haskell n'est qu'un langage qui peut être compilé ou interprété en fonction des besoins ?
Quand tu lis un fichier, que ce soit en python, en Haskell, ou en C, ton dénominateur commun c'est l'appel système et à peu de choses près, tes performances dépendent de cet appel système.
Mais l’interpréteur ne fait RIEN de plus que faire un appel système. Il y a des fois une surcouche pour réaliser l'appel, mais celle-ci ne coûte souvent presque rien comparé au coût de l'appel système.
Tu as des benchmark à l'appui pour ce que tu dis ? Je serais vraiment interessé.