2009-02-02 5 views
10

Selon ceci:Pourquoi est IronPython plus rapide que le Python officiel interprète

http://www.codeplex.com/IronPython/Wiki/View.aspx?title=IP20VsCPy25Perf&referringTitle=IronPython%20Performance

IronPython (Python pour .Net) est plus rapide que Python régulière (CPython) sur la même machine. Pourquoi est-ce? Je pense que le code C compilé serait toujours plus rapide que le bytecode CLI équivalent.

+3

Je ne suis pas sûr que cPython est plus officiel le Jython ou IronPython. Voir http://docs.python.org/reference/introduction.html#alternate-implementations –

+0

@ S.Lott: ce n'est pas * le * Python, mais c'est l'implémentation par défaut simplement parce qu'elle est la première. –

+3

Python n'est pas compilé en C –

Répondre

38

Le code Python n'est pas compilé en C, Python lui-même est écrit en C et interprète le bytecode Python. CIL est compilé en code machine, ce qui explique pourquoi vous voyez de meilleures performances en utilisant IronPython.

+0

Il y a une prise, cependant. Je suis d'accord sur la raison pour laquelle IronPython est plus rapide. IronPython est plus lent en termes de temps de démarrage. (Ce qui n'est pas important si vous utilisez le code régulièrement.) – ozgur

3

Pourrait-il être expliqué par cette notation sur la page liée:

En raison de la mise en cache du site dans la dynamique Language Runtime, IronPython effectue mieux avec plus passe PyStone que la valeur par défaut

+0

Sans savoir ce que cache le site (un concept très complexe qui n'est vraiment expliqué que dans une série de vidéos sur Channel9), cela ne vous dit rien.En outre, IPy1 (qui était pré-DLR) avait également de meilleures performances que CPython. Tout se résume à la compilation de CIL. –

8

Vous avez raison, C est beaucoup plus rapide. C'est pourquoi dans ces résultats CPython est deux fois plus rapide en ce qui concerne les dictionnaires, qui sont presque purs C. D'autre part, le code Python n'est pas compilé, il est interprété. Les appels de fonction dans CPython sont terriblement lents. Mais d'autre part:

TryRaiseExcept: +4478.9% 

Maintenant, il est là IronPython obtenir est horriblement mal.

Et puis, il y a ce projet PyPy, avec l'un des objectifs étant le compilateur Just-In-Time. Il existe même un sous-ensemble de Python, appelé RPython (Python réduit) qui peut être compilé statiquement. Lequel est bien sûr un lot plus rapide.

+0

Je me suis toujours demandé pourquoi RPython n'a pas été promu plus. C'est suffisamment dynamique pour être utile, mais très rapide. S'il y avait plus de documentation, je l'utiliserais sûrement. – Daishiman

+6

L'équipe PyPy ne veut pas vraiment encourager les gens à utiliser RPython. Ils le voient comme un détail de mise en œuvre de PyPy - il change tout le temps, a une mauvaise documentation et des rapports d'erreurs terribles. Ils se concentrent sur le fait de rendre le PYPy JIT assez rapide pour que vous n'ayez pas besoin d'utiliser RPython pour obtenir de la vitesse ... – fuzzyman

+0

RPython n'est pas destiné à être utilisé (ou même pris en charge par le développeur). C'est juste un sous-ensemble que PyPy utilise pour compiler. Si ma compréhension n'est pas fausse, un sous-ensemble, une partie de votre code sera compilé et certains seront encore interprétés. – ozgur

5

Je ne sais pas exactement comment vous en tirer la conclusion que IronPython est plus rapide que CPython. Le lien que vous publiez semble indiquer qu'ils sont bons pour différentes choses (comme les exceptions comme cela a été souligné).

5

En vous éloignant de votre question "Pourquoi?", À "Oh, vraiment?" Le "bon à différentes choses" (Jason Baker) est juste sur. Par exemple, cpython bat IronPython le temps de démarrage.

c:\Python26\python.exe Hello.py 
c:\IronPython\ipy.exe Hello.py 

CPython exécute un monde bonjour base presque instantanément (< 100ms), où IronPython a une surcharge de démarrage de 4 ou 5 secondes. Cela m'agace, mais pas assez pour m'empêcher d'utiliser IronPython.

+6

Ce n'est pas un avantage de CPython sur IronPython pour eux-mêmes. Les 4 ou 5 scours sont le temps de démarrage du CLR, pas de IronPython. –

+1

Peu importe pourquoi il faut 4 ou 5 secondes de plus pour démarrer. Il est plus rapide une fois qu'il fonctionne (en partie pour le CLR) mais plus lentement pour démarrer (en partie grâce au CLR). Les considérations de performance ont une signification basée sur l'impact de l'utilisateur. Si le cas d'utilisation d'un langage de script est de nombreux petits scripts, ceci est un inconvénient majeur. – Precipitous

+1

Peut-être que le temps de démarrage IronPython peut être réduit par une action unique pour pré-générer le code machine pour le fichier .dll IronPython? Voir Ngen.exe de Microsoft (Native Image Generator) http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx – ToolmakerSteve