Python vs C, interpretado vs compilado, etc.

[Francesc Alted]

A Friday 16 January 2009, Alberto Valverde escrigué:
> Francesc Alted wrote:
> > A Thursday 15 January 2009, Antonio Beamud Montero escrigué:
> >> Antes de meterte con modulos en C, te recomiendo que ejecutes el
> >> código con la libreria JIT pysco. En mi caso, un analizador de
> >> flujos mpeg2 paso a ir 20 veces más rápido con solo añadir las
> >> lineas:
> >>
> >>  import psyco
> >>  psyco.full()
> >>
> >> Por lo que no tuve que optimizar nada (y eso que ya tenía la mitad
> >> del código preparado para pyrex).
> >
> > Conviene advertir que Psyco sólo funciona para plataformas i386 de
> > 32-bits, y que ya empiezan a haber demasiados
> > procesadores/plataformas de 64-bits como para ignorar este hecho.
> >
> > Psyco fue una tremenda revolución en su dia, y es una lástima que
> > su autor no haya hecho una versión para 64-bits, pero parece que
> > decidió concentrar todos sus esfuerzos en PyPy [1], que a la postre
> > es una continuación, pero a lo bestia, de Psyco.  Por desgracia,
> > los objectivos de PyPy son tan ambiciosos (hacer de Python un
> > lenguaje más rápido que C, como reza la página principal del
> > proyecto [2], con un poco de guasa, todo sea dicho), que empiezo a
> > dudar que el proyecto pueda ser funcional algún dia.
>
> Pues a mí no me parece algo tan descabellado, tal vez porque confío
> más en la capacidad de un compilador en generar código-máquina
> eficiente que en la de un humano para cualquier problema medianamente
> complejo. :)
>
> Creo que es precisamente es en los problemas de cierta complejidad
> donde un lenguaje de alto nivel como python permite al programador
> abstraerse de micro-optimizaciones y concentrarse en estructuras de
> datos y algoritmos eficientes. Dejarle al compilador la tarea de
> optimizar el cómo el hardware implementa los algoritmos me parece
> ideal.

Si, por ahi van los tiros, pero el hecho es que detrás de PyPy hay un 
equipo de bastantes personas que estan en el proyecto durante bastantes 
años, y la cosa cuesta de arrancar con lo que mucha gente se ha 
desencantado un poco (al menos es lo que me pasa a mi).

> Como anécdota para "demostrar" que PyPI ya es funcional hasta cierto
> punto comento que estamos utilizándolo para compilar automaticamente
> funciones vectoriales escritas en python para alimentárselas a
> numpy/scipy de una manera similar a la que se describe aquí:
>
> http://www.enthought.com/~ischnell/paper.html

Ah, muy interesante.  No conocia ese proyecto, pero resulta *muy* 
intrigante.  Por cierto, como acabo de anunciar una nueva versión de 
Numexpr [1] en la lista de NumPy, tenia curiosidad por ver que tal 
funcionaría comparado con el fast_vectorize (que usa el traductor de 
PyPy internamente).  Aquí estan mis resultados:

In [30]: x = np.random.rand(1e7)

In [31]: timeit -n1 -r3 fvec(x)
1 loops, best of 3: 4.14 s per loop

In [32]: timeit 4.2 * x*x - x + 6.3
10 loops, best of 3: 274 ms per loop

In [33]: timeit ne.evaluate("4.2 * x*x - x + 6.3")
10 loops, best of 3: 85 ms per loop

O sea, que Numexpr puede calcular unas 50x más rápido que el vectorize 
de NumPy y unas 3.3x más que NumPy.  Por las cifras que se dan en el 
informe (70x y 3.8x respectivamente), parece que el fast_vectorize es 
todavía más rápido que Numexpr (aunque haria falta comprobarlo en la 
misma plataforma).  Muy, muy interesante, desde luego.

[1] http://code.google.com/p/numexpr/

Saludos,

-- 
Francesc Alted
_______________________________________________
Lista de correo Python-es 
http://listas.aditel.org/listinfo/python-es
FAQ: http://listas.aditel.org/faqpyes