Estado actual de Haskell soft en tiempo real
Estoy considerando Haskell para una aplicación suave en tiempo real. Probablemente usaré actores, por si sirve de algo. Me pregunto si alguien tiene una idea del estado actual del tiempo real con Haskell. Específicamente, problemas con el GC pausando la aplicación. He buscado en Google extensamente, y he encontrado una gran cantidad de discusiones de hace más de 2 años, pero nada actual. Aquí hay un par de referencias que he encontrado:
Uso de Haskell para sistemas considerables en tiempo real: cómo (si?)?
Cómo ¿sobre el rendimiento de GC de Haskell para aplicaciones en tiempo real suaves como juegos?
Muchas de las cosas más antiguas que he leído sugieren que la situación (en ese momento) se pensaba que estaba mejorando. ¿Lo ha hecho?
Incluso hace más de 2 años, hubo algunos comentarios que sugerían que las aplicaciones de Haskell podrían ajustarse para mantener las pausas GC de manera confiable a un milisegundo o dos. ¿Esto parece realista?
4 answers
Así que la preocupación por el "tiempo real" es la latencia introducida por las colecciones GC.
GHC usa un recolector de basura multinúcleo (y hay una rama con montones locales por hilo). Originalmente desarrollado para mejorar el rendimiento del multcore (cada núcleo puede recopilarse de forma independiente) al reducir el costo de la sincronización frecuente de stop-the-world, esto también beneficia al tiempo real suave por la misma razón. Sin embargo, a partir de 2013, el montón local por hilo aún no ha se ha fusionado en el GHC principal, aunque el GC paralelo lo ha sido.
Para un juego debería ser capaz de explotar esto, mediante el uso de hilos, y por lo tanto reducir la necesidad de colecciones locales stop-the-world.
Para objetos de larga vida, en el montón global, todavía corre el riesgo de algunos (ms) GC. Sin embargo, el perfilado cuidadoso con, por ejemplo, ThreadScope eliminará los obstáculos aquí. He visto video 1080p en tiempo real transmitido a través de una pila de red administrada por GHC sin pausas de GC notables.
Y incluso sin estas melodías, las cosas "podrían funcionar". Frag no necesitaba casi ninguna optimización, y era suave en tiempo real hace casi 10 años.
Finalmente, hay muchas herramientas y banderas GHC para mejorar el rendimiento:
- ghc-gc-tune - obtener desglose gráfico de las banderas GC óptimas
- Consejos sobre rendimiento
- Opciones para recolección de basura - (- Isegundos pueden ser útiles)
Y luego está la codificación: use tipos sin caja (no GC), minimiza la asignación de estructuras perezosas. Mantenga los datos de larga duración en forma empaquetada. Prueba y punto de referencia.
Creo que estarás bien.Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-05-23 12:08:35
Has visto estos:
- Estado actual de la recolección de basura en Haskell (julio 2012)
- también, echa un vistazo a la siguiente discusión en Lambda the Ultimate
Además, recomendaría contactar a los autores del documento Multicore Garbage Collection with Local Heaps (ISMM 2011).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-06 01:46:43
No he encontrado problemas con las pausas de GC, siempre y cuando no uses listas perezosas para todo, no deberías generar demasiada basura.
El cielo no es tan brillante para aplicaciones multihilo, sin embargo. GHC todavía no tiene un planificador con prioridades de subprocesos, si utiliza subprocesos para el procesamiento en segundo plano pesado, puede matar de hambre fácilmente su bucle de eventos.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2013-03-14 11:18:43
GHC 8.2.1 tiene una característica llamada Regiones compactas que podría ser útil.
Desde mi punto de vista, parece ser un tipo de gestión de memoria semi-manual. Puede almacenar datos de larga duración en una región compacta y el recolector de basura no los rastrea. Si hay alguna referencia a algo en la Región Compacta, toda la Región Compacta se mantiene viva. Una vez que no haya referencias a nada en la región, se desasignará. Si realiza actualizaciones funcionales al contenido de un región puede reasignarla en una región nueva y la región antigua se liberará.
Http://ezyang.com/compact.html
https://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact.html
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-08-24 21:13:33