Войти
ПрограммированиеФорумФизика

Зачем Юнити своя физика ? (4 стр)

Страницы: 1 2 3 4 5 6 7 Следующая »
#45
0:26, 25 мар. 2019

bykabak
Я конечно ни когда не вникал в историю языков, но вроде как C# задумывался как развитие ООП выводя это дело на новый уровень за счет наследований. Ну и так же краем уха слышал что все эти плюсы уже давно анахранизм.
Сам лично я как то с Си практически не имел дела.


#46
1:06, 25 мар. 2019

sledo
> развитие ООП выводя это дело на новый уровень за счет наследований.
ООП уже автоматически имеет в себе наследование.
никакого нового уровня за счет наследований не может быть.

#47
4:22, 25 мар. 2019

bykabak
> нужно смотреть на asm кода и анализировать что и почему.

Ну с бубном плясать то есть, если по простому говорить. Собственно, это то самое, из-за чего в Unity принялись изобретать Burst-компилятор и частично переводить С++ в C#.

#48
(Правка: 12:39) 11:16, 25 мар. 2019

С# сипользует .NET так ?  NET по сути - обёртка, которая утежеляет код и размер, но код становится проще для программиста. Программисту не нужно париться с выделением памяти и чисткой проверкой типов данных и т.д.  Так же как код для разных платформ добавляет избыточность, чтобы всё работало одинаково на разных платформах.

Всё это убивает производительность готового продукта ( если речь идёт об играх , где скорость важна )

Все эти навесные "буферы" , "бамперы" и проверочки убивают скорость когда их много.  А их получается много.

Я сомневаюсь , что код на C# будет быстрее такого же по функционалу кода на С++.  Одинаковым по скорости - ДА, но не быстрее точно.

#49
(Правка: 15:37) 15:35, 25 мар. 2019

bykabak
>Latest commit e043871 on 2 Apr 2018
>Сейчас и Активно ?
Я ж написал: "сейчас активно делается вторая версия, доступна тоже на гитхабе" (https://github.com/bepu/bepuphysics2), в принципе ты бы это заметил если бы хоть до readme удосужился проскроллить крутанув колесико мыши один раз. Первая - feature-complete, и stable to use. Есть список игр где использовалась, так же используется в этом движке
Вторая - полный реврайт на .NET Core.

>C# в принципе медленный по сравнению с С++.
Ну да, немного по-медленее будет. Но и от рук многое зависит (насколько медленным будет в итоге) - https://mattwarren.org/2019/03/01/Is-CSharp-a-low-level-language/
Ну и плюс в .NET Core 3.0 ещё и SIMD интринсики завезли, так что игроделам будет полегче.

>NET по сути - обёртка, которая утежеляет код и размер
Ну не надо настолько упрощать в следствии незнания предмета :)

>Программисту не нужно париться с выделением памяти и чисткой проверкой типов данных и т.д.
Никто не запрещает тебе использовать unsafe контекст, если нужна "беспренцедентная" скорость.

#50
15:47, 25 мар. 2019

Да, для мобилок и некоторых программ где подходит физика на C# может и отлична эта физика. Собственно, все и кинулись на Unity из-за мобилок и потенциально большего рынка сбыта.

Да, для определённого круга задач всё и пишется.  Не все же спутники на Марс запускают. ;) 

#51
(Правка: 16:25) 16:21, 25 мар. 2019

1. Выделением памяти занимается менеджер памяти. Такой есть и в C++, и в C# (в Unity и Net Framework разные).

Тут особой разницы нет, кроме того что в Net Framework сборщик мусора держит кучу дефрагментированной, поэтому менеджеру памяти, чтобы выделить N байт, не требуется в этой куче искать свободное место подходящего размера, т.к. оно всегда одним большим непрерывным куском (про LOH я в курсе). Т.е. выделение памяти под новый объект в Net Framework мгновенное. В Unity куча не дефрагментируется, чтобы не тратить на это время, поэтому выделение памяти под новый объект там медленнее. В C++ куча тоже не дефрагментируется - это в принципе невозможно - и выделение памяти тоже не мгновенное.

2. Проверкой типов в C# занимаются компиляторы, т.к. это язык с относительно строгой типизацией. Во время исполнения кода контроля типов практически нет - всё уже заранее проверено. Есть несколько специфических случаев, когда проверка происходит в рантайме, но на скорость это не влияет, потому что критичный код так никто не пишет.

3. C# от С++ принципиально отличается только сборкой мусора. Далёкими от темы товарищами он обычно воспринимается как чудовище, которое постоянно жрёт ресурсы и тормозит. Когда пытаешься разобраться, почему на C# что-то работает медленнее чем ожидалось, то каждый второй начинает утверждать, что это сборщик мусора тормозит; а тормозит он, потому что сборка мусора - это говно; и язык тоже говно. А ты понимаешь, что сборщик мусора, скорее всего, ни разу и не запускался, потому что поводов не было. Проверяешь - так и есть, ни разу не запускался.

