performance - ¿Qué hay del rendimiento del GC de Haskell para una aplicación en tiempo real suave como los juegos?
garbage-collection real-time (3)
Debido a que me di cuenta de que la lógica de reglas del juego debería manejar una enorme complejidad, estoy considerando usar un lenguaje no típico en el campo de juego como lenguaje de guiones lógicos en el juego. La razón del script en el juego es representar una lógica compleja con menos código. Así que se requiere un lenguaje extremadamente abstracto.
Pero la mayoría de los lenguajes bien abstraídos usan GC. Y normalmente los GC hacen que la CPU explote. Básicamente, difiere el borrado de la operación de memoria, y lo hace de una vez. Realmente crítico para los gráficos en tiempo real, incluidos los juegos y la GUI.
AFAIK, el GC de Haskell es un poco diferente con otros lenguajes basados en GC porque es un atributo inmutable. Es difícil de imaginar. No pude encontrar ningún documento en detalle.
¿Qué es diferente? ¿Y es que la CPU está libre de estallidos para los programas de larga ejecución? (carga bien distribuida a lo largo del tiempo, se puede invocar el comando GC completo manual para cada tic)
Es posible que desee consultar el hilo iniciado por Luke Palmer aquí: http://www.haskell.org/pipermail/haskell-cafe/2010-February/thread.html#73881
Puede que le interese esta publicación de blog de Simon Marlow sobre cómo mover GHC de la colección stop-the-world a algo más concurrente con tiempos de pausa más adecuados para aplicaciones suaves en tiempo real como juegos.
No he comparado el perfil de latencia de los GHC, pero, según tengo entendido, esos tiempos de pausa de 0,0007ms pueden parecer pequeños, pero son proporcionales al tamaño del almacenamiento dinámico que es muy pequeño para ese programa de tres en raya. serán órdenes de magnitud más grandes.
Puede que te interese el juego comercial Haskell, Nikki and the Robots , lanzado en 2011 por Joyride Labs.
No parecen estar teniendo ningún problema con tener un recolector de basura.