Микро-оптимизация - ПЛОХО против разработки игр

В разработке игр много C / C ++, в бизнес-приложениях C #. Я видел, как разработчики C / C ++ выражали беспокойство по поводу того, как одна строка кода преобразуется в сборку. В .NET некоторые заходят в IL, редко.

В C # «микрооптимизация» не одобряется, это редкость и обычно пустая трата времени. Похоже, это не относится к разработке игр.

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

Я не ищу дебатов о возможности C # как разработчика игр. Я знаю, что это было сделано до некоторой степени. Фокус на микро-оптимизации. Именно разница между Game Dev и Applications dev.

ОБНОВЛЕНИЕ
Под игрой я имею в виду современное, масштабное развитие. Например, MMORPG, Xbox, PS3, Wii ...

В бизнес-приложениях процессор не всегда является узким местом. Бизнес-приложение будет проводить большую часть времени в ожидании. Например:

1. ожидание результатов запроса базы данных
2. ожидание завершения веб-запроса
3. ожидание, чтобы пользователь сделал действие пользовательского интерфейса

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

Основным соображением является:

1. Пора торговать
2. Простота, может кто-то еще понять и поддерживать код

В бизнес-приложениях микросекунды очень редко имеют значение. В играх это факт жизни.

Если вы хотите, чтобы игра работала со скоростью 60 кадров в секунду, у вас есть ~ 16,67 миллисекунды, чтобы сделать все, что нужно сделать для этого кадра - ввод, физика, логика игрового процесса, аудио, сетевое взаимодействие, AI, рендеринг и т. Д .; если вам повезет, вы будете работать со скоростью 30 кадров в секунду и иметь роскошные 33,3 миллисекунды. Если кадр занимает слишком много времени, ваши обзоры пострадают, ваши игроки заполнят интернет-форумы желчью, и вы не будете продавать столько, сколько могли бы (не говоря уже о ударе по вашей профессиональной гордости), и если вам действительно не повезло найдет вашу команду кодирования бизнес-приложений для жизни.

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

Не ожидайте, что какой-либо язык высокого уровня выгонит C ++ на улицу, пока не будет предложена сопоставимая и предсказуемая производительность.

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

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

Это не потому, что языки принуждают людей к этому, а в том, что люди выбирают языки в зависимости от того, что они хотят делать. Если вы хотите выжать из программы последний бит производительности, вы не будете писать C # и компилировать в CLR и надеяться, что JIT-компилятор (или что-то еще) хорошо работает, вы пишете это во что-то, что вы можете в значительной степени контролировать выход. Вы будете использовать C или C ++ (и, возможно, ограниченное подмножество C ++) и изучите результаты на языке ассемблера и результаты профилировщика.

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

Игры постоянно раздвигают границы аппаратного обеспечения?

Да, они делают.

Если да, то по мере улучшения аппаратного обеспечения следует ли ожидать, что языки более высокого уровня захватят игровую индустрию?

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

Конечно, есть какое-то движение. Когда я был парнем и впервые заинтересовался разработкой игр, это была рукописная сборка, или черт побери. Это была эпоха Commodore 64. В настоящее время, конечно, C ++ является языком общения большинства разработчиков игр. И действительно, мы даже видели движение к использованию C ++ для кода движка и языка сценариев более высокого уровня для игрового логического кода. например, LUA, или движок Unreal имеет свой собственный язык UnrealScript.

В C # «микрооптимизация» не одобряется, это редкость и обычно пустая трата времени. Похоже, это не относится к разработке игр.

Если вы можете просто собрать свое приложение с высокоуровневым кодом и библиотечным кодом, то наверняка это пустая трата времени. Напишите это на устном языке, если хотите в этом случае; не будет иметь большого значения. Если вы пытаетесь реализовать передовой механизм глобального освещения, который воксализирует динамическое содержимое сцены на лету в реальном времени, как это делал CryEngine 3 , вы, естественно, не сможете избежать необходимости микрооптимизации.

«Игра» - это довольно всеобъемлющий термин. Если бы у вас была, скажем, MMORPG, меньшая оптимизация затронула бы многих игроков.

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

Я уверен, что хочу оптимизировать.

Игры постоянно выполняют огромные объемы фоновой обработки. Бизнес-приложения нет.

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

