2008-09-28 16 views
8

Entiendo que IronPython es una implementación de Python en la plataforma .NET al igual que IronRuby es una implementación de Ruby y F # es más o menos OCaml.¿Desempeño dinámico del lenguaje .NET?

Lo que parece que no puede entender es si estas lenguas realizan cerca de sus "antepasados" o más cerca de algo así como C# en términos de velocidad. Por ejemplo, ¿IronPython de alguna manera se "compila" hasta el mismo bytecode utilizado por C# y, por lo tanto, se ejecutará igual de rápido?

Respuesta

9

IronPython y IronRuby están construidos sobre el DLR - tiempo de ejecución dinámico del lenguaje - y están compilados en CIL (el bytecode utilizado por .NET) sobre la marcha. Son más lentos que C# pero faaaaaaar más rápido que sus homólogos que no son .NET. No hay puntos de referencia decentes, que yo sepa, pero verá la diferencia.

+0

¿Tiene alguna prueba de ser "faaaaaaar más rápido que sus contrapartes que no son .NET"? ¿También hay alguna forma de evitar el atroz tiempo de inicio de 10 segundos? – Unknown

1

Actualmente IronRuby es bastante lento en la mayoría de los aspectos. Definitivamente es más lento que MRI (Implementación de Matz 'Ruby) en general, aunque en algunos lugares son más rápidos.

IronRuby tiene el potencial de ser mucho más rápido, aunque dudo que alguna vez se acerquen C# en términos de velocidad. En la mayoría de los casos, simplemente no importa. Una llamada a la base de datos probablemente constituirá el 90% de la duración total de una solicitud web, por ejemplo.

Sospecho que el equipo buscará la integridad del lenguaje en lugar del rendimiento primero. Esto le permitirá ejecutar IronRuby & ejecute la mayoría de los programas de ruby ​​cuando se envía 1.0, luego pueden mejorar el rendimiento a medida que avanzan.

Sospecho que IronPython tiene una historia similar.

7

IronPython es en realidad la implementación más rápida de Python. Para alguna definición de "más rápido", al menos: la sobrecarga de inicio del CLR, por ejemplo, es enorme en comparación con CPython. Además, el compilador de optimización IronPython tiene, realmente solo tiene sentido, cuando el código se ejecuta varias veces.

IronRuby tiene el potencial de ser tan rápido IronPython, ya que muchas de las características interesantes que hacen que IronPython sea rápido, se han extraído en Dynamic Language Runtime, en el que IronPython e IronRuby (y Managed JavaScript, Dynamic VB, IronScheme, VistaSmalltalk y otros) están construidos.

En general, la velocidad de una implementación del lenguaje es más o menos independiente de las características del lenguaje reales, y más dependiente de la cantidad de años-hombre de ingeniería que van en ella. IOW: dinámico vs. estático no importa, el dinero sí.

P. ej., Common Lisp es un lenguaje que es incluso más dinámico que Ruby o Python, y sin embargo, existen compiladores de Common Lisp que incluso pueden dar una carrera por su dinero. Las buenas implementaciones de Smalltalk se ejecutan tan rápido como Java (lo cual no es sorprendente, ya que tanto las principales JVM, Sun HotSpot e IBM J9, en realidad son solo ligeramente modificadas Smalltalk VM) o C++. Tan sólo en los últimos 6 meses, las principales implementaciones de JavaScript (Mozilla TraceMonkey, Apple SquirrelFish extremos y el nuevo chico en el bloque, Google V8) han hecho descomunal mejoras en el rendimiento, 10x y más, para llevar JavaScript cabeza a cabeza con ONU-optimizado C.

1

Usted tiene la idea correcta suponiendo que el rendimiento de una aplicación moderna .NET será entre el del ancestro y de C#. La razón es que C# está muy cerca de .NET.

F # es una obviedad porque C# y OCaml tienen características de rendimiento similares mismos.

IronPython es mucho más difícil porque Python y C# tienen características de rendimiento muy diferentes. De hecho, la respuesta depende de la implementación de IronPython, que se esforzará por convertir la evaluación ineficaz del estilo de Python en una evaluación eficiente de estilo C# siempre que sea posible. Espere que IronPython sea generalmente mucho más lento que C# con los picos ocasionales en el mismo territorio. Puede ver este efecto here.

Cheers, Jon Harrop.

Cuestiones relacionadas