2009-02-02 16 views
10

De acuerdo con esto:IronPython rápido que el intérprete de Python Oficial

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

IronPython (Python para .Net) es más rápido que Python regular (CPython) en la misma máquina. ¿Por qué es esto? Creo que el código C compilado siempre sería más rápido que el bytecode de la CLI equivalente.

+3

No estoy seguro de que cPython sea más oficial que el Jython o IronPython. Ver http://docs.python.org/reference/introduction.html#alternate-implementations –

+0

@ S.Lott: no es * el * Python, pero es la implementación predeterminada simplemente por ser el primero. –

+3

Python no se compila en C –

Respuesta

38

El código de Python no se compila en C, Python en sí está escrito en C e interpreta el bytecode de Python. CIL se compila en código máquina, por lo que se observa un mejor rendimiento cuando se usa IronPython.

+0

Sin embargo, hay una trampa. Estoy de acuerdo sobre por qué IronPython es más rápido. IronPython es más lento en términos de tiempo de inicio. (Lo cual no es importante si está usando el código regularmente.) – ozgur

3

Podría ser explicada por esta notación en la página se ha vinculado a:

Debido a la caché de sitio en la dinámica Language Runtime, IronPython realiza mejor con más PyStone pasa de el valor predeterminado

+0

Sin saber qué es el almacenamiento en caché del sitio (un concepto muy complejo que solo se explica realmente en una serie de videos en Channel9), esto no le dice nada.Además, IPy1 (que era pre-DLR) también tuvo un mejor rendimiento que CPython. Todo se reduce a la compilación de CIL. –

8

Tienes razón, C es mucho más rápido. Es por eso que en esos resultados CPython es el doble de rápido en lo que respecta a los diccionarios, que son casi puros C. Por otro lado, el código de Python no se compila, se interpreta. Las llamadas de función en CPython son terriblemente lentas. Pero por otro lado:

TryRaiseExcept: +4478.9% 

Ahora, no hay donde IronPython se obtiene es muy mal.

Y luego, está este proyecto PyPy, con uno de los objetivos que es el compilador Just-In-Time. Incluso hay un subconjunto de Python, llamado RPython (Python reducido) que se puede compilar estáticamente. Lo que por supuesto es un lote más rápido.

+0

Siempre me he preguntado por qué RPython no se ha promocionado más. Es lo suficientemente dinámico para ser útil, pero muy rápido. Si hubiera más documentación para eso, seguramente lo usaría. – Daishiman

+6

El equipo de PyPy realmente no quiere alentar a las personas a usar RPython. Lo ven como un detalle de implementación de PyPy: cambia todo el tiempo, tiene una documentación deficiente y un terrible informe de errores. Se están concentrando en hacer que PyPy JIT sea lo suficientemente rápido para que no * necesites * usar RPython para obtener velocidad ... – fuzzyman

+0

RPython no está destinado a ser utilizado (ni siquiera atendido por el desarrollador). Es solo un subconjunto que PyPy usa para compilar. Si mi comprensión no es incorrecta, se compilará un subconjunto, una parte de su código y aún se interpretarán algunos. – ozgur

5

No estoy seguro de cómo se llega a la conclusión de que IronPython es más rápido que CPython. El enlace que publicas parece indicar que son buenos en cosas diferentes (como excepciones como se ha señalado).

5

Paseando su pregunta "¿Por qué?", ​​A "Ah, ¿en serio?" El "bueno en cosas diferentes" (Jason Baker) sigue adelante. Por ejemplo, cpython supera a IronPython en el tiempo de inicio.

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

CPython ejecuta un mundo básica hola casi al instante (< 100 ms), donde IronPython tiene una sobrecarga de arranque de 4 o 5 segundos. Esto me molesta, pero no lo suficiente como para evitar que use IronPython.

+6

Eso no es una ventaja de CPython sobre IronPython para ellos. Los 4 o 5 segundos son el tiempo de inicio del CLR, no de IronPython. –

+1

No importa por qué tardan 4 o 5 segundos más en iniciarse. Es más rápido una vez que se ejecuta (en parte lo hace con el CLR) pero más lento al inicio (en parte debido a la CLR). Las consideraciones de rendimiento tienen importancia en función del impacto del usuario. Si el caso de uso para un lenguaje de script es muchos scripts pequeños, este es un inconveniente grave. – Precipitous

+1

¿Quizás el tiempo de inicio de IronPython se puede reducir mediante una acción única para pregenerar el código de máquina para el .dll de IronPython? Ver Ngen.exe de Microsoft (generador de imágenes nativas) http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.110).aspx – ToolmakerSteve

Cuestiones relacionadas