Soporte para multi-core en Bennu

[darío]

A lo mejor digo una chorrada pero quizá para aquellas funciones que puedan funcionar de manera multithread se puede tener funciones separadas, algo así como load_map_bg, o similar.

[SplinterGU]

A lo mejor digo una chorrada pero quizá para aquellas funciones que puedan funcionar de manera multithread se puede tener funciones separadas, algo así como load_map_bg, o similar.

no es una chorrada, es correcto lo que decis...

[Windgate]

¿Y para load_song no se podría hacer algo similar? Algún .ogg de 8Mb he tenido por ahí... Y bueno, el resto de loads que faltan, aunque suelen cargar cosas más pequeñas también serviría poder tenerlos en un thread (fnt, ttf...).

En cualquier caso no es el soporte multi-core del que hablábamos, pero bueno, es un avance más de tantos otros hasta que en Bennu 2.0 se plantee :)

[l1nk3rn3l]

como bennu es modular lo primero que modificariamos serian los modulos

si bennu tiene mucha atomicidad por lo de los procesos ...

pero podriamos echarle mano a los modulos como el pathfind..
el modulo de quiksort, el que dicen de carga de datos , etc..

inclusive a rutinas de dibujo del mod draw , etc etc

tecnicamente la maquina virtual se dejaria intacta , solo se echaria mano de las rutinas
mas pesadas que comente..

puedo ofrecerme , claro despues de que ponga a punto la bennu3d

para realizar las primeras pruebas , haber si amerita(por supuesto) el cambio
para subir el rendimiento inclusive en un 50% en doble nucleo..

pero segun veo en windows tocaria inluir en la distribucion de los modulos estas dos nuevas DLL
libgomp-1.dll
pthreadGC2.dll

estuve molestando con el codeblocks y aqui dos programitas que ya hice(los que vienen de ejemplo por ahi)
ya pude compilar y mire y el rendimiento es alto!!
http://www.megaupload.com/?d=Z73G15AE

y como dije el codigo es pequeño y no afecta la portabilidad ya que son
sentencias #pragma de codigo C

[Windgate]

Descargando l1nk

El path_find sí que estaría bien en threads ya que consume un wevo, además de que me parece bastante ineficiente... Habría que meterle mano bien a fondo a esa función... Llevo meses diciendo que le echaré un vistazo :'(

EDIT: He visto el ejemplo, y veo que la eficiencia es de un 200% o más :o

¿Ese programa no lo has escrito en Bennu si no en C, verdad? En su día usé OpenMP desde C en la carrera, pero desde Bennu yo ni idea ??? si sale cualquier cosa palpable no dudes en subirla para echarle un vistazo ::)

[osk]

Aparte, ya comenté en su día que cuando no existe ningún camino posible, path_find se cuelga. Además de que sólo tiene un radio de acción limitado...

[Windgate]

Eso no tiene por qué ser así, un A* o cualquiera de sus variantes no tiene por qué colgarse y la profundidad máxima de búsqueda es un simple parámetro.

Estaría PERFECTO un path_find que permita seleccionar A+,A*,escalada,etc y la profundidad de búsqueda. Por ejemplo la escalada es un algoritmo rapidísimo, así SÍ que merecería la pena usar path_find en los juegos, ahora mismo no sirve más que para hacer arreglos puntuales sobre un proceso en cuestión... :(

[SplinterGU]

a ver... no todas las funciones se puede poner en threads, ya que muchas cosas se requiere esperar, y de usar threads se requiere de algun flag que notifique cuando acabo... y en algunos procesos hay que quedarse esperando ese flag... la cosa es que muchas veces en algunas funciones se depende de que los procesos esten en una foto estatica...

por ejemplo la pathfind... que pasa si yo requiero de un path desde A hasta Z, pero mientras esto se esta calculando en un thread, mi personaje que estaba en A, ahora (por no esperar) esta en H, y H no es ningun nodo del camino entre A y Z... en ese caso estariamos haciendo una gran cagada.

[FreeYourMind]

Te pongo una pantalla de tu ultima version, no veo tanta diferencia en los 2 nucleos como en el tuyo...

[Windgate]

FreeYourMind, accede a /prg/const.prg y cambia los valores de las CONST _ESCUADRON_X y _ESCUADRON_Z a otros valores, son la anchura y largura del escuadron de droides. Para valores "extremos" de por ejemplo 10x10 droides se come todo un núcleo y el otro núcleo se queda casi inactivo. Si consigues 60 fps avísame para pillarme un PC igual que el tuyo ;)

