LLVM, Parrot, JVM, PyPy + python

https://stackoverflow.com/questions/5328295

26-10-2019
|

Pregunta

¿Cuál es el problema en el desarrollo de algunos idiomas, por ejemplo python para algunas técnicas optimizadas con algunos de LLVM / Parrot.

PyPy, LLVM, Parrot son las principales tecnologías para la plataforma común de desarrollo.
Yo veo esto como:

PyPy - marco para construir VM con construir en optimizados VM para python
De manera muy general la solución.El proceso va como se lista abajo:
1. dejando de PyPy código y:
  una.PyPy backend para algunos VM (como jvm)
  b.som Kit para hacer de la propia máquina virtual
  c.elaboración/ejecución de PyPy código interno

Estoy en lo cierto Acerca de este proceso?Para python no está optimizado VM?Especialmente por defecto no es construir en VM para la optimización de la PyPy código (el paso 5.c) - que es para python y cada procesamiento del lenguaje puede parar allí y se ejecuta por ella?

Parrot se parece mucho a PyPy, pero sin 5.a y 5.b ?Algunas mejoras internas para la dinámica de transformación (Parrot Magic Cookies).

Ambos Parrot y PyPy están diseñados para crear una plataforma de creación de un lenguajes dinámicos en tiempo de ejecución, pero PyPy quiere más - también para crear más de VM.
Donde es la sens de PyPy?Para lo que se necesita para crear más de VM?No debería ser mejor centrarse en una VM (como en parrot) - porque no es común que un código de nivel - ya sea PyPy interna bytecode o Loro queridos.Creo que no se puede ganar nada mejor para traducir a PyPy bytecode a los recientemente creados con PyPy VMs.

LLVM - lo veo muy similar a la de PyPy pero sin VM generador.
Es maduro, bien diseñado entorno con objetivos similares como PyPy (pero sin VM generador) pero el trabajo en el bajo nivel de la estructura y la gran optimización/JIT técnicas implemeted

Es ver esto como: LLVM es de uso general, pero Parrot y * * * * *PyPy* diseñado para lenguajes dinámicos.En PyPy / Parrot es más fácil introducir algunas complicadas técnicas - debido a que es más alto nivel, a continuación, LLVM - como la teorización del compilador que se pueda comprender mejor el alto nivel de código y producir mejor de código ensamblador (que los humanos no pueden escribir en un tiempo razonable), entonces el LLVM uno?

Preguntas:

Estoy en lo cierto?¿Hay alguna razón por la que portar algún lenguaje dinámico sería mejor llvm, a continuación, por ejemplo, Parrot?
No he visto la actividad en el desarrollo de python en Loro.Es porque el uso de python extensiones en C no funciona en el parrot?El mismo problema está en PyPy
Por qué otras VMs no quieres mover a LLVM / parrot.Por ejemplo ruby -> parrot, CLR/ JVM -> LLVM.No sería mejor para ellos para pasar a la solución más sofisticada?LLVM es en alto el proceso de desarrollo y tiene grandes empresas que invierten en.
Sé que el problema podría estar en recompilar son los recursos, si hay necesidad de cambiar de código de bytes - pero no es obligatorio - como podemos tratar de puerto viejo código de bytes a uno nuevo, y de nuevo los compiladores de producir el nuevo código de bytes (nunca menos de java todavía necesitan interpretarse propio código de bytes - para la interfaz de usuario puede ver y traducir al nuevo código de bytes)?
¿Cuáles son los problemas con la vinculación, por ejemplo, jvm bibliotecas dentro de llvm (si tenemos en puerto de alguna manera java/jvm/scala llvm)?
Puede que me corrija si estoy equivocado en alguna parte

Algunos addings:

=============

ACLARACIÓN

Quiero descubrir cómo todos estos programas consisten y cuál es el problema de la portabilidad de uno a otro.

Solución

Que no cosas que nadie puede dar respuesta en una pregunta de stackoverflow pero le doy un minmal tiro.

Primero ¿qué problemas tienen los 3 proyectos de resolver?