Я больше не работаю в gamedev, но я работаю в VFX в таких областях, как трассировка пути, и я видел много реализаций BVH и KD, которые обрабатывают ~ 0,5 миллиона лучей в секунду на сложной сцене (и это с многопоточная оценка). Грубо говоря, я склонен видеть прямую реализацию BVH в контексте трассировки лучей со скоростью менее 1 миллиона лучей в секунду даже при многопоточной оценке. За исключением того, что у Embree есть BVH, который может обрабатывать более 100 миллионов лучей на одной сцене с одним и тем же оборудованием.

Это полностью из-за «микрооптимизации», что Embree работает в 200 раз быстрее (тот же алгоритм и структура данных), но, конечно, причина, по которой он намного быстрее, заключается в том, что разработчики в Intel - это профессионалы, которые опираются на свои профилировщики и измерения и действительно настроил области, которые имели значение. Они не изменяли код, не задумываясь, и вносили изменения, которые привели к улучшению на 0,000000001% за счет значительного снижения удобства обслуживания. Это были очень точные оптимизации, применяемые в разумных руках - они могли быть микроскопическими с точки зрения фокуса, но макроскопическими с точки зрения эффекта.

Естественно, с учетом требований к частоте кадров в реальном времени для игр, в зависимости от того, насколько высокоуровневым или низкоуровневым вы работаете с игровым движком (даже игры, созданные с помощью UE 4, часто по крайней мере частично реализуются в сценарии высокого уровня, но, скажем, не самые важные части физического движка), микрооптимизация становится практическим требованием в определенных областях.

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

Если да, то по мере улучшения аппаратного обеспечения следует ли ожидать, что языки более высокого уровня захватят игровую индустрию?

Я скорее сомневаюсь, что одни только аппаратные усовершенствования могли бы сделать это, потому что с развитием аппаратного обеспечения, так же поступают инструкции и технологии (например, физика на GPU), а также методы и ожидания клиентов в отношении того, что они хотят видеть, и конкуренции в из-за того, что разработчики часто переходят на низкоуровневый уровень, как в случае веб-разработчиков, которые сейчас пишут низкоуровневые GLSL-шейдеры в WebGL (такого рода веб-разработка, возможно, даже более низкого уровня, чем десятилетие или два назад, поскольку GLSL является C-подобным языком крайне низкого уровня, и я бы никогда не догадался десятилетие или два назад, что некоторые веб-разработчики пойдут на написание таких низкоуровневых GPU-шейдеров).

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

Как ни странно, в наши дни, когда я работаю в реальных областях, критически важных для производительности, мне приходится несколько думать о более низком уровне, чем я начинал (хотя я начинал в эпоху Borland Turbo C DOS). Потому что тогда кеш процессора практически не существовал. В основном это были только DRAM и регистры, что означало, что я мог бы сосредоточиться больше на алгоритмической сложности и писать простые структуры, такие как деревья, очень простым способом без особого снижения производительности. В наши дни низкоуровневые детали кэша процессора доминируют в моем мышлении почти так же, как и сам алгоритм. И также у нас есть многоядерные машины, которые должны заставить нас задуматься о многопоточности, атомарности, мьютексах, безопасности потоков и параллельных структурах данных и т. Д., Что, я бы сказал, во многих отношениях является гораздо более низким уровнем внимания (как во, не так по-человечески интуитивно понятны), чем когда я начал.

Странно, но сейчас мне это кажется правдой. Я думаю, что на меня больше влияют базовые и низкоуровневые сложности и детали аппаратного обеспечения сегодня, чем я был 30 лет назад, изо всех сил стараясь снять очки ностальгии. Конечно, мы могли бы немного поговорить здесь о сборке и иметь дело с некоторыми ужасными деталями, такими как XMS / EMS. Но, по большей части, я бы сказал, что мне требовалось меньше сложности и осведомленности об аппаратных средствах и компиляторах, чем сегодня, когда я работаю в областях, критически важных для производительности. И это почти кажется правдой для всей отрасли, если отложить в сторону, как писатьif/else высказывания в несколько более понятной для человека форме и рассмотрим, сколько людей в целом в наши дни больше думают о деталях аппаратного обеспечения более низкого уровня (от нескольких ядер до графических процессоров, от SIMD до кэша ЦП и внутренних деталях того, как их компиляторы / интерпретаторы / библиотеки работают и пр.).

