C++ для игрового программирования - любовь или недоверие?

Это также зависит от типа игры. Если это игра со светом процессора (например, клон астероидов) или почти что-нибудь в 2d, вы можете получить больше. Конечно, умные указатели стоят дороже обычных указателей, но если некоторые люди пишут игры на C #, то умные указатели определенно не будут проблемой. И исключения, не используемые в играх, вероятно, являются правдой, но многие люди все равно злоупотребляют исключениями. Исключения следует использовать только для исключительных обстоятельств, а не для ожидаемых ошибок.

Относительно архитектуры Cell: она имеет некогерентный кэш. Каждый SPE имеет свой собственный локальный склад объемом 256 КБ. SPE могут получить доступ только к этой памяти; любая другая память, такая как 512 МБ основной памяти или локальное хранилище другого SPE, должна быть доступна с помощью DMA. Вы выполняете DMA вручную и копируете память в локальное хранилище, явно инициируя передачу DMA. Это делает синхронизацию огромной болью.

В качестве альтернативы, вы можете получить доступ к другой памяти. Основная память и локальное хранилище каждого SPE отображаются в определенный раздел 64-разрядного виртуального адресного пространства. Если вы получаете доступ к данным через правильные указатели, DMA происходит за кулисами, и все это выглядит как одно гигантское пространство общей памяти. Эта проблема? Огромный удар по производительности. Каждый раз, когда вы получаете доступ к одному из этих указателей, SPE останавливается, пока происходит DMA. Это медленно, и это не то, что вы хотите делать в критически важном для производительности коде (то есть в игре).

Это подводит нас к мнению Скиза о vtables и исправлениях указателей. Если вы слепо копируете указатели vtable между SPE, вы получите огромный удар по производительности, если вы не исправите свои указатели, и вы также получите огромный удар по производительности, если вы это сделаете исправьте свои указатели и загрузите код виртуальной функции в SPE.

Многие люди делают абсолютные заявления о вещах, потому что они на самом деле не думают . Они предпочли бы просто применить правило, делая вещи более утомительными, но требуя меньше дизайна и продуманности. Я бы предпочел немного задуматься, когда я делаю что-то волосатое и отвлекать от скуки, но я думаю, что не все так думают. Конечно, умные указатели имеют стоимость производительности. Так же как и исключения. Это просто означает, что может быть некоторыми небольшими частями вашего кода, где вы не должны их использовать. Но сначала вы должны составить профиль и убедиться, что проблема именно в этом.

Отказ от ответственности: я никогда не занимался программированием игр.

Если вы или ваш друг действительно параноидально настроены на производительность, то прочитайте руководства Intel по оптимизации. Удовольствие.

В противном случае каждый раз обращайтесь за правильностью, надежностью и ремонтопригодностью. Я бы предпочел, чтобы игра шла немного медленнее, чем та, которая вылетала. Если / когда вы заметите, что у вас есть проблемы с производительностью, ПРОФИЛЬ, а затем оптимизируйте. Вы, вероятно, обнаружите, что есть некоторый кусок кода, который можно сделать более эффективным, используя более эффективную структуру данных или алгоритм. Эти глупые маленькие микрооптимизации беспокоятся только тогда, когда профилирование показывает, что это единственный способ получить достойное ускорение.

Итак:

1. Напишите код, который будет ясным и правильным
2. Профиль
3. ПРОФИЛЬ
4. Можете ли вы использовать более эффективные структуры данных или алгоритмы, чтобы ускорить узкое место?
5. Использовать микрооптимизацию как последнее средство и только там, где профилирование показало, что это поможет

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

I have written small games in the past with C++ and use C++ currently for other high performance applications. There is no need to use every single C++ feature throughout the whole code base.

Because C++ is (pretty much, minus a few things) a superset of C, you can write C style code where required, while taking advantage of the extra C++ features where appropriate.

Given a decent compiler, C++ can be just as quick as C because you can write "C" code in C++.

And as always, profile the code. Algorithms and memory management generally have a greater impact on performance than using some C++ feature.

Many games also embed Lua or some other scripting language into the game engine, so obviously maximum performance isn't required for every single line of code.

I have never programmed or used a Cell so that may have further restrictions etc.

Последней игрой, над которой я работал, был Heavenly Sword на PS3, и это было написанный на C ++, даже код ячейки. До этого я делал несколько игр для PS2 и игр для ПК, и они тоже были на C ++. Ни один из проектов не использовал умные указатели. Не из-за каких-либо проблем эффективности, а потому что они, как правило, не нужны. Игры, особенно консольные игры, не выполняют динамическое распределение памяти с использованием стандартных менеджеров памяти во время обычной игры. Если есть динамические объекты (ракеты, враги и т. Д.), То они обычно предварительно распределяются и повторно используются по мере необходимости. Каждый тип объекта будет иметь верхний предел количества экземпляров, с которыми может справиться игра. Эти верхние пределы будут зависеть от объема требуемой обработки (слишком много, и игра замедляется), или от объема ОЗУ (слишком много, и вы можете начать часто выполнять подкачку на диск, что серьезно ухудшит производительность).

