Perfs en Haskell

Ce sujet est la suite du topic http://www.developpez.net/forums/d78...t-quen-pensez/, afin d'éviter le HS au sein de celui-ci.

Oulà, celà fait beaucoup de réponses d'un seul coup :) !

Citation:

Globalement je trouve que le profil de toi qui se révèle dans ce fil, c'est que tu es trop attaché aux performances. Je ne sais pas qui tu es et ce que tu veux faire (il y a des gens qui font de l'embarqué et qui ont vraiment besoin d'optimiser les perfs au maximum au détriment du confort), mais il y a de fortes chances que tu t'en soucies trop et que ça risque de nuire à ta pratique. Prendre en compte les performances d'un langage quand on le choisit pour faire quelque chose, c'est normal, mais si c'est ton seul/principal critère de choix et que la lecture d'un shootout peut te faire changer d'avis sur les choix à prendre (sur des choses qui finalement se valent plus ou moins), je pense que tu as un problème.

Bluestorm, le souci c'est qu'en fait à la base je viens du milieu Python, qui est un langage merveilleux mais qui pour le moment est VRAIMENT lent pour certaines applications.
Seulement, le C c'est bien mais je préfère les langages haut-niveau (et je n'ai de toutes façons pas les compétences pour produire du code C optimisé) et le paradigme fonctionnel m'intéressait. C'est pourquoi je m'y suis lancé, mais en cherchant cette fois un langage qui était quand même plus rapide, pour pouvoir faire des choses différentes, tout en découvrant ce que la prog fonctionnelle pouvait m'apporter.
Ne crois pas que je sois obnubilé par les performances, je ne demande pas la vitesse du C, je cherche justement maintenant à apprendre un langage un tant soit peu rapide, et Haskell m'a maintenant l'air tout à fait convenable.
Je préfère un langage clair et réfléchi et un peu moins performant plutôt qu'un langage pour lequel le développement est lourd mais où l'on peut - but at what cost? - avoir des perfs exceptionnelles, ne te méprends pas.

Concernant le quicksort, je ne l'ai pas testé moi même, je ne fais que citer des trucs que j'ai vu sur le net.
Sinon, oui, je parle bien de cette version :
Code:

1 2 3 4 5 6 qsort [] = [] qsort (x:xs) = qsort elts_lt_x ++ [x] ++ qsort elts_greq_x where elts_lt_x = [y | y <- xs, y < x] elts_greq_x = [y | y <- xs, y >= x]
Oui, j'aurais utilisé 'partition' plutôt qu'une double list-comprehension.
Citation:
Envoyé par Jedai
Le développeur peut forcer une évaluation stricte où il le souhaite, dans ce cas GHC ne la rendra pas paresseuse (même si ça améliorait les performances, cas relativement fréquent pour ceux qui rajoutent trop d'annotation stricte). Ce que GHC fait, c'est analyser ton code pour voir où une évaluation stricte ne pourrait qu'améliorer les choses sans changer la sémantique, il est donc conservateur et n'optimise que s'il est sûr que ça ne ralentira pas ton programme et ne changera pas son sens. Un exemple simple :
Code:

1 2 3 4 5 sum :: [Int] -> Int sum = go 0 where go acc [] = acc go acc (x:xs) = go (acc+x) xs
Ce code est par défaut relativement plus inefficace que s'y attendrait un habitué des langages stricts avec TCO : en fait l'accumulateur n'est pas évalué à chaque appel de go (puisque ce n'est pas nécessaire) et accumule un "thunk" (une expression pas encore évaluée, en mémoire) d'une taille proportionnelle à la taille de la liste... Cela peut même entraîner un dépassement de pile lorsque le thunk doit finalement être évalué (puisqu'à ce stade il faut empiler un tas de (+) d'un seul coup, vu que (+) est strict).
Si tu actives les optimisations, GHC s'apercevra que faire (acc+x) immédiatement est une bonne idée à tout point de vue, donc il rendra go strict en ce paramètre (éliminant du même coup le risque de dépassement de pile et améliorant les performances considérablement).
Oui effectivement, c'est un exemple de ce type qui est utilisé par Real World Haskell pour introduire les 'seq', mais il n'était pas mentionné que ghc sait se rendre compte tout seul que l'évaluation stricte est mieux appropriée ici.

Citation:

Pas plus performant, soyons clair : on peut toujours faire plus performant avec du bas-niveau, mais à quel coût ? Un code Haskell sera souvent 10 à 20 fois plus petit que son équivalent en C, pour une différence de performance de seulement un facteur 2 à 5, et avec une fiabilité bien supérieure. Exceptionnellement, tu pourras avoir des codes aussi performant que du C, voir plus performant que du C utilisant naïvement les fonctions standards. De plus le temps dégagé signifie que tu as des chances de peaufiner les algorithmes, ce qui peut avoir des conséquences autrement importantes pour les performances.

J'ai en effet compris l'importance d'utiliser un maximum les foncions standard au lieu de faire sa "récursion maison", par exemple.

Je ne pense pas qu'Oz soit le meilleur langage d'assez loin pour découvrir le fonctionnel. Oz permet de découvrir plein de choses, mais sans doute pas spécifiquement le fonctionnel.

Tu devrais plutôt essayer Scheme, Ocaml ou Haskell, selon tes préférences (et il faut savoir que Scheme c'est pas typé donc c'est un autre genre de fonctionnel disons). J'ai une nette préférence pour OCaml pour quelqu'un qui n'a jamais fait de fonctionnel (parce que je trouve que l'évaluation paresseuse, qui est la principale difficulté de Haskell, n'est pas indispensable et que ça ne sert à rien de pousser les débutants à se casser la tête dessus , et aussi d'autres arguments que j'ai déjà exposé en long et en large sur le forum et que je suis prêt à aller rechercher si ça t'intéresse), mais si tu as déjà fait ton choix sur Haskell, c'est un bon langage aussi, il a aussi beaucoup de documentation pour les débutants, et n'hésite pas à poser des questions.

Oui, oui :) ça fait un moment (6 mois, mais j'ai fait un très grosse pause et j'ai repris au début des vacances) que mon choix s'est porté sur Haskell (initialement pour son côté "pur fonctionnel"), et je vais continuer dessus.
Je reviendrai sur le forum, pas d'inquiétude ^^