Как насчет производительности Haskell GC для мягких приложений реального времени, таких как игры? - PullRequest
23 голосов
/ 19 декабря 2010

Поскольку я понял, что логика правил игры должна обрабатывать огромную сложность, я рассматриваю использование нестандартного языка в игровом поле в качестве языка сценариев внутриигровой логики. Причиной внутриигрового скрипта является представление сложной логики с меньшим количеством кода. Требуется очень хорошо абстрагированный язык.

Но большинство хорошо абстрагированных языков используют GC. И обычно ГХ нагружают процессор. В основном это откладывает очистку памяти и делает это сразу. Очень важно для графики в реальном времени, включая игры и графический интерфейс.

AFAIK, GC на Haskell немного отличается от других языков на основе GC из-за его неизменного атрибута. Трудно представить. Я не смог найти какой-либо документ об этом подробно.

Что отличается? И является ли процессор свободным для долго работающих программ? (хорошо распределенная нагрузка по времени, для каждого такта может быть вызвана ручная команда GC)

Ответы [ 3 ]

6 голосов
/ 19 декабря 2010

Вы можете посмотреть на тему, инициированную Люком Палмером, здесь: http://www.haskell.org/pipermail/haskell-cafe/2010-February/thread.html#73881

4 голосов
/ 12 мая 2011

Вас может заинтересовать коммерческая игра на Haskell, Nikki and the Robots , выпущенная в 2011 году компанией Joyride Labs.

enter image description here

Они неПохоже, что есть проблемы с сборщиком мусора.

4 голосов
/ 19 декабря 2010

Вас может заинтересовать это сообщение в блоге Саймона Марлоу о переносе GHC из коллекции "Останови мир" в нечто более параллельное со временем паузы, более подходящим для мягких приложений реального времени, таких как игры.

Я сам не тестировал профиль задержки GHC, но, насколько я понимаю, эти паузы в 0,0007 мс могут показаться маленькими, но они пропорциональны размеру кучи, крошечному для этой игрушечной программы «крестики-нолики», поэтомуреальные кучи и время паузы будут на порядок больше.

...