Pregunta

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.

Lo que parece que no puedo entender es si estos idiomas tienen un rendimiento más cercano a sus " ancestros " o más cerca de algo como C # en términos de velocidad. Por ejemplo, es IronPython de alguna manera " compilado " hasta el mismo bytecode usado por C # y, por lo tanto, ¿se ejecutará igual de rápido?

¿Fue útil?

Solución

IronPython e IronRuby se crean sobre DLR (tiempo de ejecución de lenguaje dinámico) y se compilan en CIL (el código de bytes usado por .NET) sobre la marcha. Son más lentos que C #, pero faaaaaaar más rápido que sus homólogos que no son de .NET. No hay puntos de referencia decentes por ahí, que yo sepa, pero verás la diferencia.

Otros consejos

IronPython es en realidad la implementación de Python más rápida que existe. Para una 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 como 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 tanto IronPython como IronRuby (y JavaScript administrado, Dynamic VB, IronScheme, VistaSmalltalk y otros) se construyen.

En general, la velocidad de la implementación de un lenguaje es bastante independiente de las características del lenguaje real, y más depende de la cantidad de años de ingeniería que la integran. IOW: dinámico vs. estático no importa, el dinero sí.

Por ejemplo, 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 a C una carrera por su dinero. Las buenas implementaciones de Smalltalk se ejecutan tan rápido como Java (lo cual no es una sorpresa, ya que ambas JVM principales, Sun HotSpot e IBM J9, en realidad son máquinas virtuales Smalltalk ligeramente modificadas) o C ++. En solo los últimos 6 meses, las implementaciones principales de JavaScript (Mozilla TraceMonkey, Apple SquirrelFish Extreme y el nuevo chico en el bloque, Google V8) han hecho mejoras de rendimiento de ginormous , 10x y más, para llevar la cabeza de JavaScript a la cabeza con C no optimizada.

Actualmente IronRuby es bastante lento en la mayoría de los casos. Definitivamente es más lento que MRI (Implementación de Ruby de Matz) 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 a C # en términos de velocidad. En la mayoría de los casos simplemente no importa. Una llamada a la base de datos probablemente representará el 90% de la duración total de una solicitud web, por ejemplo.

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

Sospecho que IronPython tiene una historia similar.

Tienes la idea correcta al suponer que el rendimiento de una implementación moderna de .NET estará entre el del antepasado y el de C #. La razón es que C # está muy relacionado con .NET.

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

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 una evaluación ineficaz del estilo Python en una evaluación eficiente del 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 aquí .

Saludos, Jon Harrop.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top