Игры обычно не используют исключения, потому что игры не должны иметь ошибок и, следовательно, не должны генерировать исключения. Это особенно верно для консольных игр, в которых игры тестируются производителем консолей, хотя на последних платформах, таких как 360 и PS3, действительно есть несколько игр, которые могут дать сбой. Честно говоря, я ничего не читал в Интернете о том, какова фактическая стоимость включения исключений. Если стоимость возникает только тогда, когда возникает исключение, то нет причин не использовать их в играх, но я точно не знаю, и это ». Вероятно, зависит от используемого компилятора. Как правило, игровые программисты знают, когда могут возникнуть проблемы, которые могут быть обработаны с использованием исключения в бизнес-приложении (такие как ввод-вывод и инициализация), и обрабатывают их без использования исключений (это возможно!).

Но затем в В глобальном масштабе C ++ постепенно уменьшается как язык для разработки игр. Flash и Java, вероятно, имеют гораздо больший сегмент рынка, и у них действительно есть исключения и умные указатели (в форме управляемых объектов).

Что касается доступа к указателю Cell, проблемы возникают, когда код DMA переходит в DMA. Ячейка по произвольным базовым адресам. В этом случае любые указатели в коде должны быть «исправлены» с новым базовым адресом, включая V-таблицы, и вам не нужно делать это для каждого объекта, который вы загружаете в Cell. Если код всегда загружается по фиксированному адресу, то нет необходимости исправлять указатели. Однако вы теряете немного гибкости, поскольку ограничиваете место, где может храниться код. На ПК код никогда не перемещается во время выполнения, поэтому исправление указателя во время выполнения никогда не требуется.

Я действительно не думаю, что кто-то «не доверяет» функциям C ++ - не доверять компилятору - это нечто совершенно иное, а часто и новое. эзотерические архитектуры, такие как Cell, стремятся получить надежные компиляторы C раньше, чем C ++, потому что компилятор C гораздо проще создать, чем компилятор C ++.

Кевин Фрей написал интересный документ: « Сколько на самом деле стоит обработка исключений? ».

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

Тот факт, что shared_ptr не используется широко, отчасти объясняется реальной стоимостью этого, но что еще более важно, потому что собственность не очень ясна. Право собственности и управление ресурсами - одна из самых важных и трудных задач. Отчасти потому, что ресурсов на консоли все еще не хватает, но также и потому, что наиболее сложные ошибки обычно связаны с нечетким управлением ресурсами (например, кто и что контролирует время жизни объекта). IMHO shared_ptr в этом не помогает.

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

Но есть много других частей C ++, которые широко используются в игровом бизнесе. Внутри EA EASTL представляет собой удивительный римейк STL, который очень адаптирован для высокой производительности и ограниченных ресурсов.

Есть старая поговорка о генералах, которые полностью готовы к войне в прошлой войне, а не в следующей.

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

Я тоже слышал это до того, как присоединился к игровой индустрии, но кое-что, что я обнаружил, это то, что компиляторы для специализированного игрового оборудования иногда ... некачественные. (Я лично работал только с основными консолями, но уверен, что это еще более верно для таких устройств, как сотовые телефоны и тому подобное.) Очевидно, это не большая проблема, если вы разрабатываете для ПК, где компиляторы испытаны, верны и изобилуют разнообразием, но если вы хотите разработать игру для Wii, PS3 или X360, угадайте, сколько вариантов у вас есть и насколько хорошо они протестированы по сравнению с выбранным вами компилятором Windows / Unix.

Это не означает, что инструменты обязательно ужасны, но они гарантированно работают только в том случае, если ваш код прост - по сути, если вы программируете на C. Это не значит, что вы можете ' t использовать класс или создать интеллектуальный указатель с использованием RAII, но чем дальше от этой «гарантированной» функциональности, тем шатче становится поддержка стандарта. Я лично написал строку кода, используя некоторые шаблоны, которые были скомпилированы для одной платформы, но не для другой - один из них просто не поддерживал должным образом какой-то крайний случай в стандарте C ++.

Некоторые из них, несомненно, являются программистами игр. фольклор, но есть вероятность, что он откуда-то пришел: какой-то старый компилятор странным образом разворачивал стек, когда возникали исключения, поэтому мы не используем исключения; Определенная платформа плохо работает с шаблонами, поэтому мы используем их только в тривиальных случаях; и т.п. К сожалению, проблемные случаи и места их возникновения, кажется, никогда нигде не записываются (и эти случаи часто являются эзотерическими, и их было сложно отследить, когда они впервые произошли), поэтому нет простого способа проверить, все еще проблема или нет, кроме в надежде, что в результате вы не пострадаете. Излишне говорить, что это легче сказать, чем сделать, поэтому колебания продолжаются.

Я наткнулся на отличную презентацию Sony под названием "Pitfalls of Object Oriented Programming" (Питфоллы объектно-ориентированного программирования). Это поколение консольного оборудования действительно заставило многих людей взглянуть на OO аспекты C++ и начать задавать вопросы о том, действительно ли это лучший путь вперед.

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