[pyar] Análisis sobre charla "Python más rápido que C"

[Fernando Pelliccioni]

2014-04-29 19:55 GMT-03:00 Claudio Freire <klaussfreire en gmail.com>:

> 2014-04-29 19:34 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
> > Cambié la forma de medición para poder hacerlo de forma portable en las 3
> > plataformas más populares: OSX, Windows y Linux.
> > Además la cambié porque sospecho que ptrace pueda estar interfiriendo con
> > las pruebas. No tengo un conocimiento profundo de ptrace, así que
> prefiero
> > medir usando tiempos.
>
> También cambiaste considerablemente lo que se mide.
>
> ptrace es una facilidad del sistema operativo (linux), en este caso,
> mide la cantidad de instrucciones ejecutadas.
>

¿Mide la cantidad de instrucciones o la cantidad de ciclos?
Considerando que los procesadores modernos tienen 8 pipelines por core
(para el resto, significa que se puede ejecutar hasta 8 instrucciones por
ciclo), no creo que la primera sea una buena medición.

Suelo usar stopwatches, Profile-Guided Optimizations (PGO) e Intel vTune
para verificar el rendimiento. Pero en este caso, no se como usar los
últimos dos con Python (además que para estas pruebas, no es necesario)

Más allá de eso, no voy a usar ptrace, ya que temo interfiera en la
ejecución
"passing a small fixed-size block of memory between the two"
http://en.wikipedia.org/wiki/Ptrace#Limitations
Voy a leer un poco la documentación oficial de ptrace para verificar si mis
presentimientos son reales o no.



>
> Es cierto que no es una medida exacta de tiempo (hay instrucciones e
> instrucciones), pero es lo que se puede hacer desde user-space. Hacer
> algo mejor requiere mucho más trabajo, involucrando profilers
> propiamente dichos que utilizan ayuda del kernel (para usar los
> performance-counters del CPU).
>

Igualmente, con usar un stopwatch (usan performance counters en las
implementaciones de C++ que tengo) y realizar varias ejecuciones de la
prueba es más que suficiente.


>
> El código tuyo tiene muchas falencias, la mayor de las cuales, es que
> no compensa el overhead de medición. Mejor sería, en vez de
> reimplementar timeit, usarlo (el módulo timeit).
>
>
Creo que te referís al código Python.
Y sí, me lo suponía, es por eso que pedí ayuda :)
Así que por favor, si alguien sabe como utilizar algo similar a un
Stopwatch en Python y me quiere guiar, le agradeceré.
¿Cómo es el tema de timeit?



>
> 2014-04-29 19:34 GMT-03:00 Fernando Pelliccioni <fpelliccioni en gmail.com>:
> >
> > Porfa, chequeen el codigo Python y díganme si se les parece correcto,
> tanto
> > el algoritmo como la forma de medición.
> > A los que tengan experiencia en otras implementaciones de Python, (como
> la
> > que menciona Claudio, CPython), por favor, me podrían dar una mano con
> > detalles de como instalar y compilar correctamente en esas
> implementaciones.
>
>
> CPython es la implementación de referencia de python (o sea: lo que
> bajás de python.org)
>


Ah mirá vos, pensé que era otra implementación. O sea que, ¿si ejecuto...
python my_program.py

con Python 2.7.5 estoy utilizando CPython?
Si es así, entonces creo que tengo una confusión, yo creí que CPython
transformaba el código Python a C.



>
> Fijate que si querés medir lo que tarda en ejecutar una multiplicación
> C++ (no C, lo que veo ahí no es C), no podés ni compilar con -O3 ni
> marcar las funciones como inline y las variables como const.


En realidad no quiero medir lo que tarda una multiplicación, el objetivo de
incluir ese test, es para demostrar que no tiene sentido. Y justamente a
ese punto estamos llegando.
Estoy usando C++, así puedo usar los relojes de alta resolución, en C
tendría que escribir el código necesario para cada plataforma.
Además, con C++ puedo obtener la misma performance que con C y además sacar
provecho de algunas abstracciones.
Igual no se preocupen, voy a utilizar C++ casi como en C, o mejor dicho,
ala FORTRAN. Creo que el código va a ser bastante entendible.

¿No puedo compilar con -O3 ni usar const ni inline?
Entonces, muchachos, estoy comparando algo real (Python) contra algo
imaginario (C o C++).
Sino me prohíben marcar las funciones como "inline" o las variables
"const", entonces, no estoy programando en C++.
En los programas reales, en producción, solemos compilarlos usando -Ox, y
aquí es donde salta otro punto por el cual este test es incorrecto.


> Porque si
> lo hacés, el compilador va a ejecutar la multiplicación en tiempo de
> compilación, y lo que vas a medir es lo que tarda en imprimir un
> string prefabricado (que imagino no es la idea).
>

De hecho, no va a haber siquiera string prefabricado, la función completa a
ser removida por el compilador :)
En Python debería ocurrir lo mismo (supongo). ¿Lo hace? Bueno, aquí tenemos
otro punto a discutir (lo dejamos para después)

Justamente mi objetivo haciendo esta prueba era dejar en claro por qué
considero que este test es incorrecto.
Espero haber haber despejado sus dudas, si no es así, pregunten.
El próximo paso es modificar el test, para poder medir cuanto tarda una
multiplicación en C o C++ usando -O3, inline, const (o sea, usando C++)
pero evitando que el compilador remueva todo el código.
Es fácil, ¿Se les ocurre como hacerlo?
Luego seguimos analizando los otros test de la charla

Saludos,
Fernando.


> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de
> Argentina - http://www.usla.org.ar
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20140429/f6629bc8/attachment.html>