Comments 24
опыт преобразования промежуточного языка в ILшта?
Тем не менее это всё тот же C#, где работают те же IDE, рефакторинги.
просто ужасное количество бойлерплейта) чем на С++
У вас есть пример такого бойлерплейта?
ребята, если мы скажем что юнити теперь кодируется на С++, наши пользователи просто испугаются и свалят
И действительно свалят в таком случае.
Говорю это имея опыт написания на Unity ECS тестовых игр и некоторый опыт профессиональной разработки с другими ECS
Безусловно, но перфоманс-ориентед ECS с вещами типа SoA/Архитипы нигде не будет удобнее и понятнее имхо, тем более в С++.
плюсовый код написанный левой пяткой по умолчанию работает в разы быстрее С#
довольно спорное утверждение, особенно в контексте HPC#. Пример! :)
Эээ не понимаю причем тут ECS. Если вы пишите игру, в которой у вас много объектов и затык в ЦПУ, то абсолютно не важно C# или C++ вам придется брать Data oriented подход и потратить много усилий, никакой компилятор С++ за вас ваш "простой код" не оптимизирует в SoA данные и т.п. А вообще вера в компиляторы плюсов слишком сильная у людей, попробуйте как-нибудь поупражняться на godbolt.org, чуть более сложный код (как в жизни ;-) и оптимизации идут лесом.
За счет них же и макросов можно и в ногу выстрелить :) ну и опять же — время компиляции отличается в разы. Ребята с юнити еще и дотюнили розлин (инкрементальная компиляция) что там вообще должно в теории на лету компилироваться всё (но просядет немного в llvm opt).
Unity.Physics.Collider* capsuleColliderForQueries;
{
Unity.Physics.Collider* colliderPtr = collider.ColliderPtr;
// Only capsule controller is supported
Assert.IsTrue(colliderPtr->Type == ColliderType.Capsule);
byte* copiedColliderMemory = stackalloc byte[colliderPtr->MemorySize];
capsuleColliderForQueries = (Unity.Physics.Collider*)(copiedColliderMemory);
UnsafeUtility.MemCpy(capsuleColliderForQueries, colliderPtr, colliderPtr->MemorySize);
capsuleColliderForQueries->Filter = CollisionFilter.Default;
}
Сильно это отличается от стрельбы себе в ногу в с++?
Ну хотя бы макросов нет ;-)
Не смог удержаться )) Статья выглядит как наглядная иллюстрация: "что только не сделаешь, чтоб не писать на c++":
… почти полностью обойтись без стандартной библиотеки (прощайте Linq, StringFormatter, List, Dictionary), запретить операции выделения (=никаких классов, только структуры), рефлексию, отключить сборщик мусора и виртуальные вызовы, а также добавить несколько новых контейнеров, которые разрешено использовать (NativeArray и компания).
проверки на границы масивов в рантайме, и нарекания на скорость компиляции — улыбнули )) опять забывают — компиляция продукта производится единожды, но продук запускается "миллионы раз".
Мы можем получать ошибки, связанные с выходом за границу при попытке доступа, получим отличные сообщения об ошибках, у на будет поддерживаться отладчик, а скорость компиляции будет такая, о которой вы уж и позабыли, работая с C++.
резюмируя:
Мне самому весьма нравится писать код на C#. Однако традиционный C# — не самый лучший язык с точки зрения производительности.
компиляция продукта производится единожды, но продук запускается "миллионы раз".
Правильнее сказать компиляция производится миллион раз, продукт запускается миллион раз. Почитайте https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
Хотя LLVM opt и llc/jit тоже не самые быстрые, но хотя бы убирается долгая фаза сбора плюсов для генерации IR. C# из коробки предоставляет их рантайму (читай llvm) хороший alias analysis для кода, и еще им был необходим контроль над оптимизациями грубо говоря по-методно. Вот этот метод максимально оптимизировать и векторизовать, а вот тут отключить все оптимизации, строгий расчет флотов и т.п.
Безусловно всё можно было сделать в С++ (насколько понял, ребята даже свой opt pass для векторизации пишут для LLVM IR) но С# — это основной язык в среде Unity, разумнее развивать его, а не предлагать C# юзерам Unity отдельную подсистему писать на плюсах (jobs).
Оказывается все просто: компилятору явно говорится что данные не пересекаются и можно векторизовать со спокойной душой. Так ли это сложно в С++, предназначенном для производительности, в статье не описано.
Мне кажется они пытаются решить неразрешимое противоречие: сделать простой и производительный инструментарий. Фишка в том, что простота всегда накладывает некие ограничения: ты можешь делать поверхностные операции, но не можешь уйти вглубь, иначе это становится сложно. А значит ты не можешь максимально эффективно распорядиться ресурсами, что значит невозможно достичь максимальной производительности.
В итоге, им приходится делать фактически сложное решение (нет сборщика мусора, везде опасные массивы, нет удобных плюшек C#, черт посмотрите их примеры, они просто ужасают), под эгидой простого решения — "..but it's still C#!!". Честно говоря не верится, что типичное Unity3D сообщество перейдет на эту парадигму. Это сообщество как раз таки и выросло из простоты и удобства инструмента.
Оказывается все просто: компилятору явно говорится что данные не пересекаются и можно векторизовать со спокойной душой. Так ли это сложно в С++, предназначенном для производительности, в статье не описано.
Пользователь компилятору этого не говорит.
ты можешь делать поверхностные операции, но не можешь уйти вглубь, иначе это становится сложно. А значит ты не можешь максимально эффективно распорядиться ресурсами, что значит невозможно достичь максимальной производительности.
Я не видел исходного кода Burst, но у ребята утверждают что у них полный контроль и предсказуемость над маппингом IL в LLVM IR. Понятно что можно так же держать полный контроль кодгена на С++, но как минимум нельзя сказать что они не могут "уйти вглубь".
В итоге, им приходится делать фактически сложное решение (нет сборщика мусора, везде опасные массивы, нет удобных плюшек C#, черт посмотрите их примеры, они просто ужасают), под эгидой простого решения — "..but it's still C#!!". Честно говоря не верится, что типичное Unity3D сообщество перейдет на эту парадигму. Это сообщество как раз таки и выросло из простоты и удобства инструмента.
Мне примеры не кажутся страшными — там вроде даже указатели не используются.
То, что это C# позволит шарить между скриптинговой средой и высокопроизводительными джобами юзерский ECS код. И все не-гцшные фичи языка можно свободно использовать.
Мне примеры не кажутся страшными — там вроде даже указатели не используются.
То, что это C# позволит шарить между скриптинговой средой и высокопроизводительными джобами юзерский ECS код. И все не-гцшные фичи языка можно свободно использовать.
А вы пробовали? Обычно хватает небольшого тестового проекта, чтобы осознать, что писать так как предлагается это страдание.
Стек DOTS: C++ & C#