Performance dynamique du langage .NET?

Question

Je comprends qu'IronPython est une implémentation de Python sur la plate-forme .NET, tout comme IronRuby est une implémentation de Ruby et que F # est plus ou moins OCaml.

Ce que je n'arrive pas à comprendre, c'est si ces langues fonctionnent plus près de leurs "ancêtres". ou plus proche de quelque chose comme C # en termes de vitesse. Par exemple, IronPython est-il en quelque sorte "compilé"? vers le même bytecode utilisé par C # et, par conséquent, fonctionnera aussi vite?

Answer 1

IronPython et IronRuby sont construits sur le DLR - environnement de langage dynamique - et sont compilés à la volée au format CIL (le bytecode utilisé par .NET). Ils sont plus lents que C # mais faaaaaaar plus vite que leurs homologues non.NET. À ma connaissance, il n’existe pas de points de repère décents, mais vous verrez la différence.

Answer 2

IronPython est en fait l’implémentation Python la plus rapide du marché. Pour une définition du terme "le plus rapide", au moins: la surcharge de démarrage du CLR, par exemple, est énorme par rapport à CPython. En outre, le compilateur d’optimisation IronPython n’a vraiment de sens que lorsque le code est exécuté plusieurs fois.

IronRuby a le potentiel pour être aussi rapide qu'IronPython, car bon nombre des fonctionnalités intéressantes qui font que IronPython est rapide ont été extraites dans Dynamic Language Runtime, sur lequel IronPython et IronRuby (et JavaScript géré, VB dynamique, IronScheme, VistaSmalltalk) et d’autres) sont construits.

En général, la rapidité d’implémentation d’une langue dépend de ses fonctionnalités et dépend davantage du nombre d’années-personnes en ingénierie utilisées. IOW: le rapport entre dynamique et statique n'a pas d'importance, mais pas l'argent.

Par exemple, Common Lisp est un langage qui est encore plus dynamique que Ruby ou Python, et pourtant, il existe des compilateurs de Common Lisp qui peuvent même donner à C une bonne idée de son argent. Les bonnes implémentations Smalltalk fonctionnent aussi vite que Java (ce qui n’est pas une surprise, car les deux principales machines virtuelles, Sun HotSpot et IBM J9, ne sont en réalité que des machines virtuelles Smalltalk légèrement modifiées) ou C ++. Au cours des six derniers mois seulement, les principales implémentations de JavaScript (Mozilla TraceMonkey, Apple SquirrelFish Extreme et le nouveau venu, Google V8) ont apporté des améliorations ginormous en termes de performances, 10x et plus, pour permettre à JavaScript de prendre la tête. à la tête avec C non optimisé.

Answer 3

Actuellement, IronRuby est plutôt lent à bien des égards. Il est nettement plus lent que l'IRM (Matz 'Ruby Implementation) dans son ensemble, bien qu'il soit parfois plus rapide.

IronRuby a le potentiel d’être beaucoup plus rapide, bien que je doute qu’ils approchent un peu le C # en termes de rapidité. Dans la plupart des cas, cela n'a pas d'importance. Un appel à une base de données constituera probablement 90% de la durée totale d’une requête Web, par exemple.

Je pense que l’équipe visera d’abord la maîtrise de la langue plutôt que la performance. Cela vous permettra d’exécuter IronRuby & amp; exécutez la plupart des programmes ruby ??lorsque la version 1.0 est disponible, ils peuvent alors améliorer les performances au fur et à mesure.

Je soupçonne que IronPython a une histoire similaire.

Answer 4

Vous avez la bonne idée de supposer que les performances d'une implémentation .NET moderne se situeront entre celles de l'ancêtre et celles de C #. La raison en est que C # est très étroitement associé à .NET lui-même.

F # est une évidence, car C # et OCaml ont eux-mêmes des caractéristiques de performance similaires.

IronPython est beaucoup plus difficile car Python et C # ont des caractéristiques de performances très différentes. En fait, la réponse dépend de l'implémentation d'IronPython elle-même, qui s'efforcera de convertir une évaluation inefficace de style Python en une évaluation efficace de style C #, dans la mesure du possible. Attendez-vous à ce que IronPython soit généralement beaucoup plus lent que C # avec les pointes occasionnelles sur le même territoire. Vous pouvez voir cet effet ici .

Salut, Jon Harrop.