[Python-es] (Iron)Python en Visual Studio 2008

[lasizoillo]

El día 19 de enero de 2010 20:37, Olemis Lang <olemis en gmail.com> escribió:
>> C++ tiene tipado estático y python dinámico. Esto quiere decir que una
>> variable de C++ se sabe que va a contener en tiempo de compilación,
>> cosa que no se puede hacer con python. Esto permite hacer muchas
>> optimizaciones al compilador de C++ que no se pueden hacer en un
>> compilador de python. Normalmente, cuando se compila un programa de
>> python, lo que se hace es meter el interprete o maquina virtual en un
>> ejecutable, junto con el código de python a interpretar. Eso quiere
>> decir que lo normal es que compilando el python no ganes velocidad.
>>
>
> ... a no ser q desee calcular 100000 ! (factorial de 100,000)
>
> :P
>

Cojonudo el ejemplo. ¿Cómo compilarias a C o código máquina el siguiente código?

In [1]: reduce(lambda x,y:x*y, range(1, 100001))

No adjunto la salida porque requeriría varias pantallas. Las primeras
iteraciones son validas si x y/o y son enteros de 32 o 64 bits, pero
llega un punto en el que es necesario usar bigints. Un compilador
podría ponerse siempre en el peor de los casos y determinar que
siempre hacen falta bigints (lo cual no es óptimo), o podría hacer un
código que en tiempo de ejecución (y los correspondientes overflows)
fuera determinando el tipo de dato más apropiado para almacenar el
resultado (opción óptima pero demasiado compleja para encontrar buenas
opciones en la práctica), o incluso podría limitarse a meter en un
ejecutable el interprete de python y el programa a correr. Cuando
metes en un ejecutable el interprete de python y el programa, el
resultado (en tiempos de ejecución) es equivalente a no haber
compilado nada.

Es por eso que cython o pyrex añaden semantica de tipado estatico a un
lenguaje muy parecido a python, Porque así el compilador puede
ahorrarse la tarea de adivinar cosas y puede limitarse a generar
código con las indicaciones del programador.

Hay otros factores que ayudan a un compilador a generar código óptimo.
Y la riqueza de python no suele ayudar mucho. Es esa la razón por la
que me reafirmo al decir que compilando python no es motivo para
esperar demasiada optimización de código. Aunque hay que reconocer que
el código que propones (matemático) es posiblemente de los más fáciles
de optimizar y en los que más mejoría se pueda encontrar con un jit
como psyco.

Las opciones de jit que hay en python tienen algunas carencias:
 * psyco funciona solo en x86. Olvidate de usarlo en sparc, amd64, arm, ...
 * pypy están avanzando con un jit que parece prometedor. Pero todavía
está inmaduro y falta camino por recorrer para que funcione al 100%.
 * unladen-swallow también está inmaduro. Parece que google no va a
conseguir el exitazo que ha conseguido con el V8 (jit para
javascript).