Когда самое лучшее время для рассмотрения производительности?

  

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

Теперь вопрос в том, нужно ли нам думать о производительности в каждой отдельной строке кода при разработке игр?

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

45 голосов | спросил Emad 15 +03002017-10-15T05:59:23+03:00312017bEurope/MoscowSun, 15 Oct 2017 05:59:23 +0300 2017, 05:59:23

6 ответов


90

Инжиниринг для производительности

  • Следуйте рекомендациям поставщика.
  • Используйте правильные структуры данных.
  • Внедрить правильные шаблоны использования.
  • Не делай ничего глупого.

Оптимизация

  • Когда уже написанный код работает медленно, измерьте его, узнайте, почему, реализуйте то, что требуется, чтобы сделать его быстрым.

Преждевременная оптимизация

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

Эти три вещи не одинаковы .

В частности, Engineering for Performance - это то, что вы должны делать из самого старта , и это определенно не то же самое, что преждевременная оптимизация потому что он использует фактические измерения; в этом случае опираясь на опыт и рекомендации относительно того, как работает оборудование и какие шаблоны использования будут быстрыми или медленными.

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

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

ответил Maximus Minimus 15 +03002017-10-15T12:58:30+03:00312017bEurope/MoscowSun, 15 Oct 2017 12:58:30 +0300 2017, 12:58:30
22

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

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

  

Нужно ли нам думать о производительности в каждой отдельной строке кода при разработке игр?

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

Разговор о преждевременной оптимизации на самом деле не о том, что оптимизация - это плохо. Речь идет о том, что люди не в состоянии оптимизировать правильные вещи. Ваше время - одна из переменных, которые необходимо оптимизировать, что достигается, не теряя времени на «оптимизацию» функции, которая вызывается один раз каждые 30 миллисекунд и требует 100 микросекунд.

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

ответил Peter 15 +03002017-10-15T13:28:17+03:00312017bEurope/MoscowSun, 15 Oct 2017 13:28:17 +0300 2017, 13:28:17
9

Нет, вам не нужно проверять строку every , потому что не каждая строка имеет отношение к производительности. В основном это зависит от того, как часто выполняется строка. Раздел кода, который занимает 1 мс, который будет выполнен, совершенно не имеет значения, когда он выполняется один раз при запуске игры, стоит посмотреть, когда выполняется каждый кадр и определенно должен быть оптимизирован, если выполняется для каждого игрового объекта в каждом кадре.

Это также зависит от того, какую игру вы разрабатываете. Когда вы разрабатываете очень графический 3D-шутер, вам нужно быть гораздо лучше, чем когда вы программируете ретро-RPG-игру.

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

ответил Philipp 15 +03002017-10-15T13:15:28+03:00312017bEurope/MoscowSun, 15 Oct 2017 13:15:28 +0300 2017, 13:15:28
3

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

Вообще говоря, это связано с балансом между временем /ресурсами, потраченными на то, чтобы выяснить, есть ли что-то в правильном направлении, а время /ресурсы, потраченные на уничтожение плохих решений.

Подумайте об этом как о ремонте квартиры. Некоторые решения могут иметь длительные последствия («Упс, холодильник больше не вписывается в его кубиты». «Упс, где я хочу, чтобы в моей ванной не было воды»), но вы не будете думать о том, как каждый удар вашей кисти может повлиять, например, структурная устойчивость здания.

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

  • Я связываю скорость обновления игры с графической частотой кадров?
  • Я заставляю синхронную экономию?
  • Я заставляю (не) -детерминизм?
ответил TLW 15 +03002017-10-15T21:16:59+03:00312017bEurope/MoscowSun, 15 Oct 2017 21:16:59 +0300 2017, 21:16:59
1

Для игры ваша основная цель - встретить целевую частоту кадров на целевой минимальной машине (и, возможно, максимальное время загрузки и т. д.).

Чтобы сделать это, нет, вам не нужно беспокоиться после каждой строки.

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

Затем вам нужно беспокоиться, когда что-то является параллельным или параллелизуемым. Игры массово параллельны, если не по какой-либо другой причине, то из-за графики.
Следовательно, параллель не просто означает «потоки», но также, например, графический API, доступ к диску или сеть. Всякий раз, когда вы упускаете возможность иметь что-то, что может легко и изначально быть параллельным, запускаться параллельно, например, из-за плохой синхронизации (или из-за отсутствия асинхронного API), вы теряете больше, чем вы может когда-либо оптимизировать другими способами.
Вы также должны беспокоиться, когда что-то хорошо известно как узкое место или источник киосков, или препятствие для масштабирования. Например, например, переключение состояний отображения, рисование вызовов, чтение с графического процессора или открытие файлов.

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

ответил Damon 16 +03002017-10-16T22:02:28+03:00312017bEurope/MoscowMon, 16 Oct 2017 22:02:28 +0300 2017, 22:02:28
0

Получите реальность. Ответ просто полностью НЕТ. Нет обсуждения.

Основная проблема заключается в том, как вы спрашиваете:

  

Нужно ли нам думать о производительности в каждой строке кода в игре?   развитие?

Вы имеете в виду также такие вещи, как экраны конфигурации? Как разовой парсер для небольшого конфигурационного файла размером 1kb? Серьезно?

Не важно, сколько времени занимает большинство вашего кода. Существует не одно программное обеспечение, где каждая отдельная строка имеет критический момент. Нигде.

ответил TomTom 17 +03002017-10-17T14:00:00+03:00312017bEurope/MoscowTue, 17 Oct 2017 14:00:00 +0300 2017, 14:00:00

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132