Size: a a a

Compiler Development

2020 June 03

M

MaxGraey in Compiler Development
Alexander Tchitchigin
В соседнем чате зашёл разговор про GC и игры. Мне на этот счёт давно уже подумалось, что внедрение very low pause GC в новых JVM (Shenandoah GC и кто там ещё) вкупе с и так давно дофига быстрым JIT и оптимизированным по выделению памяти и переиспользованию объектов кодингом в недрах движков, сделает их пригодными для очень широкого круга игр, кром там самых навороченных AAA блокбастеров. Предположительно, GraalVM сможет и ещё расширить спектр платформ для тех, кому очень нужно.
Или у меня слишком поверхностный и оптимистичный взгляд?
Это немного оффтоп, но все же отвечу
C физикой не так все просто. Во первых она чаще всего считается на CPU, потому что так проще, а так же потому, что конвееры GPU и так нагружены др предела. Плюс там нельзя использовать вариативную дельту а только фиксированное dt, так как дифференцирование по вариативному dt пипец как сложно и делают обноврение скажем раз в 8ms (30fps) и если частота кадров значительно выше 30 то делают просчет дважды или более (это нормально), если ниже 30 то это фрейм (фреймы) для просчетов физики дропуют и тогда возможны глюки которые очень часто можно наблюдать в играх, когда например модель игрока проваливается в пол, застревает в стене или ее крючит, размазывет и т д. Так вот для GC с задержкой даже в 8-10 мс шанс что такое случиться очень высок скажем так
источник

AT

Alexander Tchitchigi... in Compiler Development
MaxGraey
Это немного оффтоп, но все же отвечу
C физикой не так все просто. Во первых она чаще всего считается на CPU, потому что так проще, а так же потому, что конвееры GPU и так нагружены др предела. Плюс там нельзя использовать вариативную дельту а только фиксированное dt, так как дифференцирование по вариативному dt пипец как сложно и делают обноврение скажем раз в 8ms (30fps) и если частота кадров значительно выше 30 то делают просчет дважды или более (это нормально), если ниже 30 то это фрейм (фреймы) для просчетов физики дропуют и тогда возможны глюки которые очень часто можно наблюдать в играх, когда например модель игрока проваливается в пол, застревает в стене или ее крючит, размазывет и т д. Так вот для GC с задержкой даже в 8-10 мс шанс что такое случиться очень высок скажем так
Во-первых, помнится, у Shenandoah задержка меньше, во-вторых, для физики по факту же всё равно подрубают какой-нибудь Bullet, написанный на плюсах. Т.е. на Java-код ложится только связывание всего этого в кучу, игровая логика и прочий bookkeeping. Вкупе с low-pause GC и JIT должно работать со страшной скоростью, нет?
источник

AT

Alexander Tchitchigi... in Compiler Development
В смысле, эти GC, которые я имею в виду, вообще concurrent, т.е. работают одновременно со всем остальным, а stop-the-world паузы у них ~10 __микро__секунд (AFAIR).
источник

M

MaxGraey in Compiler Development
На сколько я знаю GC для Java нет таких задержек. Там порядка 60-100 мс для Shenandoah. Хотя может что то и изменилось уже
источник

λ

λoλdog in Compiler Development
Alexander Tchitchigin
Во-первых, помнится, у Shenandoah задержка меньше, во-вторых, для физики по факту же всё равно подрубают какой-нибудь Bullet, написанный на плюсах. Т.е. на Java-код ложится только связывание всего этого в кучу, игровая логика и прочий bookkeeping. Вкупе с low-pause GC и JIT должно работать со страшной скоростью, нет?
Вызов плюсов из джавы не оч хорошо работает
источник

λ

λoλdog in Compiler Development
Alexander Tchitchigin
В смысле, эти GC, которые я имею в виду, вообще concurrent, т.е. работают одновременно со всем остальным, а stop-the-world паузы у них ~10 __микро__секунд (AFAIR).
Там ключевое слово негарантированно
источник

AT

Alexander Tchitchigi... in Compiler Development
λoλdog
Там ключевое слово негарантированно
Что не гарантировано?
источник

λ

λoλdog in Compiler Development
Хотя ситуация прям со stop world должна случаться не часто
источник

M

MaxGraey in Compiler Development
Вот на хабре пишут даже ZGC может гарантировать разве что не более 100 мс и с ним огромные проблемы:
https://habr.com/ru/post/477692/
источник

AK

Andrei Kurosh in Compiler Development
Alexander Tchitchigin
Учитывая, к тому же, что всё больше и больше heavy lifting делается шейдерами...
Шейдеры используются в основном для графики, но помимо нее есть еще куча вещей, который на GPU делать невозможно или неудобно - физика, pathfinding, сетевое взаимодействие, обсчет непосредственно игровой логики и всякие ECS...
источник

AT

Alexander Tchitchigi... in Compiler Development
Andrei Kurosh
Шейдеры используются в основном для графики, но помимо нее есть еще куча вещей, который на GPU делать невозможно или неудобно - физика, pathfinding, сетевое взаимодействие, обсчет непосредственно игровой логики и всякие ECS...
Учитывая, сколько сетевого кода пишется на Java, это не выглядит убедительным аргументом! 😃
источник

AT

Alexander Tchitchigi... in Compiler Development
А игровую логику вообще обычно на скриптовых пишут.
источник

AK

Andrei Kurosh in Compiler Development
Alexander Tchitchigin
Учитывая, сколько сетевого кода пишется на Java, это не выглядит убедительным аргументом! 😃
Не, я как раз поддерживаю мысль, что управляемый язык с быстрым GC для игровых движков был бы крайне актуален. Шейдеры на нем писать нельзя, но есть масса вещей кроме шейдеров, которые можно таким образом улучшить
источник

λ

λoλdog in Compiler Development
Alexander Tchitchigin
Учитывая, сколько сетевого кода пишется на Java, это не выглядит убедительным аргументом! 😃
А там стараются делать минимум аллокации
источник

λ

λoλdog in Compiler Development
И все на байтбуферах или не стеке
источник

λ

λoλdog in Compiler Development
Andrei Kurosh
Не, я как раз поддерживаю мысль, что управляемый язык с быстрым GC для игровых движков был бы крайне актуален. Шейдеры на нем писать нельзя, но есть масса вещей кроме шейдеров, которые можно таким образом улучшить
Ну вообще в ue есть сборка мусора))
источник

AK

Andrei Kurosh in Compiler Development
λoλdog
Ну вообще в ue есть сборка мусора))
В Unity тоже есть
источник

AT

Alexander Tchitchigi... in Compiler Development
λoλdog
А там стараются делать минимум аллокации
Удивительно, но во всех игровых движках (даже на C++!!!) стараются делать минимум аллокаций и максимум переиспользования объектов. И в сетевом коде тоже, да.
источник

M

MaxGraey in Compiler Development
λoλdog
Ну вообще в ue есть сборка мусора))
Там оно очень своеобразное и только для UObject
источник

λ

λoλdog in Compiler Development
MaxGraey
Там оно очень своеобразное и только для UObject
Ну да
источник