Высокий уровень! = Менее эффективный

Возвращаясь к этому вопросу:

Если да, то по мере улучшения аппаратного обеспечения следует ли ожидать, что языки более высокого уровня захватят игровую индустрию?

Для меня это не об оборудовании. Речь идет об оптимизаторах и инструментах. Когда я начинал, люди практически писали все консольные игры на ассемблере, и тогда было реальное преимущество в производительности, особенно с учетом отсутствия качественных компиляторов, генерирующих 6502.

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

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

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

В C # «микрооптимизация» не одобряется, это редкость и обычно пустая трата времени. Похоже, это не относится к разработке игр.

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

Для бизнеса «микрооптимизация» означает ускорение очень маленького шага в общем бизнес-процессе, реализуемом программным обеспечением. Причина, по которой это осуждается, как правило, одна из:

1. Дополнительные деньги, потраченные на доставку той же ценности для бизнеса, на несколько секунд быстрее. Деньги, сэкономленные на улучшении скорости, поступают из другого пула (времени пользователя), поэтому бизнес, как правило, не получает выгоды от затрат, которые он тратит, а клиент делает это за счет бизнеса.
2. Обычно бизнес-программисты плохо видят весь бизнес-процесс, поэтому оптимизация одного шага может не принести хороших преимуществ всему процессу. Например, если вы сделаете 3% процесса в 10 раз быстрее, вы ускорили весь процесс на 2,7%.
3. Как правило, бизнес имеет большой список оставшихся работ, которые имеют определенную бизнес-ценность, и будет устанавливать приоритеты добавления этого значения вместо доставки того же значения в (возможно) меньшее время.

Разработка игр - это другой зверь. «микрооптимизация» экономит небольшое количество времени в функции или рутине.

1. Игровые системы, как правило, придерживаются цикла рендеринга. В настоящее время золотой стандарт составляет 60 кадров в секунду, поэтому все, что будет рассчитано, должно быть выполнено и отображено на экране за 1/60 секунды.
2. Это означает, что часто одни и те же процедуры вызываются от тысячи до сотен тысяч раз в течение игры. Таким образом, 10-кратное улучшение в одной функции увеличивается в зависимости от того, сколько раз будут ощущаться выгоды от улучшения.
3. Неспособность достичь скорости рендеринга влияет на представление игры. Видео станет прерывистым, персонажи будут анимироваться с помощью прыжков и прыжков вместо плавных движений. Это немедленно выводит игрока из погружения в игру, и он подвергает сомнению ценность игры.

Так что в бизнесе никого не волнует, если форма четырехэтапного бизнес-процесса представлена ​​в 0,6 секунды или 0,5 секунды. Во время игр нужно заботиться о том, чтобы процедура, занимающая 200 мс, могла быть сведена к выполнению за 100 мс.

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

Это связано с тем, почему этот инструмент был выбран для конкретной работы.

Игроки в гольф будут зацикливаться на направлении и силе, которые они применяют с помощью клюшки, не так сильно, когда они используют водителя.

Почему? Потому что они разные виды снимков. Если вы хотите проехать на машине, вы должны проехать на фарватере с максимальным расстоянием. Для удара, вы хотите получить его точно в отверстие.

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

Большинство бизнес-приложений написаны как собственные инструменты. Ожидания относительно удобства использования этих инструментов намного ниже, чем в случае программного обеспечения, продаваемого массовым клиентам. Весьма распространено, что у внутреннего бизнес-приложения есть меню и диалоги, которые медленно реагируют на щелчки мыши, окна, которые перерисовываются с задержкой, или даже графический интерфейс, написанный на Swing (ужас!). Это происходит по ряду причин (более важно, что программное обеспечение настраиваемо, чем то, что оно очень «быстрое», пользователи программного обеспечения не имеют выбора, использовать или не использовать данное программное обеспечение, людей, которые делают Решение об установке программного обеспечения не используйте его сами ...). Следствием всего этого является то, что разработчики этого инструмента не тратят много времени на оптимизацию отзывчивости приложения, но очень заботятся о расширяемости и количестве функций. Разная клиентская база => разные цели дизайна => разная методология.

Обратите внимание, что бизнес-приложение, нацеленное на массовую аудиторию, например Excel, сильно оптимизировано.