Комментарии 52
Бенчмарки это все здорово... а в реальной жизни 6 ядер 3.7Ггц дадут больший комфорт в работе, чем 20 ядер 2.6ггц, хотя попугаи будут говорить нам что второй быстрее в 3 раза.
20 ядер 2.6 ГГц - это какой-нибудь Xeon? Кто мешает вместо него поставить Extreme Edition, у которого частота ядер выше, а стоимость примерно такая же? А еще есть AMD Epyc, там 24 ядра (настоящих, не виртуальных) не так уж дорого стоят.
Есть Xeonы с достаточно высокой частотой. Но вообще — чем больше ядер, тем ниже частота.
Проведу аналогию с автомобилями:
Мало ядер, высокая частота — быстрая, отзывчивая и лёгкая Феррари
Много ядер, низкая частота — неторопливый 300-тонный карьерный самосвал
чем больше ядер, тем ниже частота
Смотря сколько ядер. Бывают 10-ядерные процессоры, частота ядер которых выше, чем у 4-ядерного.
неторопливый 300-тонный карьерный самосвал
Нет здесь прямой аналогии. Процессор выполняет вычисления. У многоядерного процессора могут быть наборы инструкций, позволяющие выполнять вычисления быстрее, чем процессор, у которого меньше ядер, и не имеющий таких наборов инструкций. У них могут быть разные объемы кэшей и прочие факторы, влияющие на скорость вычислений.
Смотря где и в какой работе. Если сидеть часами в одной эксельке, играть или гыгыкать над котиками в ютубе, то да, нужно пару ядер и выше частоты.
А если работать, когда запущена идея, эклипс, что-то фоном собирается в локальном гитлаб-раннере, ты в это время дебажишь, еще в это же время открыто 10-20 активных вкладок, дока в редакторе, еще поднято всё тестовое рабочее окружение (которое влезает в 256 гигов оперативки, конечно) ... - вот тут 20-40 ядер вне конкуренции. Ах, да, это только одна виртуалка - а их 3 на машине-хосте - одна с виндой, одна с текущим дебианом, и одна с астрой, чтобы тестировать совместимость клиента со старыми дистрами - все три имеют свою видяху и объединены в единый рабочий стол посредством barrier. И все это работает без лагов и фризов. На десктопе такое нереально собрать (или конски дорого), только на серверном железе.
Ну, сами считайте, если у вас будет солюшн в VS собираться в разы быстрее, даст вам это больший комфорт или нет. Особенно учитывая, что солюшн может легко собираться несколько десятков минут.
Или, например, мне нужно запускать одновременно пару (а то и тройку) клиентов онлайн-игр, при этом в фоновом режиме работает виртуальная машина (с совсем другой задачей, не относящейся к играм). На 6 ядрах это будет совсем-совсем впритык, отчего я в своё время и брал топовый 8-ядерник.
Всё, указанное в статье, несомненно верно и полезно. Только реальная причина тормозящих игр скорее не в кэшах, а в культуре разработки, которая приводит к большим алгоритмическим ошибкам, как было в GTA Online с квадратичным чтением текстового файлика.
Игры оптимизируют по параметру цены разработки и по возможности сделать рекламный ролик, а не по реальным FPS у игрока.
Хорошая статья. Когда увидел про физику в 30 фпс, вспомнился элден ринг с его жестким локом на 60фпс с привязанными фреймами того же парирования 🙈.
и использование таких операндов приводило к тяжеловесным ассемблерным инструкциям приведения типов от одного к другому
Только вот в современном мире почти везде используются two's-complement-числа, для которых это приведение типов — no-op. И, вероятно, бенчмарки показывают такую разницу не из-за разности типов, а из-за, собственно, unsigned, код вокруг которого, предположительно, хуже поддаётся оптимизации из-за допустимости его переполнения с точки зрения стандарта (в отличие от signed, переполнение которого не определено стандартом)
Совершенно верно, дополнительный код сильно упростил логику cpu, в случае беззнаковых типов переполнение вызывает возврат к началу численного диапазона, для знаковых технически поведение программы не определено, но в с/c++ зачастую происходит также возврат. Это мешало, и мешает и будет мешать, приводя к ошибкам, ловить такие ошибки хочется но дорого.
Я просто пытался сказать, что содержимое заголовка и текста абзаца не вполне соответствует бенчмарку (ибо дело не в согласовании signed/unsigned, а конкретно в unsigned, код с которым, предположительно, окажется медленнее, даже если везде будет unsigned)
func_signed_signed(int): # @func_signed_signed(int)
mov eax, 10
ret
func_unsigned_signed(int): # @func_unsigned_signed(int)
xor ecx, ecx
cmp edi, -10
mov eax, 10
cmovae eax, ecx
ret
Ваш цикл кстати превращается в... ничто.
использование таких операндов приводило к тяжеловесным ассемблерным инструкциям приведения типов от одного к другому.
О каких тяжеловесных инструкциях идёт речь?
Таких инструкций просто не существует, т.к. делать ничего не нужно.
Есть только инструкции расширения знака (extsb,extsh,extsw). Двухтактовые, как и любые простые ALU операции.
Единственный косяк PPE в этом плане был в том, что знаковая загрузка из памяти с расширением знака (lha, lwa) делалась микрокодом, который блокировал конвейер на пару десятков тактов, поэтому компилятор пихал пары lwz / extsw.
При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает.
Что за чушь. Разница между 30 фпс и 120 фпс очевидна даже человеку, который первый раз сел играть в компуктерн. Да и тикрейт в онлайн дрочильнях уже давно 120\с всюду.
Простите, а где вы увидели в тексте заявление о том, что эта разница незаметна? Там написано совсем не это
Когда пишется "чисто маркетинговый показатель", подразумевается что это буллшит. Это не буллшит.
Давайте я переформулирую мысль из поста:
Картинка в 200 фпс в играх не являются достаточными условием для плавного геймплея, поскольку для него нужна ещё и обработка физики с высокой частотой
И под "чисто маркетинговый показатель" подразумевалось именно несоответствие одного другому, поскольку этот показатель не может отобразить плавность/комфорт игры в отрыве от частоты обработки физики, который не указан. И такие показатели как раз и принято называть "чисто маркетинговыми"
Вы же, прочитав текст, не вникая в его смысл, сформировали у себя в голове почти противоположный тезис "картинка в 200 фпс в играх не являются необходимым условием..." и оспариваете его, хотя он заявлен не был автором
Я может чего-то не понимаю, но кадр в игре строится после обновления мира. Я не верю, что есть какая-то логика "Ровно 30 раз в секунду обсчитываем физику, а кадр рисуем 200 раз в секунду".
Конечно можно обсудить фреймген типа DLSS3, но там этого нет.
Про физику вот тут написано хорошо https://www.google.com/amp/s/habr.com/ru/amp/publications/801479/
Кратко, время графического фрейма плавает, один фрейм 14 второй 18, в среднем 16 получим. Человек этого не замечает, картинка плавная, но если вы попробуете на таких качелях стимулировать коллизии то получите, что объекты пролетают друг в друга, или пули пролетают сквозь стены. Поэтому физике в играх больше важна стабильносмть, т.е. симуляция системы на стабильных 30фпс будет более достоверной чем на нестабильных 60 или 100
Внутри все работает без привязки к фпс, иначе мы будем иметь кучу проблем с подсистемами игры, все апдейты идут с delta time. Если отработали раньше времени сл фрейма, то просто ждём его наступления, но обычно все немного сложнее, в конце текущего фрейма можно считать части следующего, будущие анимации, грузить текстуры, считать сл фрейм физики. Тикрейт больше относится к сетевой части, обычно это показатель количества пакетов пришедших от сервера, он конечно связан с рендером, физикой и др, но опосредованно, конечно разница будет, попробуйте построить кривую по 3 точкам и по 60. в играх также применяется симуляция наперёд, а когда приходят реальные данные они апроксимируются на уже вычисленные значения.
При том, что все эти 30 — 60 — 120 — 200 фпс в играх, это чисто маркетинговый показатель, это время с которой движок может создавать фреймы для видеокарты, но движок это не только картинка, есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает.
Ещё на первых чемпионатах Quake, чтобы выполнять все трюки требовался FPS выше 100, и чем выше тем, лучше, а высокий FPS даёт ощутимые преимущества в бою против человека.
есть физика — а она как работала на 30 фпсах 10 лет назад, так и работает
А почему физика до сих пор на 30 fps работает? Её невозможно дальше оптимизировать?
И по поводу загрузки уровня в редактор за 5 минут вместо 8 - как-то все равно сурово. Откуда такие жуткие времена? Графика для текстур долго грузится, объемы данных большие?
Я это к чему: если, например, поиск в каких-то контейнерах при загрузке долго производится, может, для ускорения поиска дополнительно какие-нибудь map добавить, пусть даже при некотором увеличении объема памяти? ИМХО, в редакторе экономия памяти менее важна, чем в самой игре.
Физику можно и чаще считать, в автосимуляторах видел цифры порядка 400- 1600 шагов физики в секунду.
Но в остальных играх высокая точность не сильно нужна, достаточно чтобы оно выглядело более-менее правдоподобно.
Физику можно и чаще считать, в автосимуляторах видел цифры порядка 400- 1600 шагов физики в секунду.
Только это поставит CPU на колени. Я ради интереса на днях включил физику в настройках игры 2011 года. Игра честно предупредила, что ни выделенной железки для обсчёта физики, ни видеокарты NVIDIA с поддержкой PhysX, не обнаружено и начала тормозить так, что играть стало абсолютно некомфортно.
Только это поставит CPU на колени
С чего бы? Вы тёплое с мягким не путайте. Речь о физике автосимуляторов, а не о PhysX.
Физику 300-400Hz легко тащит jaguar на превген консолях. И ничего там не тормозит.
Assetta Corsa - 333Hz
Forza Motorsport 8 - 360Hz
Colin McRae: Dirt - 1000Hz (игра 2007г)
iRacing
https://www.iracing.com/physics-modeling-ntm-v7-info-plus/
11) What is the sampling rate of your physics model?
360 Hz, is the short answer. But we calculate forces twice per update step, so we do player tire force calculations at least 4x2x360 = 2880 times per second. More if some of the tires are contacting multiple surfaces (i.e. curbs). We use IEEE floats.
В редакторе (возьмите что Юнити, что Анриал) все объекты, их свойства, зависимости, ссылки хранятся в виде текста, оно нечитаемое (ну т.е. читаемое конечно, но не для человека), собственно загрузка и обработка этих данных требует прилично так времени, описание объектов на одном слое занимает под 100мб, таких слоев на уровне под 50 и больше (каждый дизайнер работает на своем слое), чтобы не мешать соседям. Можно конечно хранить это все в бинарном виде, но профит не особо большой, а проблем с поддержкой своего формата намного больше. 5 минут это очень быстро, поверьте, загрузка большого уровня в Unreal спокойно улетает за 15 минут
В современных играх физика чаще всего настолько рудиментарна, что и 30 фпс хватает
Имхо все эти игры дуракавалянье. Потому москвичей и ненавидят. Предлагаю для отрезвления использовать 486. Некоторые за всю жизнь кроме экрана ничего не видели, молодежь не умеет писать по русски, и это длится годами.
Что-то нативный strlen у вас как-то плохо работает. Вроде как в современных рантаймах он по самое не могу оптимизирован. Очень странно. В clang там вообще вроде интринсинк '_builtin_strlen' подставляется.
Msvc 19.2.xxx, xbox rel, /Ox, на кланге не такой разрыв, но тоже в пару раз выигрыш. Интринсики есть не для всего, хороший суммарный выигрыш получается при переводе всех функций. Сейчас посмотрю на quickbench другие компилирены.
Del
На счёт тригонометрических функций: видел в свежих версиях clang оптимизацию, когда они вычисляются во время компиляции, если аргументы - constexpr значения.
На счёт смешанных вычислений float/double: а зачем вообще нужен double в играх? Его точность для них как правило избыточна. Так что лучше его сознательно нигде не применять, а случаи вида *= 2.0 отлавливать предупреждениями компилятора с рассматриванием предупреждений как ошибок.
Недавно на хабре была статья о разработке эмулятора солнечной системы в натуральных размерах и там пришлось очень много хитростей придумать чтобы решить проблему с недостаточной точностью флоатов. И автор в одном месте пишет что-то вроде " понятно зачем в движках есть возможность использовать даблы". Хотя ситуация конечно очень специфичная но тем не менее
Применение фильтров и поиск объектов на сцене становится затратной задачей и занимает секунды реального времени
Вот чтобы избежать такой проблемы был изобретён подход ECS. В нём компоненты разнородных объектов хранятся последовательно, что улучшает кеш-локальность при выполнении алгоритмов с перебором определённых компонентов.
У ecs куча других проблем, которые не перекрывают профит от скорости, например необходимость переобучения коллег, физическое разделение данных и логики, лавинообразный рост зависимостей между системами, неявные зависимости, которые приходится костылить, постоянное активное перемешивание кеша, невозможность отладки в студии, надо писать свои дебагеры, еcs непереносимы между проектами за исключением самых простых кейсов. Хорошо сделаный сценграф не сильно уступает по перфу. У каждого подхода есть свои плюсы, зачем тащить в движок неоптимальную вещь ради прозрачных 10% перфа. Вы пока этих процентов добиваетесь потратите время, которое бы ушло на разработку игры.
Самые лучшие и важные оптимизации - алгоритмические. Они могут дать прирост и в разы и на порядки. О чём очень кратко и незаслуженно мало сказано в последнем абзаце. Много раз встречался, когда для программистов оптимизация - это только вот эти технические приёмы, но это не так. Они способ выжать последние проценты.
Статья очень интересная, но при чём тут это?
загружаемые 100 гигабайтные игры
Основной объём игр — ассеты. Да, они могут быть лишними, забытыми и т.д. Но если вы хотите, грубо говоря, две рубашки персонажу вместо одной, придётся добавить текстуру второй рубашки, что уыеличит объём данных. Я, конечно, играл в .kkrieger, но это как-бы совсем не то, о чём разговор
Чем больше размер данных, тем дольше они грузятся. Проблема "двух рубашек" давно уже не стоит, для текстур давно есть инструменты, которые оставляют только изменения. А вот проблема уникального генеративного контента, например из Houdini есть, два одинаковых с виду камня сделаные в этом прекрасном инструменте, без сарказма, имеют разную геометрию, разные текстуры, разные нормали, которые тулзами практически не унифицировать.
Эта проблема тоже решена. Не надо хранить сгенерированные штуки. Надо их генерировать на лету. Есть проблема скорости генерации, но она решится сама собой со временем.
Публикации
И целых 20 ядер мало