Performances F # vs performances Erlang, existe-t-il une preuve que la VM d'Erlang est plus rapide?

J'ai mis du temps à apprendre la programmation fonctionnelle et je suis arrivé à la partie où je veux commencer à écrire un projet au lieu de simplement me lancer dans des tutoriels / exemples.

En faisant mes recherches, j'ai trouvé qu'Erlang semble être assez puissant en ce qui concerne l'écriture de logiciels simultanés (ce qui est mon objectif), mais les ressources et les outils de développement ne sont pas aussi matures que les produits de développement Microsoft.

F # peut fonctionner sur linux (Mono) afin que cette exigence soit satisfaite, mais en regardant autour d'Internet, je ne trouve aucune comparaison de F # vs Erlang. En ce moment, je penche vers Erlang juste parce qu'il semble avoir le plus de presse, mais je suis curieux de savoir s'il y a vraiment une différence de performance entre les deux systèmes.

Étant donné que j'ai l'habitude de développer en .NET, je peux probablement me familiariser avec F # beaucoup plus rapidement qu'Erlang, mais je ne trouve aucune ressource pour me convaincre que F # est tout aussi évolutif qu'Erlang.

Je m'intéresse surtout à la simulation, qui va envoyer beaucoup de messages traités rapidement vers des nœuds persistants.

Si je n'ai pas fait du bon travail avec ce que j'essaye de demander, veuillez demander plus de vérification.

f# erlang

— afuzzyllama
source

Les langues n'ont pas de vitesse. Les implémentations de langage spécifiques exécutant un programme spécifique sur une entrée spécifique (cela peut inclure tout le monde extérieur, selon le programme) ont une vitesse.

F # s'exécute sur le runtime .NET et Erlang s'exécute sur sa propre machine virtuelle. Les processus d'Erlang sont considérés comme légers par rapport aux langages de son domaine (comme Scala). Pour une simulation qui génère des nœuds et transmet de nombreux messages, le runtime .NET / Mono est-il aussi bon que la machine virtuelle d'Erlang ou la machine virtuelle d'Erlang est-elle supérieure?

— afuzzyllama

@delnan: Les langues ont des caractéristiques de performance.

— Jon Harrop

@JonHarrop Comment cela? Un langage de programmation n'est qu'une syntaxe et une sémantique associée.

@delnan: la sémantique impose des limites à l'optimisation. Par exemple, les langues à typage dynamique sont extrêmement difficiles à optimiser dans la pratique. L'absence de types de valeur sur la JVM entraîne une allocation de tas beaucoup plus importante que sur .NET et, par conséquent, une contrainte beaucoup plus importante sur le GC. Comme les générateurs de code, les récupérateurs peuvent et exploitent des informations telles que l'immuabilité afin d'améliorer les performances. La conception d'un langage de programmation a un effet énorme sur cela.

— Jon Harrop

Réponses:

Qu'entendez-vous par «viable»? "Avoir le plus de presse" n'est pas forcément le meilleur moyen de choisir une langue.

La renommée d'Erlang est sa capacité de parallélisation massive. C'est pourquoi il est couramment utilisé dans les commutateurs téléphoniques Ericsson. Erlang est doux en temps réel, vous pouvez donc y garantir certaines performances.

F # bénéficie des capacités d'optimisation de la gigue .NET. De plus, le langage lui-même est conçu pour être un langage fonctionnel très performant (il s'agit d'une variante d'OCaml, largement utilisée dans le secteur financier en raison de sa rapidité).

En fin de compte, à moins que vous ne prévoyiez d'exécuter des millions de minuscules agents en même temps (ce pour quoi Erlang est optimisé), F # devrait être à la hauteur.

Cette page explique les cas d'utilisation appropriés pour Erlang.

— Robert Harvey
source

Par «viable», j'entendais évolutif. Je sais qu'avoir la presse ne signifie pas que cette langue est nécessairement meilleure, mais il semble que Erlang a été prouvé (au moins par Ericsson). Qu'entendez-vous par agents? Processus?

— afuzzyllama

Oui. Il a été prouvé qu'Erlang gère simultanément de nombreux appels téléphoniques sur un commutateur Ericsson. Vous devez déterminer si votre cas d'utilisation est similaire. Je vois cela comme un cas d'utilisation relativement spécialisé; si cette caractéristique est absente dans votre application, je ne vois aucun avantage à utiliser Erlang, et la page Erlang décrit en fait certains cas d'utilisation pour lesquels Erlang ne convient pas .

— Robert Harvey

Agents, acteurs, c'est un concept de design qui revient beaucoup dans les discussions sur le langage fonctionnel; Je suis surpris que vous ne l'ayez pas encore rencontré. en.wikipedia.org/wiki/Agent-based_model

— Patrick Hughes

En d'autres termes, avez-vous besoin d' une évolutivité massive (maintenant ou à terme) du type fourni par Erlang? La plupart des programmes ne le font pas.

— Robert Harvey

F # a également le modèle d'agent - en utilisant le "MailboxProcessor" légèrement crypté qui est le même genre de chose que dans Erlang. Je ne peux cependant pas commenter les caractéristiques de performances relatives de chacun.

— FinnNk

Peu de déclarations objectives peuvent être faites à ce sujet car les performances de ces deux langages dépendent fortement de l'application et du style de programmation.

Le seul conseil que je puisse donner est que F # a l'avantage de performance d'un système de type statique et le CLR fait un bon travail en exploitant cela afin d'améliorer les performances. F # possède des agents asynchrones et le passage des messages, mais il n'a pas été optimisé et le code synchrone est souvent 10 fois plus rapide.

Erlang est typé dynamiquement, ce qui le désavantage considérablement en termes de performances (attendez-vous à beaucoup plus de boxe), mais il a été conçu à partir de zéro pour prendre en charge le passage rapide des messages entre les agents asynchrones, ce qui pourrait bien être beaucoup plus rapide que l'équivalent F # . Cependant, je n'ai pas de résultats de référence pour étayer cela: c'est juste mon attente.

Soit dit en passant, Erlang et F # sont des langues relativement marginales avec de petites communautés et, en raison de leurs différents marchés cibles, les personnes familières avec les deux sont rares. La seule personne à laquelle je peux penser qui se qualifie presque est Jesper Louis Andersen mais je ne sais pas combien de F # il a fait.

— Jon Harrop
source

Vous devriez lire cet article de Joe Armstrong: http://erlang.org/pipermail/erlang-questions/2012-F February / 064277.html

Bref, Erlang n'a pas été conçu pour être rapide! Il est raisonnablement rapide dans de nombreux cas, mais cela est secondaire à des problèmes tels que la tolérance aux pannes et la stabilité.

La vérité est qu'Erlang et F # sont des langues agréables, et même si je n'ai regardé que F #, j'ai écrit un livre sur Erlang: Construire des applications Web avec Erlang et je peux dire que c'est un langage amusant à travailler.

Je voudrais également souligner qu'il semble y avoir un boom des livres sur le langage fonctionnel qui seront publiés au cours des 6 à 9 prochains mois. Je connais au moins 4 sur Erlang (y compris le mien), un sur Haskell, ainsi que des titres sur OCaml, Clojure et F #.

— Zachary K
source