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

[altern]

Jon Valdés(e)k dio:
> On Tue, May 6, 2008 at 11:24 AM, altern <altern2 en gmail.com> wrote:
>> aqui estoy de nuevo con python y opengl
>>
>>  ahora acabo de tener un rato para hacer unas pruebas generales y he
>>  hecho un ejemplo sencillo que adjunto. Incluso esto se lleva el 30 y
>>  pico % de mi CPU que es un PIV a 1.6 yo necesito que se mantenga por debajo
>> del 20% y necesito correr mucho mas codigo que el que hay en este ejemplo.
>>
>>  Entiendo de esto que el problema es general de python pq esto es muy
>> sencillo y mucho de donde arrascar u optimizar, que en general
>> python+pyopengl a pelo no chuta lo suficiente para mis necesidades...
> 
> He estado mirándolo un poco, y la verdad es que el rendimiento es
> verdaderamente pésimo. Buscando por internet cosas sobre pyopengl, me
> he encontrado un artículo [1] donde comparaban el rendimiento de perl
> y python con opengl (en el que salía perdiendo python), y luego un
> comentario del autor de pyopengl explicando por qué en python va todo
> tan lento.
> 
> De primeras, según lo que dice el tipo este, el asunto es que todas
> las instrucciones de pyopengl llaman a la función correspondiente de
> C, y luego hacen siempre una llamada a glGetError. Esto solo ya hace
> que hagan falta el doble de llamadas a la librería de opengl que las
> que harías en un programa en C (aparte que glGetError obliga a
> ejecutar todas las instrucciones que están en el buffer de
> instrucciones de OpenGL antes de poder ejecutarse, lo que destroza
> bastante el sistema que tiene OpenGL de mandar las instrucciones en
> bloques grandes, y revienta el rendimiento si lo haces mucho).

si, esto ya lo habia leido en otro lado.

> Por otro lado, comenta que los vertex arrays (una de las soluciones
> que te sugería yo en otros mails) tampoco es que funcione demasiado
> rápido, porque pyopengl acaba convirtiendo todos los elementos del
> array al formato de C, y eso tarda lo suyo :-S
> 
> Me temo que, efectivamente, y a no ser que pruebes a usar display
> lists en las partes que puedas, python es demasiado lento para lo que
> necesitas, asi que efectivamente tendrás que reimplementar parte en C
> o C++. Al final todo este thread no ha servido de mucho, parece :-S

bueno, a mi si pq ahora tengo mas claro por donde cojeo. supongo que a 
otros tb les habra servido para enterarse de algo.

> El tema de escribir módulos en C/C++ no tengo demasiada idea, pero
> fijo que gente de por aqui sí que sabe :)
> 
> Si tienes alguna pregunta de OpenGL en C o lo que sea, pregunta ;)

gracias!

> Por cierto, he flipado en esa página con el benchmark [2] que tienen
> entre C y Perl. Resulta que perl es prácticamente igual de rápido que
> C en OpenGL :-O No estaría mal que los de pyopengl aprendieran algo de
> la gente esta de POGL

gracias por tomarte la molestia de mirar esto. Otra opcion que quedaria 
puede ser http://www.pyglet.org/
esto es un wrapper a las dll directamente usando Ctypes. Creo que se 
puede desactivar el checkeo de errores tipo PyOpenGL y es mas eficiente, 
pero tb es mas nuevo, hace un año o asi que esta en marcha. Se supone 
que viene a reemplazar a pygame y pyopengl. Tiene muy buena pinta y 
hasta ahora no me habia metido con ello por vagueza, pero igual hay que 
probarlo a ver si hay alguna diferencia, aunque me temo que la solucion 
pasa por C.

> Un saludooo.
> 
> [1] http://graphcomp.com/pogl.cgi?v=0111s3B2
> [2] http://graphcomp.com/pogl.cgi?v=0111s3B1
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> eside-ghost mailing list
> eside-ghost en deusto.es
> https://listas.deusto.es/mailman/listinfo/eside-ghost