Muy ambicioso tema saco, con 2D no he tenido problemas reales, pero con Bennu 3D empiezo a notar la necesidad de un soporte para aprovechar los múltiples núcleos de la CPU.
Aquí os dejo una captura de un videojuego en 3D en el que abuso, literalmente, del número de procesos activos. Bennu rinde como un verdadero campeón, pero observo que la ejecución se resiente por CPU, ya que sólo aprovecha el primer núcleo. Un soporte para multi-core en Bennu 3D sería una auténtica BOMBA ya que veo que Bennu 3D, con sus pequeños defectos promete y mucho:
(http://trinit.es/images/Bennugd/Sugerencias/extremo.jpg)
¿En qué podríamos ayudar para un soporte multi-core? Utilicen sus perversas mentes amigos ;)
EDIT: Aquí la imagen completa en la que se observa que solo se hace uso del primer núcleo: http://trinit.es/images/Bennugd/Sugerencias/extremo.jpg (http://trinit.es/images/Bennugd/Sugerencias/extremo.jpg)
a cuantos fps va esto?
Mira en los datos a la izquierda de la captura, creo que eran 1000vs1000 droides, cada uno con su modelo de arma y los disparos en sí son modelos también.
2 FPS :'(
No se bloquea, pero el FPS se resiente muchísimo, es por carga de CPU, eso lo tengo claro. He intentado reducir operaciones al máximo, pero me sigue faltando mi segundo núcleo.
no se si usas los 2 nucleos... quizas si estas usando aceleracion 3d, entonces puede estar usando los 2 nucleos...
no lo se, lo puedo ejecutarlo en linux...
Al hacer Ctrl+Alt+Supr monitorizo los 2 núcleos y veo que tengo uno saturado y el otro en desuso... No, no usa los 2 núcleos, puedes verlo en la captura.
No puedes probar en Vista o 7 y seguir los pasos de esta página a ver si funciona:
http://xp3ctr0.blogspot.com/2009/01/usar-los-2-nucleos-del-procesador-para.html
Parece que tambien da en XP:
http://www.taringa.net/posts/info/3109826/usar-los-2-nucleos-del-procesador-dual-core.html
Lo que me estoy imaginado es que sea sólo para que el SO lo aproveche y no las aplicaciones ejecutadas en el.
Esto es llevarlo todo al extremo más extremo, y pensar que yo creí pasarme al meter un mapa de 100x80 tiles/proceso ;D
Ahí, más que la CPU habría que pensar en hacer uso de la aceleración 3D si no lo está haciendo ya (estoy hecho un lio con la Bennu3D), y a partir de ahí ya pensar en multicore, porque no es lo mismo pasar a usar un motor 3d acelerado por HW que dividir la programación en varios cores y sincronizarlo.
Lo cierto es que Bennu se presta fácilmente al uso multicore, dada su naturaleza pseudo-concurrente (y que en tiempo de render se puede usar el segundo core para el sonido), pero a ver quien es el guapo que se pone a ello.
Por PC no es, porque he visto una burrada como el "Rome: total war" moviendo tropecientos modelos 3D en máquinas de menos de 2GHz. Supongo que hay que pensar que Bennu aun es interpretado y que va por soft...
Pero vamos, que para necesitar un maquinón para nuestros juegos ya hay que echarle narices ;D Wind, al final vas a necesitar imágenes 2d pre-renderizadas para mover eso :P
Había pensado usar modelos de mucha menos densidad poligonal para los planos más alejados o algo así... Es una pena lo de la eficiencia pero va mejorando la cosa.
En cuanto a echar una mano en el multicore, yo no tengo idea del tema, sorry :(
encontre una forma de usar las nuevas tecnologias sin modificar tanto el codigo y sin
tantos cambios y 100% portable a tecnologias donde no existe Multicore..
se llama OpenMP
http://es.wikipedia.org/wiki/OpenMP
y actualmente esta incluido en el compilador GCC que es el que usa bennu,
solo usar directivas pragma dentro del codigo y no afecta nada si la plataforma no lo usa...
http://openmp.org/
lo usare probandolo con Bennu3d a ver como me va..
es mas facil de usar que usar los hilos de la SDL...
es 100% libre y es muy facil de usar.. a ver si alguien se anima a modificar las partes criticas de bennu
como los loops en el motor los for ,,,, etc etc..
ejemplillo basico:
http://rajorshi.net/blog/2009/05/programming-for-multicore-introduction-openmp-gcc/
y las nuevas versiones con OpenMP y GCC
http://gcc.gnu.org/projects/gomp/
Tutorial:
https://computing.llnl.gov/tutorials/openMP/
ejemplos:
http://openmp.org/examples/Using-OpenMP-Examples-Distr.zip
Oh, me hablaron de OpenMP en la carrera pero no le dí importancia, gracias por el aporte l1nk, lo tendré en cuenta.
EDIT: Veo las estadísticas de uso de las CPU y alucino :o karma++, tiene muy buena pinta para tirar por ahí
A ver qué dice Splinter...
cuidado, bennu no puede trabajar con multithread, por lo menos no la parte de la maquina virtual... necesita tener una sincronizacion especifica...
despues de la version 1.0 final, esta pensado pasar varias cosas a multithread... como el motor grafico... y alguna otra cosa mas... pero no se puede la maquina virtual depende de la serializacion para funcionar correctamente...
Oh...
En mi caso simplemente tengo una matriz de IDs de proceso que chequear y retornar de ella un ID específico, eso lo veo "threadable"... De todas formas bueno es saberlo.
También se me había pasado por la cabeza tener un fichero que asocie IDs de proceso a IDs de objetivo, y que desde Bennu se consulte ese fichero mientras que desde otro programa en C se lea/escriba para que se detecten los objetivos usando threads... Incluso había pensado en CUDA...
¿Lo veis una chifladura total? Tened en cuenta que el tiempo de cálculo de objetivos consume como un 30% de CPU y pasarlo a otro programa dejaría más recursos para la parte gráfica :P
cuidado con eso... mientras la matriz sea de solo lectura no hay problemas con threads, cuando la matriz pasa a tener escritura ahi tenes que usar semaforos y de todo... pero el multithread no es ese el problema con bennu... el problema es que los procesos necesitan ejecutarse en un orden X, necesitan que un proceso ejecute antes que otro y tenga sus datos confiables... tanto a nivel usuario como a nivel interno, obviamente que todo esto puede ser semaforizado, pero eso es una complicacion muy grande para muchos...
hay cosas que actualmente son multithread, como una funcion de carga de fpg y otra de map si mal no recuerdo, se pueden pasar algunas cosas a multithread, pero hay que tener cuidado con eso... no todos manejan el concepto bien, y para la mayoria que viene de div, fenix, esto puede ser muy duro...
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.
Quote from: darío on November 20, 2009, 08:12:06 AM
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...
¿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 :)
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
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 ::)
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...
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... :(
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.
Te pongo una pantalla de tu ultima version, no veo tanta diferencia en los 2 nucleos como en el tuyo...
(http://forum.bennugd.org/index.php?action=dlattach;topic=919.0;attach=733)
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 $"
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.
60 no pero 4 ya es algo ;D, y lo que veo raro es que mis nucleos salen con gráficos parecidos.
(http://forum.bennugd.org/index.php?action=dlattach;topic=919.0;attach=735)
@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 ::)
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
: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/
l1nk3rn3l, justo te iba a decir que se podia hacer algo asi... je, esta bien esa openmp...
Me parece excelente si se avanza por OpenMP... Además teniendo en cuenta que mi propuesta partía de los recursos que consume Bennu 3D se podría pasar la carga de modelos a un hilo... A diferencia de las texturas, los modelos deben ser cargados cada vez que se quiere sacar uno nuevo a escena, y supongo que la succión de recursos será notable. En mi caso cada disparo que sale en pantalla conlleva una carga del modelo asociado :P