On 1/16/13 4:34 PM, Jaime Perea wrote:
On Miércoles, 16 de enero de 2013 16:06:29 Chema Cortes escribió:
El día 16 de enero de 2013 15:17, Francesc Alted <fal...@gmail.com>
escribió:
Yo no puedo opinar mucho de la interacción de LLVM con Julia por que no lo
conozco demasiado, pero sí que puedo decir que en Continuum estamos
poniendo a punto Numba (https://github.com/numba/numba), un compilador al
vuelo (JIT) que traduce código Python al lenguaje intermedio (IR) que usa
LLVM internamente. LLVM, a su vez, compila el IR a código nativo (que
depende de la platforma) y lo ejecuta (o lo puede guardar en un fichero
binario, esto ya depende de la aplicación).
Numba permite, mediante decoradores y anotaciones de tipo, hacer que
funciones puras en Python (ahora mismo no se soporta todo el lenguaje,
pero
sí un subconjunto bastante amplio) puedan correr a velocidad de C puro, y
lo que es mejor, de manera completamente interactiva (la compilación al
vuelo es realmente rápida). Numba es completamente open-source, así que
cualquiera puede contribuir al proyecto (de hecho alguien de esta lista
ya menciona que han contribuido ya).
Creo que ya tengo claro cómo usáis LLVM en numba. Incluso veo que
permite la compilación estática además de JIT, lo que seguramente
tiene que dar resultados bastantes buenos.
Tenía interés en saber si LLVM facilitaba la concurrencia y el cómputo
distribuido. Por lo que veo, Julia tiene estas facilidades, pero debe
ser cosecha propia. También estoy viendo proyectos para portar otros
lenguajes como scala o C# a LLVM, por lo que parece que esta
plataforma empieza a tomar auge y, tal vez, lleguemos a librarnos de
JVM y .Net.
Pero no hay que llevarse a engaño: LLVM realmente no es una tecnología
demasiado útil para PyPy, ya que éste último viene con su propio
compilador
JIT, asi no se complementan demasiado bien. En Continuum claramente hemos
apostado más por LLVM (via Numba) que por la vía PyPy. La ventaja de
Numba
es que no se tiene por qué renunciar a librerias que son extensiones (el
proyecto de migración de NumPy a PyPy está siendo lento y plagado de
trampas, y ya somos muchos los que dudamos de que se pueda llevar a cabo
de
una manera completa). Numba permite compilar de manera selectiva la parte
de código Python que es un cuello de botella, respetando toda la gama de
librerias y extensiones que ya existen ahora mismo.
Por supuesto que Blaze (https://github.com/ContinuumIO/blaze), nuestro
proyecto para reemplazar NumPy para problemas de Big Data, usará Numba
como
motor de cálculo de manera que el usuario no tenga que preocuparse de
hacer
extensiones para optimizar los cálculos, sino que éstos se efectuarán a
velocidad de C (¡y sin arrays temporales!) directamente. Blaze es otro
desarrollo open source, y aunque todavía está en su infancia, esperamos
que
de aquí a no mucho tiempo ya pueda ser posible hace cosas interesantes con
él.
No conocía Blaze. Le echaré un vistazo. Ya solo os falta un proyecto
para computación distribuída ;-)
Hola
Unas preguntas técnicas de un ignorante:
Cuando habláis de computación distribuida, ¿se refieres a python en entornos,
digamos, mpi o sólo en memoria compartida?.
No sé lo que piensa Chema en particular, pero para nosotros (Continuum),
los dos.
El problema que le veo siempre a esta historia es que si quieres mover datos
sin tener que ir a tcp/ip, por ejemplo moviendo cosas en infiniband, no te
quedan muchas más opciones que mpi... o inventarte algo como protocolo de
comunicaciones. ¿Sabéis como lo gestiona esto julia?.
Yo no tengo ni idea de como lo gestiona Julia. Pero como he dicho
antes, el espíritu de Blaze es distribuir los datos entre diferentes
nodos y después intentar mapear el código donde están los datos con el
fin de minimizar su transporte (el map-reduce funciona de manera
parecida). En los casos donde este mapeo no pueda ser exacto los datos
se tendran que transportar. El tipo de transporte que se usará todavia
está por decidir, pero Disco (http://discoproject.org/), y en
particular, su filesystem distribuido tiene muchas papeletas para ser el
vehiculo elegido (pero es cierto que todavia contemplamos otras posibles
soluciones).
Otra pregunta ¿como afecta la existencia del GIL a vuestros tipos de
optimizaciones?
El GIL sólo afecta a código que corre en la máquina virtual de Python,
asi que el código emitido por LLVM no está sujeto a tales
restricciones. En particular, nuestro objectivo es poder usar de manera
efectiva no sólo los diferentes cores de la CPU de manera simultánea,
sino también las posibles GPUs del sistema.
Poder programar number-crunching en python es un sueño para gente como yo :-)
Bueno, para tí y para mucha gente ;)
--
Francesc Alted
_______________________________________________
Python-es mailing list
Python-es@python.org
http://mail.python.org/mailman/listinfo/python-es
FAQ: http://python-es-faq.wikidot.com/