В С++ требуется удалять каждый выделенный в куче объект. Есть миллион объектов - надо каждый из них отдельно удалять, иначе здравствуй, утечка памяти. Создавать/уничтожать объекты в куче в плотном цикле - не очень хорошая идея. В Net Framework это без проблем - выделение мгновенное, а уничтожать не требуется - это работа сборщика мусора, который запускается только когда заканчивается место в куче, и ему по большому счёту всё равно, сколько в этой куче мусора - ему больше интересно количество живых объектов.

В Unity выделение памяти и сборка мусора не так эффективны, как в Net. Сборка мусора может доставлять проблемы, но существование моря игр показывает, что даже для рилтайма это не такая большая проблема, как можно подумать. А для нерилтайма вообще пофиг.

Какой подход быстрее, со сборкой мусора или без, в общем случае трудно сказать. Зависит. Подход со сборкой мусора проще, а гигиену памяти надо соблюдать и в C# и в C++.

4. Код на C#, чем бы он не компилировался, в конечном итоге преобразуется в нативный машинный код, который напрямую исполняется процессором. Можно взять какую-нибудь простую функцию на C# и C++ и посмотреть их дизасм. Без включения зверских оптимизаций они будут выглядеть похоже или даже идентично. С++ типа быстрый, потому что его компилятор может себе позволить тратить сколько угодно времени на оптимизации. JIT-компилятор Net Framework/Core/Mono такого себе позволить не может, и результат слабее. Burst-компилятор в Unity эту проблему решает, и у него вроде получается.

#52
16:29, 25 мар. 2019

Получается с++ = говно?

#53
(Правка: 16:39) 16:36, 25 мар. 2019

Откуда такой полярный вывод? Я бы сказал мягче: не идеал. Слово «говно» у меня зарезервировано за JavaScript, но это субъективно.

#54
16:59, 25 мар. 2019

alexzzzz
> Откуда такой полярный вывод?
ну указано много серьёзнейших проблем против восхваления си-шарп —- оттуда такой вывод.

#55
17:10, 25 мар. 2019

У C++ конечно есть свои проблемы, но ни одной из них в списке нет. То что в пунктах 1 и 3 - не хорошо и не плохо, а просто так есть.

#56
17:18, 25 мар. 2019

alexzzzz
> Код на C#, чем бы он не компилировался, в конечном итоге преобразуется в
> нативный машинный код, который напрямую исполняется процессором.
а во всех других языках это не так

#57
(Правка: 17:40) 17:37, 25 мар. 2019

Rikk
>Получается с++ = говно?
Ты видимо не читал, что alexzzzz написал?
Что шарп, что плюсы - оба отличные инструменты. Выбирай, что к душе больше лежит.
Хочешь сам быть в ответе за память? Используй плюсы. Не хочешь? Используй шарп.
При этом, используя шарп - ты попрежнему можешь париться о памяти, он у тебя это не забирает, а просто скрывает за GC. Убирает от тебя лишние заботы, если они тебе не нужны и ты просто хочешь быстрее получить результат, а не делать например обёртки над всякими memcpy и размышлять неделями над тем, какой префикс для своих обёрток выбрать чтобы по итогу опять всё переписать ибо не феншуй получился. И это не говоря про всякие char/wchar/bstr/CComBSTR/CString/LPCTSTR/...
Хочешь понимать что происходит под капотом в отношении памяти? Пожалуйста. Не нужно - можно не понимать, всеравно всё будет работать, а медленее или быстрее - ну, ты ж все-таки код пишешь, а не язык за тебя его пишет, и надо понимать что последний не палочка-выручалочка который сделает тебе гипер-шустрый код, и это же справедливо и для С++.
C# не запрещает тебе писать быстрый код, если ты этого хочешь, и все нужные инструменты для этого (ну, как минимум: Span, stackalloc, ref/in/out, unsafe) он тебе предоставляет. Ну и конечно же, как писать максимум GC allocation-free кода - вообще отдельный топик, разобравшись в котором сможешь почувствовать себя вполне себе С++-ником :)

#58
17:38, 25 мар. 2019

> а во всех других языках это не так

1. Это так не во всех языках. Есть и интерпретируемые. В основном специализированные. Но у того же Питона интерпретаторы байт-кода, кажется, до сих пор в ходу наравне с компиляторами.

2. Факт того, что C# транслируется в IL-байткод некоторыми воспринимается так, будто этот байткод потом в рантайме интерпретируется, и от этого всё тормозит, потому что не может не тормозить. Так никогда не было, но миф существовал и до сих пор встречается.

#59
19:52, 25 мар. 2019

Kinjal
Да, я именно про это.

Страницы: 1 2 3 4 5 6 7 Следующая »
ПрограммированиеФорумФизика