En serio, en casos extremos se satura uno de los núcleos y el otro queda roncando, hice las pruebas con el PC "en reposo" sólo corriendo la aplicación 3D.

@Splinter: Cierto lo que dices, asumía la necesidad del flag que indicase la finalización, con ello ya podría interpretarse el camino una vez esté resuelto y mientras tanto permanecer quieto. Juegos como Warcraft III lo hacen, se ven saturados por el cálculo y no mueven hasta que se resuelve un camino amén de otro gran número de optimizaciones como calcular una única ruta y que todas las unidades la sigan, aunque luego la ruta se vea modificada... Los chicos de Blizzard no se complicaron demasiado, por eso a ellos les funciona tan bien su "jueguecito de 1000 millones de $"

[SplinterGU]

teniendo esas consideraciones me parece fantastico

por ejemplo, la colision no se podria hacer con esto... ya que se necesita todo el sistema de procesos congelado.

[FreeYourMind]

60 no pero 4 ya es algo  ;D, y lo que veo raro es que mis nucleos salen con gráficos parecidos.

[Windgate]

@Freeyourmind... ¿Qué procesador tienes? Yo tengo un Core Duo 2Ghz y ya ves que no me deja superar el 50% de saturación en uno de los núcleos. ¿Y qué Windows calza tu PC? A ver si va a ser que Vista o 7 ofrecen más rendimiento que XP y yo sin saberlo... :(

@Splinter: Cierto, la colisión consume muuuuucho, lo he sentido en mis propias carnes... En cualquier caso se me ocurre que dependiendo del retraso para la resolución se podría paralelizar... Hace un par de años en programación paralela vimos problemas de mecánica de fluídos que al ser calculados partícula por partícula eran una aproximación de la realidad. Pero bueno, tampoco es plan de rebuscar tanto la solución.

La idea de pragma y OpenMP de l1nk también huele bien, ya veremos qué puede salir de todo esto ::)

[FreeYourMind]

Windows 7, pero estoy segurisimo que en Vista seria igual.
El XP creo que ya soportaba doble nucleo.

El mismo que el tuyo, el mio es Core Duo T7700, 2,4 GHz, 800 Mhz FSB, 4 MB L2 Cache.
Targeta gráfica GeForce 8600M GT TurboCache 512 MB

[l1nk3rn3l]

 :o
tecnicamente OpenMp funciona asi:

pones varios trabajos y estos al final se sincronizan, son hilos,
pero estos no terminan hasta que terminen ejemplo un bucle,
a diferencia de los hilos de SDL o de Boost,

asi no hay que tener ninguna bandera o flag para saber si ya termino,,

asi si llamamos a un pathfind que demoraba 300ms ahora demorara 150ms
y asi un completo frame podremos ejecutar mas tareas de lo que haciamos antes
..

no me supe explicar cuando propuse esto, OpenMP permite dividir varias tareas
y luego las sincroniza , los procesos no quedan en background, sino simplemente
que divide el tiempo en varias tareas , asi si un bucle duraba 2s ahora en 2core dura 1s
aqui la explicacion:
http://es.wikipedia.org/wiki/OpenMP
http://es.wikipedia.org/wiki/Programaci%C3%B3n_paralela

asi si el proceso de render que lo estuve mirando dura 20ms ahora durara 10ms en doble o mas nucleos sera menos
claro, esta tecnologia es escalable...


OpenMP se basa en el modelo fork-join, paradigma que proviene de los sistemas Unix, donde una tarea muy pesada se divide en K hilos (fork) con menor peso, para luego "recolectar" sus resultados al final y unirlos en un solo resultado (join). Modelo Fork-join

el programa(DESCARGA anterior) que habia dejado ordena una matriz y puede verse cuanto dura con y sin OPenMp
claro no uso banderas ni nada por el estilo , ha eso me refiero que esta tecnologia es muy facil de implementar
por algo la incluyeron dentro del compilador GCC inclusive Vstudio2008 ya la tiene pero tiene el estandar 2.0 de openmp
el gcc ya tiene el 3.0
;D

hicimos un repaso aqui:
http://coldev.blogspot.com/