[eside-ghost] extensiones C/C++ para Python

[altern]

Alfredo Beaumont(e)k dio:
> Az, 2008eko Apiren 30a(e)an, altern(e)k idatzi zuen:
>> aupa gente
>>
>> una pregunta un poco vaga para los programadores... como de dificil
>> pensais que es para una persona que no hay usado nunca C/C++ pero que se
>> maneja bien con Python, hacer extensiones en C/C++ para python?
> 
> Bueno, yo diría que tiene una complejidad 'moderada'. No es trivial, pero 
> bueno, si hay que hacerlo tampoco es que sea excesivamente complicado. Si no 
> has programado en C/C++ probablemente lo que más te cueste es la parte que 
> tengas que hacer en ese lenguaje, sobre todo si necesitas que sea eficiente.
> 
>> el tema es que tengo un proyecto de investigacion que lleva graficos en
>> PyOpenGl en 2D pero necesito que sea mucho mas optimizado. Le he dado
>> muchas vueltas y creo que la unica solucion es portar alguna zona de la
>> libreria (o puede que entera), como una extension que pueda ser
>> controlada desde python. Esto me da un poco de panico pq no tengo ni
>> idea de lo complejo que esto pueda ser y no se si puede haber alguna
>> otra opcion.
>>
>> el problema es que necesito renderizar unos 100 de objetos que se mueven
>> cada frame, pero a la vez el consumo de CPU tiene que ser muy bajo (max
>> 10-15%) actualmente en cuanto meto mas de 25 objetos se me dispara
>> aunque le limite el fps al minimo.
> 
> Yo lo que haría, antes de embarcarme en la aventura de reescribir parte del 
> código en C/C++ es _saber_ a qué se debe ese consumo de CPU. Es decir, 
> tendrás que 'profile'ar tu aplicación y detectar los cuellos de botella. Es 
> posible que esos cuellos de botella no estén donde piensas que van a estar 
> (aunque bueno, si es renderizado de gráficos... es probable que esté donde 
> piensas), y también cuál es la mejor forma de resolverlo, hay varias 
> opciones:
>  * Que el problema se pueda resolver desde python optimizando el algoritmo
>  * Que haya que migrar el algoritmo a C/C++ para resolver el problema
>  * Que ni siquiera migrando a C/C++ vayas a obtener el rendimiento que 
> esperas.
> 
> En resumen, no te lances a la aventura 'a ciegas', primero invierte algo de 
> tiempo en ver qué es lo más conveniente.

ya le he dado un monton de vueltas, el problema esta tanto el los loops 
como en el render de OpenGL. Hago un loop sobre una lista con los 
objetos a renderizar. Por cada objeto hay que mirar las propiedades y 
llamar el metodo con el OpenGL. Al final el problema es que Python no 
chuta cuando tiene demasiado codigo por frame. Si haces un editor de 
texto o aplicaciones donde las partes fuertes sean locales no hay 
problemas.

Por ejemplo, en el mismo programa cada vez que hay un click del raton el 
programa hace un loop en la misma stack de objetos y calcula 
intersecciones para ver si hay alguno siendo clickeado. bueno pues esto 
no es ningun problema pq es puntual aunque hay *mogollon* de codigo con 
funciones matematicas y tal. Pero el loop de render va como muy lento a 
12 fps, o sea el loop con todo el codigo asociado 12 veces por segundo. 
Con esto no puede. Y he mirado un monton de tutoriales y hablado con 
vaios programadores de C/C++ todos me han dicho que la arquitectura 
parece que esta bien, que no es una chapuza, vamos.

Basicamente todo este codigo esta concentrado en un objeto que llamo 
Engine, aqui estan los metodos de OpenGL, y el loop de renderizado. Creo 
que esto es lo mas critico. Igual podria portar esto a C (como funciones 
en vez de objeto para no hacer C++) y dejar lo demas en python. Eso me 
dejaria con todo el OOP en Python. No se si esto haria mas facil el 
trabajo. Siempre oigo que C++ es mucho mas complicado que C.

bueno, gracias por los consejos!

enrike