Сообщение Re[9]: Ядро на C++ от 29.12.2016 13:53
Изменено 29.12.2016 13:57 AlexGin
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Q>Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++!
Q>Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит.
В том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача НЕ главная.
Там будут прежде всего рассчёти по определённым алгоритмам и формулам, а скорость — некритична.
По крайней мере, в нашем проекте было именно так.
Q>Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса.
То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
В том проете, в котором мы работали, на НЕуправляемом коде фактически была вся игра.
Только некоторый "предбанничек" был на Unity и C#.
Q>Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Не знаю, с Xenko не работал.
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Q>Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++!
Q>Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит.
В том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача НЕ главная.
Там будут прежде всего рассчёти по определённым алгоритмам и формулам, а скорость — некритична.
По крайней мере, в нашем проекте было именно так.
Q>Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса.
То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
В том проете, в котором мы работали, на НЕуправляемом коде фактически была вся игра.
Только некоторый "предбанничек" был на Unity и C#.
Q>Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Не знаю, с Xenko не работал.
Re[9]: Ядро на C++
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Q>Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++!
Q>Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит.
Для Unity и C# вероятно — причина снижения производительности именно в мостике управляемый<->НЕуправляемый, наличие GC и т.д.
Но в том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача на мой взгляд НЕ главная.
Там будут прежде всего рассчёты по определённым алгоритмам и формулам, а вот скорость — некритична.
По крайней мере, в нашем проекте было именно так.
Q>Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса.
То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
В том проете, в котором мы работали, на НЕуправляемом коде фактически была вся игра.
Только некоторый "предбанничек" был на Unity и C#.
Q>Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Не знаю, с Xenko не работал.
Q>Здравствуйте, AlexGin, Вы писали:
AG>>Разработка на Unity и C# — проще, менее трудозатратно — однако, НЕ даст той динамики игры, как приложение на C++!
Q>Не в последнюю очередь, как ни парадоксально, это из-за того, что ядро-то движка Unity написано как раз на C++!
Q>Типа, тяжёлые вычисления вынесем в натив, и всё будет ок? А вот **й, накладные расходы на маршаллинг из управляемого кода в неуправляемый в методах Update() тысяч объектов каждый кадр убивают весь профит.
Для Unity и C# вероятно — причина снижения производительности именно в мостике управляемый<->НЕуправляемый, наличие GC и т.д.
Но в том-то и дело, что для приложений такого рода, написанных на Unity, оптимизация по скорости — задача на мой взгляд НЕ главная.
Там будут прежде всего рассчёты по определённым алгоритмам и формулам, а вот скорость — некритична.
По крайней мере, в нашем проекте было именно так.
Q>Иногда игровой цикл выносят наоборот в управляемый код (маршалит в неуправляемое ядро только один game object, обновляющий все остальные), что в некоторых случаях даёт буст перформанса.
То есть — причина высокого перфоманса — всё-таки "неуправляемое ядро" на старом добром C++
В том проете, в котором мы работали, на НЕуправляемом коде фактически была вся игра.
Только некоторый "предбанничек" был на Unity и C#.
Q>Другой, непопулярный кроссплатформенный движок Xenko изначально написан на управляемом языке. Когда я в последний раз сравнивал с Unity на Андроиде, производительность Xenko была выше (я измерял только скрипты, про отрисовку не скажу).
Не знаю, с Xenko не работал.