Заметки из мира IT

В стиле минимализм

В последнее время можно увидеть множество споров на тему того на сколько хорошо язык D подходит для разработки игр. С одной стороны красота и...
http://dynamic.versusit.ru/Files/2013/56017bdf-5bdb-4627-9f84-b21e27c42547.png

В последнее время можно увидеть множество споров на тему того на сколько хорошо язык D подходит для разработки игр. С одной стороны красота и функциональность языка делают его применение в геймдеве очень заманчивым, с другой можно встретить частую критику того, что встроенный сборщик мусора значительно снижает производительность, там где стремятся любой ценой выжать лишний FPS.

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

Однако говоря о сборщике мусора следует понимать, что сборщик мусора встроен в стандартную библиотеку Phobos, а не в сам язык. Это значит, что в случае необходимости сохраняется возможность писать и вручную управлять объектами. Это конечно потребует определенных усилий т.к. почти всё придется писать вручную и от стандартной библиотеки можно будет использовать только редкие части модули, такие как к примеру, std.traits.

Benjamin Thaut в своем блоге провел любопытное исследование не тему влияние сборщика мусора на производительность графической подсистемы. Были выполнены следующие сборки:

GC Version compiled with DMD: и скомилировал ее с флагами -O -release -noboundscheck -inline. Для управления большими блоками памяти не содержащие в себе указателей управлялись вручную. Это было нужно для повышения производительности. В остальном сборщик мусора вызывался вручную для каждого кадра.




GC Version compiled with GDC: Тот же самый код, что и в предыдущем варианте, только. Использованы следующие флаги -fno-bounds-check -frelease -O -finline-small-functions -findirect-inlining -fpartial-inlining -fpeephole2 -fregmove

Manually Memory Managed Version compiled with DMD: Полностью ручное управление памятью. Так же были произведены небольшие модификации библиотеки Phobos и рантайма из которой в чистом виде было использовано только несколько функций не затрагивающих сборщик мусора. Был разработан механизм подсчета ссылок, а так же механизм контроля и информирования о утечках памяти.

Результаты получились следующими:

DMD GC Version: 71 FPS, 14.0 ms frametime
GDC GC Version: 128.6 FPS, 7.72 ms frametime
DMD MMM Version: 142.8 FPS, 7.02 ms frametime

Время затраченное на сборку мусора:

DMD GC Version: 8.9 ms
GDC GC Version: 4.1 ms

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

Исходники самого проекта можно взять тут. Исходники должны быть совместимы с dmd 2.060, однако тесты выше были выполнены на dmd 2.058.
druntime (build with make -f win32nogc.mak, currently only works on windows)
phobos (build with make -f win32nogc.mak, currently only works on windows)
thBase (my standard library)

К сожалению автор не привел привел аналогичный код на С++. Однако есть мнение, что С++ не смог бы заметно превзойти D с отключенным сборщиком мусора.

Не смотря на то, что сейчас в геймдеве подавляющее большинство проектов использует С++ за последние несколько лет появилось значительное количество любительских графических движков на D, а так же один профессиональный рыночный продукт, который использует для своих игр компания Remedy Games. В свете чего хотелось бы обсудить вопрос того, какие преимущества при разработке игр дает D и какие недостатки необходимо преодолеть, чтобы D стал полноценной заменой С++ в геймдеве.

admin

Яндекс.Метрика