Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>>>Откуда взяться дотнету в нейтивном коде?
S>> Легко. .Net Core для отладки используется
V>Не используется.
S>> Искать неохота. Но старай вариант
S>>https://docs.microsoft.com/ru-ru/archive/msdn-magazine/2015/windows-10-special-issue/microsoft-net-net-and-universal-windows-platform-development
V>Речь шла про Unity.
V>Нет в Unity никакого дотнета.
Угу IL2CPP как бы говорит, что используются дотнетовские сборки и легко можно делать отладку используя Core Clr
https://learn.unity.com/tutorial/fixing-performance-problems#5c7f8528edbc2a002053b594
Unity сначала компилирует наши скрипты на язык, называемый Common Intermediate Language (CIL). CIL-это язык, который легко компилируется в широкий спектр различных языков машинного кода. Затем CIL компилируется в собственный код для нашего конкретного целевого устройства. Этот второй шаг происходит либо при создании нашей игры (известной как компиляция с опережением времени или компиляция AOT), либо на самом целевом устройстве непосредственно перед запуском кода (известной как компиляция just in time или JIT-компиляция). Использует ли наша игра компиляцию AOT или JIT, обычно зависит от целевого оборудования.
То есть JIT то используется! AOT нужен в основном для айфона, а на андроиде может прекрасно работать и как Xamarin на Mono
V>>>У них сборщик не из дотнета, известный консервативный https://www.hboehm.info/gc/.
V>>>Г-но.
S>>Но могут и коровский подключить.
V>Я тоже теоретически могу в космос полететь.
V>Но пока не полетел.
V>Вот там так же.
Они писали, что исследуют эту возможность, а ты в космос потелишь, с вероятностью близкой к нулю, ибо даже к этому и не готовишься.
V>>>ИМХО, именно поэтому было выбрано генерирование в исходники С++, т.к. это автоматизирует отладку по исходникам C# даже с учётом конверсии исходников через свою приблуду.
S>>С++ выбран из-за оптимизирующих компиляторов. Тот же .Net Native точно так же и поступает и CoreRT dhjlt
V>.Net Native не имеет к Unity никакого отношения.
V>И иметь никогда не будет.
V>По крайней мере до тех пор, пока не научатся дешево размечать стек.
Угу. В .Net Native перетекло множество наработок из Mono. CoreRT тоже развивается в опенсорсе
V>DllImport — встроенный DllImport.
V>GetProcAddr — получение адреса символа из DLL вручную в unmanaged указатель на ф-ию и последующий вызов.
V>По стоимости примерно равны.
Ну делается это один раз.
V>Одним словом, вызов нейтивного кода из managed относительно дорогой.
V>Но вызов managed кода из нейтивного — вообще ж-па, а в графических приложениях и то и другое активно юзается.
Чем жопа то?
https://docs.microsoft.com/ru-ru/dotnet/core/tutorials/netcore-hosting
Получаем ссылку на статическую функцию из нативного кода.
https://habr.com/ru/post/304482/
V>А я еще так думаю, что проблема в новом JIT, который тщательно оптимизирует ф-ии только после многих вызовов.
V>В дотнете до 3.1 такого не было.
V>Т.е., может захватываться адрес самого первого, неоптимизированного варианта ф-ии, который был в момент загрузки кода JIT-ом и затем вызов происходит только по этому адресу.
V>Это объясняет разницу м/у Ptr from delegate и Unmanaged func ptr.
V>В первом случае делегат держит ссылку на на managed указатель на метод и, когда джит подготовит новый метод, переключит указатель на него.
V>Во втором случае остаётся указатель на неоптимизированный вариант первоначальной JIT-компиляции.
V>(если любопытно, могу в "Дотнете" выложить тесты целиком с пояснениями)
V>В общем, опять облом-с.
V>А я серьезно на этот указатель на функцию рассчитывал. ))
Это все понятно. Поэтому ждем CoreRT. A для UWP все прекрасно работает. Только он не опенсоурс.
А проблемы JIT давно известны. Но здесь уже стоит делема в скорости разработки или выжимать миллисекунды, там где это не нужно.
Нужно все считать. И большинству кто использует облака это не ахти то и нужно.
Больше интересно многим как обфускатор, а не для увеличения скорости
Ну и смотрим куда собираются двигаться Unity.
Предупреждение для разработчиков о грядущих критических изменениях в движке
.Net 6 и .Netstandard 2.1 . Казалось бы причем тут DotNet
