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

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

V>>>Структуру АПИ можно сделать классом в C# и подавать по обычной ссылке, а можно сделать value-типом и подавать через ref, а можно сделать ref struct, т.е. ограничить время жизни на стеке. А можно просто IntPtr и заниматься сериализацией-десериализацией.
S>>По-моему, нормальный вариант — только один. Если API принимает struct, то мы и отдаём struct.

V>Или class, если требуется сохранить затем.
И сразу нарываемся на custom marshaller. Зачем?

V>Практически всегда, если данные не предназначены для последующего хранения, вплоть до того, что могут ссылаться на невалидную область памяти.
Хранение хранению рознь. У реф структ слишком много ограничений, поэтому использовать их захочется точечно.

S>>К сожалению, нормального способа работы со структурами переменного размера в дотнете/С# я не вижу.
S>>То есть можно сделать враппер вокруг byte[], который работает при помощи MemoryMarshal, и даже приемлемо по эффективности (после JIT все эти обращения к MemoryMarhshal.Cast<byte, IntPtr>(data.AsSpan().Slice(sizeof(int))[index] превращаются в in-place инструкции типа LEA), но код выглядит, мягко говоря, нечитаемым.

V>В select в линухах подаются битовые массивы, поэтому stackalloc решает вопрос.
V>Длина битовых массивов идёт первым аргументом — как максимальный номер хендла.
Ну это тривиальный частный случай. Как только мы встречаем что-то сложнее примитивного массива интов, начинаются танцы с бубном. Так-то можно и дотнетовый массив отмаршаллить без копирования.



V>>>Можно пройтись глазами по хелперу нейтивного вызова, ссылку я дал.
V>>>Сравнить с вызовом managed-кода, когда просто в RAX загружается значение переменной и просто делается call RAX.
S>>Ну по идее так и должно быть. Если маршалинга нет (а для достижения этого есть все предпосылки), то должно делаться именно это.

V>А как же замкнуть фрейм стека для GC?
А зачем?

V>Такие у меня тоже есть в текущем дотнете, но по-мелочи.
V>В RuiJIT сейчас чёрт ногу сломит, его надо серьёзно переделывать.
Я на своём уровне некомпетентности вижу только одну глобальную проблему: нет, как такового, хотспоттинга. Tiered compilation выглядит как жалкое подобие левой руки. Может, оно и блеснёт в какой-то момент (например, развязав руки дорогостоящим оптимизациям в Tier1), но мне кажется, что как-то это всё очень вяло. Чтобы выжимать из managed code максимум, надо уметь помимо "ой, давайте при первом проходе просто отдавать говнокод" делать очень много profile-based вещей, типа спекулятивного инлайнинга. Как я понимаю, в текущей архитектуре джита и CLR это вообще недостижимо. Максимум, что мы сможем получить эволюционным путём — это tier2 поверх tier0 и tier1.

S>>В основном — именно благодаря рослину. Тот компилятор, который был до него, не имело смысла опенсорсить — количество потенциальных контрибуторов туда было бы нулевым, особенно с учётом трудностей отладки.

V>ХЗ, именно в то время опенсорсный GCC развивался бешенными темпами, что аж догнал MSVC.
Ну, тут спорный момент. Я в чём-то понимаю позицию команды. Для GCC была уверенность в том, что коммиты не будут в будущем списаны за ненадобностью.
Для Рослин была совершенно стандартная ситуация легаси — когда есть уже ясное видение, что в долгосрочной перспективе мы не хотим ехать на существующей технологии; инкрементально переехать на новую технологию мы не можем; при этом в каждый момент мы понимаем, что если мы вкладываемся в легаси, то получаем быстрый результат, но при этом а) отнимаем ресурсы от проекта портирования, и б) увеличиваем количество кода, которое надо будет портировать. Это отдаляет "светлое будущее" с удвоенной скоростью.

Многие компании на этом вообще ломаются. А MS ничего, всё же выехали с рослиным. Стиснули зубы, понимая, что рискуют аудиторией, но пилили.