pypy permite implementar un intérprete de un lenguaje de alto nivel y consigue generar un jit de forma gratuita.Lo bueno de esto es que usted no tiene una dependencia de la falta de coincidencia entre el lenguaje y la plataforma.Esa es la razón por la que pypy-clr es más rápido, a continuación, IronPython.Más info aquí: http://codespeak.net/pypy/dist/pypy/doc/extradoc.html --> De alto rendimiento de la implementación de Python para la CLI/.NET con el compilador JIT de generación dinámica)
llvm es una infraestructura de bajo nivel para los compiladores.La idea general es tener un "alto nivel de la asamblea".Todos los optomizations trabajo en ese idioma.A continuación, hay toneladas de infraestructura a su alrededor para ayudarle a construir compiladores JIT (o AOT).La implementación de un lenguaje dinámico en llvm es posible, pero necesita más trabajo para luego implementarlo en pypy o loro.Usted, por ejemplo, no se puede obtener un GC de forma gratuita (hay GC puede utilizar junto con LLVM ver http://llvm.org/devmtg/2009-10/ --> el vmkit video ) Hay intentos de construir una plataforma mejor para la dinámica de idiomas basado en llvm: http://www.ffconsultancy.com/ocaml/hlvm/
No sé mucho acerca de parrot, pero como entiendo que quieren construir un estándar de máquinas virtuales especializados para la dinámica de idiomas (perl, php, python,....).El problema aquí es el mismo que el de la compilación a JVM/CLR hay una dependencia missmatch, sólo una mucho más pequeña.La VM todavía no conoce la semántica de su lenguaje.Como me unterstand parrot es todavía muy lento para el código de usuario.(http://confreaks.net/videos/118-elcamp2010-parrot)

La respuesta a tu pregunta:

Estoy en lo cierto?¿Hay alguna razón por la que portar algún lenguaje dinámico sería mejor llvm, a continuación, por ejemplo, Parrot?

Eso es una cuestión de esfuerzo.La construcción de todo su auto y especializados para eventualmente ser más rápido, pero es MUCHO más esfuerzo.

No he visto la actividad en el desarrollo de python en Loro.Es porque el uso de python extensiones en C no funciona en el parrot?El mismo problema está en PyPy.

La orientación de parrot sería (en este punto) no es probable que tenga un beneficio de más de pypy.¿Por qué nadie más lo hace, no sé.

Por qué otras VMs no quieres mover a LLVM / parrot.Por ejemplo ruby -> parrot, CLR/ JVM -> LLVM.No sería mejor para ellos para pasar a la solución más sofisticada?LLVM es en alto proceso de desarrollo y tiene grandes empresas que invierten en.

Ok hay un montón de cosas en esa pregunta.

Como he dicho LLVM es difícil mover a y parrot no es demasiado rápida (corríjanme si estoy equivocado).
Ruby tiene Rubinius bruja intenta hacer un montón de ruby y jit para llvm (http://llvm.org/devmtg/2009-10/ --> Aceleración de Ruby con LLVM).
Hay una aplicación de CLR/JVM en LLVM, pero ambos ya tienen muy maduro implemantations que tienen grandes inversiones.
LLVM no es de alto nivel.

Sé que el problema podría estar en recompilar son los recursos, si hay necesidad de cambiar de código de bytes - pero no es obligatorio - como podemos tratar de puerto viejo código de bytes a uno nuevo, y de nuevo los compiladores de producir el nuevo código de bytes (nunca menos de java todavía necesitan interpretarse propio código de bytes - para la interfaz de usuario puede ver y traducir al nuevo código de bytes)?

No tengo idea de cuál es la pregunta.

¿Cuáles son los problemas con la vinculación, por ejemplo, jvm bibliotecas dentro de llvm (si tenemos en puerto de alguna manera java/jvm/scala llvm)?

Ver el video de VMKit he enlazado más arriba que muestran lo lejos que tienes y cuál es el problema (y cómo lo han resuelto).

Puede que me corrija si estoy equivocado en alguna parte

Muchas de las cosas que escribió está mal o yo no anderstand lo que quieres decir, pero las cosas que he enlazado debe hacer un montón de cosas más claras.

Algunos ejemplos:

Clojure

El creater no quería que todo el trabajo de implementación de su propia máquina virtual y todas las bibliotecas.Así que por dónde ir?Desde Clojure es un nuevo idioma puede construir de una manera que funciona bien en una plataforma como la JVM restringiendo mucho de la dinámica de la materia un lenguaje como python o ruby habría.

Python

El lenguaje no puede (en la práctica) ser cambiado para que funcione bien en la JVM/CLR.Así que la implementación de python en aquellos que no traen enormes aceleraciones.Estática compilador no funciona muy bien, ya sea porque no hay muchos estática garantías.La escritura de un JIT en C será rápida, pero muy difícil de cambiar (consulte las condiciones del proyecto).El uso de la llvm jit podía trabajar y que es explorado por la Unladen Swallow proyecto (nuevo http://llvm.org/devmtg/2009-10/ --> Unladen Swallow:Python en LLVM).Algunas personas querían tener python en python así que empezaron a pypy y su idea de las costuras que funciona muy bien (ver arriba).Parrot podría trabajar así, pero no he visto a nadie que haya prueba (dude).

Sobre todo:

Creo que estás confundido y lo puedo entender.Tómese su tiempo y leer, escuchar, ver todo lo que puede conseguir.No te la tensión.Hay un montón de piezas para este y, finalmente, ver cómo lo que encaja y lo que tiene sentido y que incluso cuando usted sabe mucho todavía hay un montón de hablar de uno puede hacer.La pregunta es dónde implementar un nuevo idioma o cómo acelerar un viejo lenguaje tiene muchas respuestas y si le preguntas a 3 personas con las que es probable que obtener tres respuestas diferentes.

Otros consejos

¿Qué estás tratando de implementar? Su pregunta está muy confusamente redactada (me doy cuenta de que el inglés es probable que no sea su primer idioma).

LLVM y Pypy son proyectos maduros y útiles, pero realmente no se superponen mucho en este punto. (En un momento, Pypy podría generar Bytecode LLVM, que fue compilado estáticamente a un intérprete, en oposición al código C, pero no proporcionó un gran beneficio de rendimiento y ya no es compatible).

Pypy le permite escribir un intérprete en Rpython y usarlo como una descripción para generar un intérprete de código nativo o JIT; LLVM es un marco C ++ para construir una cadena de herramientas de compilador que también se puede utilizar para implementar un JIT. Los optimizadores, la generación de códigos y el soporte de la plataforma de LLVM son significativamente más avanzados que los de Pypy, pero no es tan adecuado para construir un tiempo de ejecución de lenguaje dinámico (ver el Retrospectiva de Saden Swallow para algunos ejemplos de por qué). En particular, no es tan efectivo para recopilar/usar retroalimentación de tiempo de ejecución (que es absolutamente esencial para hacer que los idiomas dinámicos funcionen bien) como el JIT basado en trazas de Pypy. Además, el soporte de recolección de basura de LLVM sigue siendo algo primitivo, y carece de la capacidad única de PYPY para generar automáticamente un JIT.

Por cierto, se basan dos implementaciones de Java en LLVM.J3/vmkit y Tiburón.

Podrías considerar ver el Charla de Stanford la semana pasada; Proporciona una descripción bastante decente de cómo funciona Pypy. Carl Friedrich Bolz's presentación También proporciona una buena visión general del estado de implementación de VM.

¿La razón principal? Porque el diseño de VM es no Una tecnología establecida, y tener una variedad de máquinas virtuales con diferentes objetivos y objetivos permite que una variedad de mecanismos se prueben en paralelo en lugar de tener que ser probados en serie.

El JVM, CLR, Pypy, Parrot, LLVM y el resto se dirigen a diferentes tipos de problemas de diferentes maneras. Es similar a las razones por las cuales Chrome, Firefox, Safari e IE usan sus propios motores JavaScript.

Unaden Swallow intentó aplicar LLVM a Cpython, y pasó más tiempo solucionando problemas en LLVM que al hacer algo específico de Python.

Python-on-Grot sufrió diferencias semánticas entre Perl 6 y Python causando problemas con el proceso de compilación front-end, por lo que es probable que los esfuerzos futuros en esta área usen el front-end de Pypy para apuntar a la VM loro.

Diferentes desarrolladores de VM ciertamente vigilan lo que están haciendo los demás, pero incluso cuando levantan buenas ideas les darán su propio giro antes de incorporarlos.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow