Langage fonctionnel le plus rapide

Je me suis récemment plongé dans la programmation fonctionnelle, en particulier Haskell et F #, plus avant. Après quelques recherches sur Google, je n'ai pas pu trouver de comparaison de référence des langages fonctionnels les plus importants (Scala, F # etc.).

Je sais que ce n'est pas nécessairement juste pour certaines langues (Scala me vient à l'esprit) étant donné que ce sont des hybrides, mais je veux juste savoir qui surpasse qui sur quelles opérations et dans l'ensemble.

— Farouk
source

Les langages ne sont ni rapides ni lents, les implémentations le sont.

— starblue

Les implémentations de langage ne sont pas rapides ou lentes, les programmes exécutés à l'aide de ces implémentations de langage le sont (par rapport à certains autres programmes). Soyez charitable - lorsque quelqu'un parle qu'un langage de programmation est plus rapide qu'un autre, la manière évidente qui a du sens est de comprendre qu'il s'agit de programmes particuliers exécutés à l'aide d'implémentations de langage particulières.

— igouy

@starblue: C'est une réponse très simple et pas très utile. Bien qu'il soit certainement possible de créer deux implémentations du même langage, dont l'une est plus lente que l'autre, la façon dont vous l'exprimez implique qu'il n'existe pas de détails de conception de langage qui nécessitent nécessairement certaines inefficacités dans l'implémentation que d'autres langues, par leur conception, ne nécessitent pas. Et ce n'est tout simplement pas vrai. (Surtout dans ce sujet particulier; les langages fonctionnels sont connus pour eux!)

— Mason Wheeler

@igouy "Les implémentations de langage ne sont ni rapides ni lentes" Ce n'est pas vrai. CPythonvs PyPyvient rapidement à l'esprit.

— NlightNFotis

@NlightNFotis - Combien de secondes prend CPython? Combien de secondes prend PyPy? Les implémentations de langage ne sont ni rapides ni lentes. Combien de secondes ce programme prend-il avec CPython?

— igouy

Réponses:

Selon le Great Benchmarks Game , ATS est plus rapide que les autres avec Haskell, Scala et l'une des variantes de Common Lisp à égalité de vitesse juste derrière. Après cela, Ocaml et F # sont à peu près dans la même catégorie de vitesse avec Racket et Clojure à la traîne ...

Cependant, presque rien de tout cela ne signifie rien du tout. Tout est une question de problème, de machine, de compilateur, de techniques de codage et, dans certains cas, de chance. D'une manière générale, les langages codés automatiquement comme Haskell surclasseront les langages compilés par VM comme F # et surclasseront largement les langages purement interprétés. De manière générale, les langages de type statique sont plus rapides que les types de type dynamique en raison d'une analyse statique permettant de calculer toutes les opérations de type à la compilation plutôt qu'à l'exécution. Encore une fois, ce sont des règles générales, il y aura toujours des exceptions. Les "paradigmes" n'ont pas grand-chose à voir avec cela.

— Ingénieur du monde
source

Je sais qu'il y a beaucoup de facteurs à prendre en considération et même si tout était parfait, ils pourraient fonctionner différemment sur différentes données, ma question est assez vague. Merci pour le lien, vraiment utile - je ne savais pas que l'ATS était aussi rapide

— Farouk

Bon lien avec des informations de comparaison détaillées. Je suis un peu déçu de voir Clojure utiliser beaucoup plus de mémoire et prendre beaucoup plus de temps que Java. Je me souviens de certaines affirmations selon lesquelles Clojure aurait des performances similaires, ce qui ne semble pas être le cas.

— DPM

Le site Web ATS indique que ATS prend en charge une variété de paradigmes de programmation - donc avant de prétendre que ATS est plus rapide que le reste, vous devez montrer que ces programmes sont en fait écrits dans un style fonctionnel. Il se peut que l'ATS fonctionnel ne soit pas plus rapide que les autres.

— igouy

Le site Web de Scala indique que Scala intègre des fonctionnalités orientées objet et fonctionnelles. Avez-vous vérifié que les programmes Scala sont écrits comme des programmes fonctionnels plutôt que des programmes orientés objet?

— igouy

Il convient également de noter que vous ne pouvez pas mesurer / quantifier les performances d'un langage de programmation . Le mieux que vous puissiez faire est de mesurer les performances d'une implémentation spécifique du langage sur des plateformes spécifiques, en exécutant des programmes spécifiques.

Donc, lorsque vous demandez «le langage fonctionnel le plus rapide», ce que vous demandez vraiment sur le meilleur des implémentations actuelles du ou des langages.

Le commentaire de @ igouy soulève le fait qu'il existe d' autres mesures de performance pour la mise en œuvre du langage; par exemple le temps de compilation. Mais cela ne change pas le fait que le temps d'exécution du programme d'application est une mesure (indirecte) de l'implémentation d'un langage, pas une mesure du langage lui-même.

Prenons l'exemple de Java. Supposons que j'écrive un benchmark à thread unique en utilisant uniquement les fonctionnalités de langage de Java classique (Java 1.0). Si je compile et exécute en utilisant JDK 1.0, j'obtiendrai de mauvaises performances ('cos JDK 1.0 n'avait pas de compilateur de code natif). Si je passe de JDK 1.1 à ... JDK 1.7, j'obtiendrai probablement de meilleurs résultats progressivement. Mais cela n'est pas dû à des modifications du langage Java ... car mon benchmark utilise le même sous-ensemble de langage. Au contraire, l'accélération est due à des améliorations dans les compilateurs, le système d'exécution et / ou l'implémentation de bibliothèques de classes. Ce sont tous des problèmes de mise en œuvre .

L'autre point est que ces différences d'implémentation peuvent être vraiment importantes (par exemple des ordres de grandeur) pour le même langage. Ainsi, le fait que la meilleure implémentation de la langue X soit plus rapide que la meilleure (ou la seule) implémentation de la langue Y ne vous dit pas nécessairement grand-chose sur la langue elle-même.

— Stephen C
source

Le mieux que vous puissiez faire est de mesurer les performances de programmes spécifiques. Lorsque nous mesurons les performances d'une implémentation de langage, nous voulons savoir combien de temps il faut pour compiler un programme, pas combien de temps ce programme prend pour s'exécuter.

— igouy

Le temps d'exécution du programme est une propriété de ce programme particulier lorsqu'il est exécuté à l'aide de cette implémentation de langage particulière sur ce matériel particulier, etc. est utilisé comme raccourci pour les implémentations de langage bien connues habituelles.

— igouy

@igouy - c'est vrai. Mais beaucoup de gens ne font pas la distinction, comme l'illustrent de nombreux anciens sites Web proclamant que "Java est lent. Malheureusement, ce non-sens a été lu littéralement par toute une génération de programmeurs ... et il a considérablement nui à la réputation de Java. QUE c'est pourquoi je fais valoir ce point ICI.

— Stephen C

Comme vous voulez avoir la liberté de dire - "une mesure (indirecte) de la mise en œuvre d'une langue" - veuillez expliquer pourquoi quelqu'un d'autre ne devrait pas être libre de dire - une mesure (indirecte) d'une langue .

— igouy

@igouy - 1) Vous êtes libre de dire ce que vous voulez. Mais cela ne vous donne pas raison. 2) Considérons le cas où la seule implémentation d'un langage est la merde. Nous le comparons. Ensuite, nous mettons à jour l'implémentation, la comparons et les performances se sont considérablement améliorées. Est-ce à dire que les performances linguistiques se sont améliorées? Comment cela a-t-il un sens ... étant donné que la langue n'a PAS changé !!!

— Stephen C

Si vous regardez les langues uniquement sur la vitesse d'exécution, vous manquez quelques points majeurs. La vitesse est une bonne chose, mais ce n'est pas la seule chose.

Haskell utilise un système de type très robuste pour créer des programmes qui seront beaucoup plus susceptibles d'être exempts de bogues et robustes.

Erlang utilise son système de surveillance intégré pour vous permettre de créer des systèmes de pannes qui peuvent vous donner un niveau de fiabilité énorme face à différents types de pannes. De plus, Erlang peut vous offrir un niveau de concurrence difficile à égaler dans d'autres langues.

En vérité, je considérerais la vitesse d'exécution dans les temps modernes comme étant assez loin sur la liste de ce que je considérerais dans la plupart des cas. (OK si je faisais un calcul numérique massif, je voudrais probablement utiliser fortran pour la vitesse mais sinon ce n'est tout simplement pas assez important pour avoir de l'importance)

— Zachary K
source