Текущее состояние Haskell в режиме реального времени

Я рассматриваю Haskell для мягкого приложения реального времени. Я, скорее всего, буду использовать актеров, для чего это стоит. Мне интересно, есть ли у кого-нибудь представление о текущем состоянии в реальном времени с Haskell. В частности, проблемы с GC приостанавливают приложение. Я широко изучил Google, и я нашел много дискуссий от 2+ лет назад, но ничего не сказал. Вот несколько ссылок, которые я нашел:

Использование Haskell для значительных систем реального времени: как (если?)?

Как о производительности GC Haskell для мягкого приложения в реальном времени, например игр?

Большая часть старых вещей, которые я читал, предполагает, что ситуация (в то время) считалась улучшающейся. Это?

Даже 2+ года назад было несколько замечаний, предполагающих, что приложения Haskell могут быть настроены для надежной остановки GC-пауз до миллисекунды или двух. Это кажется реалистичным?

Ответ 1

Таким образом, проблема "реального времени" - это латентность, введенная коллекциями GC.

GHC использует многоядерный сборщик мусора (и ветвь с локальные кучи для каждой нити). Первоначально разработанный для улучшения многопользовательской производительности (каждое ядро может собираться независимо) за счет сокращения стоимости частых остановок в мире, это происходит и с пользуется мягким реальным временем по той же причине. Однако с 2013 года локальная куча на потоке еще не была объединена в основной GHC, хотя параллельный GC был.

Для игры вы сможете использовать это, используя потоки и тем самым уменьшая потребность в локальных коллекциях stop-the-world.

Для долгоживущих объектов, в глобальной куче, вы по-прежнему рискуете GC (GC). Однако тщательное профилирование, например, ThreadScope удалит здесь препятствия. Я видел видео в реальном времени 1080p, транслируемое через сетевой стек, управляемый GHC, без заметных пауз GC.

И даже без этих настроек, вещи "могут просто работать". Фраг практически не нуждался в оптимизации, и теперь он был мягким в реальном времени почти 10 лет назад.

Наконец, для повышения производительности существует множество инструментов и флагов GHC:

ghc-gc-tune - получить графическое разбиение оптимальных флагов GC
Рекомендации по пропускной способности
Параметры сбор мусора - (могут быть полезны секунды)

И тогда есть кодировка: используйте unboxed types (no GC), минимизируйте ленивое распределение структуры. Храните долговечные данные в упакованном виде. Тест и бенчмаркинг.

Думаю, с тобой все будет хорошо.

Ответ 2

Вы видели их:

Текущее состояние сборки мусора в Haskell (июль 2012 г.)
также проверьте следующее обсуждение в Lambda the Ultimate

Кроме того, я бы рекомендовал обратиться к авторам статьи Multicore Garbage Collection with Local Heaps (ISMM 2011).

Ответ 3

Я не сталкивался с проблемами с паузами GC, если вы не используете ленивые списки для всего, вы не должны генерировать слишком много мусора.

Тем не менее Sky не очень яркий для многопоточных приложений. GHC по-прежнему не имеет планировщика с приоритетами потоков, если вы используете потоки для интенсивной обработки фона, вы можете легко голодать в цикле событий.

Ответ 4

GHC 8.2.1 имеет функцию Compact Region, которая может быть полезна.

По моему мнению, это похоже на управление полумаксимальным управлением памятью. Вы можете хранить долговечные данные в компактном регионе, и сборщик мусора не отслеживает его. Если есть какие-либо ссылки на что-либо в компактном регионе, весь компактный регион остается в живых. Когда в регионе нет ссылок на что-либо, он будет освобожден. Если вы создадите функциональные обновления для содержимого региона, вы можете перераспределить его в новом регионе, и старый регион будет освобожден.

http://ezyang.com/compact.html
https://hackage.haskell.org/package/compact-0.1.0.1/docs/Data-Compact.html