Здравствуйте, vdimas, Вы писали:

V>Это следствие невозможности боксирования.
V>Следствие невозможности располагаться в полях не ref-struct типов.
Я в курсе — но, тем не менее, ограничение такое есть.

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

V>Случаев сразу несколько.
V>Раньше был доступен stackalloc только под примитивные blit-типы.
V>Например, делаешь byte * b = stackallock byte[N], затем приводишь к указателю на структуру.
V>Потом стало можно привести к управляемой ref-ссылке на структуру через CompilerServices.Unsafe.
V>В последней версии C# можно делать stackalloc пользовательских структур, которые вдоль всей иерархии агрегации состоят или из простых типов или структур, состоящих из простых типов.
V>Т.е. структуры, попадающие под ограничение unmanaged.
V>В т.ч. в теле которых располагаются inplace-массивы примитивных типов или тоже unmanaged структур.
Ага, вы говорите про "массивы структур". Но ведь с ними и до этого особенных проблем не было — ну, разве что, кроме случаев, когда сама структура не нужна за пределами текущего фрейма стека, и не хочется нагружать GC.
Я-то имел в виду работу с flexible array member https://en.wikipedia.org/wiki/Flexible_array_member

V>>>Чтобы GC игнорировал стек нейтивных вызовов.
V>>>Т.е., возможна зебра вглубь всех вызовов:
V>>>- из управляемого кода в нейтив;
V>>>- оттуда приходит колбэк в управляемый код (многие перечисления в системных АПИ так работают);
V>>>- из этого фрейма опять вызывается что-то в нейтиве.
S>>Ну в вашем-то случае весь метод — это инкремент лонга по указателю. Никаких колбэков, никаких зебр.

V>У меня просто бенчмарк различных способов вызова ф-ий.
V>А ты спрашивал, зачем замыкается стек перед вызовом нейтивной функциональности.
V>А как GC должен знать, где в стеке управляемые данные, а где игнорить?
Программист ему подскажет, где можно безопасно игнорить, при помощи SuppressGCTransition.

V>Стек замыкается в любом случае, т.к. GC stop world никто не отменял.
Для конкретного метода с инкрементом отключение GC Transition ускоряет вызов в натив вдвое. Если вычитать baseline — то втрое.
Для часто вызываемых микро-методов типа "набъём команды в буфер" — самое то.

V>Средней руки приложение может компиляться под AOT iOS несколько минут, сколько-нибудь большое — десятки минут.
V>Поэтому, всё это херня собачья, гнаться за хотспотом.
Не уверен.

V>Над разрабывать либы так, чтобы они были готовы к нейтивной компиляции потом, а клиент при публикации своего приложения пусть запускает АОТ-оптимизатор.

V>Ну, у нас зато тоже в некоторых проектах тонны статического-справочного кода, вот на такх проектах разница видна хорошо.
V>И что характерно — если эти "справочные" данные бинарно сериализовать (не встроенной бинарной сериализацией, которой теперь тоже нет в .Net Core, а просто ручками), сохранить в ресурсах, а потом при старте прочесть — это занимает примерно 30 ms. А в исходном виде добавляло примерно 400 ms.
Непонятно, откуда тормоза.

S>>Это для десктопа. А для любимого мной бэкенда важен именно хотспот, т.к. никакой AOT не предскажет реальную нагрузку.
V>А толку, если нагрузка может меняться?
Ну так для того хотспот в джаве и умеет повторно джиттить уже отджиттенный код. Нагрузка поменялась => метод перекомпилировали.
V>В нейтиве для этого отродясь было PGO.
V>К АОТ его тоже надо прикручивать.
У PGO ровно та же самая проблема — устаревание данных.

V>Хотя, АОТ хорош тем, что не рассматривает типы как открытые, хотя бы по виртуальности/наследованию.
Это как это он так не рассматривает? А если я динамически код сгенерю? А если будет подгружена новая сборка?

V>Плюс, у него достаточно времени на всевозможные оптимизации.
Для "настольного" применения — согласен, АОТ нужен. А для серверсайда, когда приложение живёт неделями, выделить 1% времени на дооптимизацию даст столько времени, что никакому АОТ столько не дадут.
V>Т.е. и дефолтная оптимизация может много чего дать.
Да для начала надо бы, конечно, просто глупостей не делать. Например, всё таки оптимизировать порождаемый IL.
V>Просто непонятно — когда это всё будет в наличии! ))
Отож.

V>Просто это был бы не Рослин, а портированный на шарп плюсовый компилятор.
V>По моему опыту, портирование кода из С++ в дотнет тривиальное (это обратно нетривиально), у меня получалось портировать примерно 2 тыс строк в день.
V>Если хотя бы 4-5 человек навалятся, первый шарповый компилятор на шарпе можно было бы получить примерно за неделю.
Ну ХЗ. Почему-то они так делать не хотели.

V>Просто они вообще с 0-ля его писали.
V>Наглухо.
V>Похоже, еще и учились писать компилятор в процессе, бгг...
V>Заодно похерили ранее сделанные вложения в уже имеющийся компилятор.

V>Детсад, штаны на лямках.

V>Я же почитывал Липперта — он нифига не спец в компиляторостроении.
V>Это отдельная дисциплина, не бог весть какая сложная, но в ней надо шарить...
V>Желательно, до начала разработки...
V>А эти гаврики с шашкой на танк помчались.
V>Результат известен.