Я всегда находил термин «микрооптимизация» довольно двусмысленным. Если некоторые изменения на уровне инструкций в структуре памяти и шаблонах доступа ускоряют процесс в 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 как мы, люди реагировать на горячие точки профилировщика, и это было сделано таким образом, чтобы обыграть лучших мировых экспертов, и даже тем, кто работает в наиболее критичных для производительности областях, было бы легко его освоить ... и это прогресс исходящих от смехотворно умных оптимизаторов, а не от более быстрого оборудования.