Posté par neil .
En réponse au journal Visiteurs en C++.
Évalué à 1.
Dernière modification le 25 avril 2013 à 23:29.
Haskell vu sa gestion de la mémoire à forcément des cas pathologiques.
C’est quoi le problème de la gestion de la mémoire en Haskell ?
J’en voit plusieurs, mais ils ont tous des solutions, et c’est pour ça que j’utilise pas mal Haskell pour faire du calcul multi-dimensionnel sur des données volumineuses. Tu veux peut-être parler du fait que ce soit un langage de haut-niveau avec mémoire collectée, et que les paramètres du collecteur influencent les performances ? Ça tombe bien, il existe des outils graphiques pour analyser ça. Tu veux peut-être dire que l’évaluation paresseuse (en pensant thunks) peut remplir la pile ? Ça tombe bien, les bang patterns facilitent grandement l’écriture de code strict. Tu veux peut-être aussi parler du fait que tout les types sont par défaut boxés et donc prennent donc plus de place ? Ça tombe encore pas mal, vu qu’il existe pas mal de bibliothèques de type Array qui peuvent unboxer les types (e.g. repa, vector), et on peut aussi le faire directement à la main.
Évidemment, ça suppose de pas mal d’avoir un poil de connaissance sur le langage (Haskell restant un gros langage avec pas mal de concepts fonctionnels à connaître), ses extensions, son implémentation, et ses bibliothèques. Mais c’est pareil pour avoir des trucs optimisés en C. L’avantage est d’avoir un code relativement sûr, concis, avec pas mal d’optimisations faites par le compilateur en collaboration avec les bibliothèques (fusion de boucles, parallélisation automatique, utilisation des GPUs).
[^] # Re: un inconvénient des templates
Posté par neil . En réponse au journal Visiteurs en C++. Évalué à 1. Dernière modification le 25 avril 2013 à 23:29.
C’est quoi le problème de la gestion de la mémoire en Haskell ?
J’en voit plusieurs, mais ils ont tous des solutions, et c’est pour ça que j’utilise pas mal Haskell pour faire du calcul multi-dimensionnel sur des données volumineuses. Tu veux peut-être parler du fait que ce soit un langage de haut-niveau avec mémoire collectée, et que les paramètres du collecteur influencent les performances ? Ça tombe bien, il existe des outils graphiques pour analyser ça. Tu veux peut-être dire que l’évaluation paresseuse (en pensant thunks) peut remplir la pile ? Ça tombe bien, les bang patterns facilitent grandement l’écriture de code strict. Tu veux peut-être aussi parler du fait que tout les types sont par défaut boxés et donc prennent donc plus de place ? Ça tombe encore pas mal, vu qu’il existe pas mal de bibliothèques de type Array qui peuvent unboxer les types (e.g. repa, vector), et on peut aussi le faire directement à la main.
Évidemment, ça suppose de pas mal d’avoir un poil de connaissance sur le langage (Haskell restant un gros langage avec pas mal de concepts fonctionnels à connaître), ses extensions, son implémentation, et ses bibliothèques. Mais c’est pareil pour avoir des trucs optimisés en C. L’avantage est d’avoir un code relativement sûr, concis, avec pas mal d’optimisations faites par le compilateur en collaboration avec les bibliothèques (fusion de boucles, parallélisation automatique, utilisation des GPUs).