Performance mono

Question

Existe-t-il des tests de performance pour Mono comparé à Java dans GNU/Linux?

Avez-vous déjà testé les performances de Mono?

Answer 1

Il y a un post intéressant de Miguel à ce sujet.

« Alvaro souligne que dans le Langue Shootout Benchmark Mono est à la 18ème place par rapport au 10 place de Java.

Nous savons que l'édition Java propriétaire de Sun (pas open source un, comme que l'on ne trouve nulle part encore) est plus rapide que Mono, mais j'étais surpris que nous étions si loin derrière Donc, j'ai regardé la comparaison entre Java6 et Mono. "

Comparison - Java and Mono http://tirania.org/pictures/javavsmono.png

See Details Here

Answer 2

Je l'ai vu un http://shootout.alioth.debian.org/gp4/csharp.php

Answer 3

amazedsaint>Il y a un post intéressant de Miguel sur ce point.

Ce graphique est très obsolète!

Voilà the current Mono C# 4.0 comparison

Answer 4

Je benchmarked Mono 2.2 against various other VMs including OCaml, LLVM, .NET and Java:

Mono 2.2 vs OCaml vs .NET vs LLVM vs JDK http://2.bp.blogspot.com/_NMRkpon4Ps0/SYNY8YtzTCI/AAAAAAAAACg/Bkjli4JV-NU/s1600-h/scimark2_individual.gif

En résumé, Mono 2.2 est mieux que Mono 2.0, mais est encore le plus souvent un beaucoup plus lent que presque tout le reste.

Answer 5

Mon indice de référence (en utilisant des problèmes mathématiques complexes et la manipulation de la mémoire (avec des chaînes brutes)):

MonoDevelop de Windows (en cours d'exécution sur la console en utilisant .net 3.5): Realizando Calculos em ... 535 itens 1.000.000 Realizando Operações com cordes Longas ... 2.038 Realizando Cálculos em ... 530 itens 1.000.000 Realizando Operações com cordes Longas ... 1.962 Realizando Cálculos em ... 530 itens 1.000.000 Realizando Operações com cordes Longas. .. 1.963

Utilisation de mono.exe sur Windows: Realizando cálculos em 1.000.000 itens ... 6.875 Realizando fonctionne avec des chaînes longues ... 6.206 Realizando cálculos em 1.000.000 itens ... 6.840 Realizando fonctionne avec des chaînes longues .. . 6.114 Realizando Cálculos em ... 6,857 itens 1.000.000 Realizando Operações com cordes Longas ... 6,116

en utilisant mono sur Linux Ubuntu: Realizando Cálculos em ... 5934 itens 1.000.000 Realizando Operações com cordes longues ... 6,915 Realizando cálculos em 1.000.000 articles ... 6,034 opérations de la scène avec des chaînes longues ... 7,489 effectuer des calculs 1.000.000 articles ... 5740 d'effectuer des opérations avec des chaînes longues ... 6731

code source même, mais sur Visual Studio 2008: la réalisation des calculs 1.000.000 articles ... 588 Exécution d'opérations avec des chaînes longues ... 1289 calculs du spectacle 1.000.000 articles ... 566 Exécution d'opérations avec des chaînes longues ... 1320 la réalisation des calculs 1.000.000 articles ... 702 opérations Jouer avec les longues chaînes ... 1393

VS 2008 a généré exe avec NGEN (executable natif): effectuer des calculs 1.000.000 articles ... 567 opérations de la scène avec des chaînes longues ... 1255 calculs du spectacle 1.000.000 articles ... 563 Exécution d'opérations avec des chaînes longues ... 1269 la réalisation des calculs 1.000.000 articles 562 ... en effectuant des opérations avec des chaînes longues

... 1263

dans ces tests, mono est plus lent que 10x .NET 3.5 SP 1 = (

Answer 6

C++, C# (Mono), et C VALA:

http://jpaflacerda.wordpress.com/2011/11/08/vala-benchmarking/ De nombreuses langues

: http://attractivechaos.github.com/plb/

Conclusion: Mono a évolué beaucoup, mais il est encore lent comparé à d'autres langues disponibles. Je me suis intéressé à Moat, qui a presque la même syntaxe de C#, mais est plus rapide que simple C dans certains cas.

Answer 7

La dernière version de ce shoot-out se trouvent here.

En un mot, par rapport à Java, Mono utilise beaucoup moins de mémoire et fonctionne un peu plus lent.

Pour garder les choses en perspective, les deux ils courent la même vitesse dans le grand schéma des choses. Ils Ces deux tests exécutés ordres de grandeur plus rapide que les langues comme Ruby, LUA, Python, PHP et Perl. Les deux Ils sont dans le ballon parc même que Pascal, OCAML, Haskell, Lisp et environ la moitié eux ce qui rend le jeûne comme C et C++. here Cliquez pour plus de détails.

Pour pinailler, Cornichons clairs Que nos réponses comparer ici Java et C# Mono. Les deux mono et environnements JVM sont ciblés par différentes langues et le choix des questions linguistiques. Par exemple, si l'on compare F # sur Mono avec Clojure sur la machine virtuelle Java, nous obtenons des résultats totalement différents et tout à coup « Mono » est « faster ».

Bien que ces comparaisons sont intéressantes et instructives, vous devez les prendre avec un grain de sel. Tout d'abord, bien que certains de personnes, la plupart des gens qui écrivent du code Java et C# ne sont pas en cours d'exécution, mais rien algorithmes numériques dans des boucles serrées. En second lieu, dans certaines de ces langues, les algorithmes testés peuvent être simplement appeler dans les bibliothèques sont Qué écrites en C et non pas dans la langue cible du tout. Enfin, d'autres points de référence (et mises en œuvre) devraient donner des résultats différents probables.

Pourtant, il est raisonnable de conclure que go est beaucoup plus rapide que Ruby, C++ est plus rapide que Go et Java et C# assez EFFECTUER raisonnablement Compte tenu de la façon dont ils sont productifs (à mon humble avis).

Answer 8

La plupart des points de référence sont basés sur le calcul lourd de boucles serrées. Le temps commence à compter juste avant la boucle et arrêter juste après.Si votre application effectue un traitement de données important, évitez C# et Java, optez simplement pour C/C++.

Il est plus probable que votre application soit côté serveur. Qu'il devra accepter les requêtes, récupérer les données et les renvoyer. Dans un tel scénario, la vitesse brute du code généré n'est pas pertinente par rapport aux autres paramètres. Vous feriez mieux de regarder l'efficacité du framework sous-jacent, la rapidité de la phase d'initialisation précédant l'exécution de votre code, comment il est facile d'implémenter des technologies efficaces comme des E/S non bloquantes, comment la mémoire est-elle libérée? et processus recyclé après l'exécution du code. À quel point est-il facile de déployer du code, de le faire évoluer ...

Le paramètre humain est encore plus important que tout cela. Un Java mal écrit est plus lent qu'un bon C# et vice versa. Vous devez donc vérifier vos développeurs. Quelle langue maîtrisent-ils, quel outil préfèrent-ils? Sont-ils des dépendants VS/resharper ou peuvent-ils utiliser Java IDE? Le temps passé à apprendre un nouveau langage ou un IDE ne sera pas dépensé pour écrire un code meilleur et plus optimisé.