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

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

V>На практике не нарываемся, если класс содержит только примитивные типы в полях.
V>Структуры в АПИ обычно идут по указателю, на стороне C# это ref для struct или просто классы по ссылке.
V>Маршаллер пинит экземпляры таких классов, вот и весь маршаллинг.
Плюс коррекция указателя. Ок.

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

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

V>Такой же stackalloc начинается.
О, это интересно. То есть вы размечаете "структуру" в стеке как серию stackalloc? А есть гарантии их взаимного расположения?

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

V>Указанные два "островка" управляемого стека должны быть связаны в однонаправленный список, от текущего верха стека к его нижним фреймам.
V>Дотнетный дебаггер при отладке, кстате, показывает места, где участки нейтивного стека пропущены.
Ну, это если у нас реально тяжёлый нативный метод — долго работает и/или делает колбэки в менеджед. В первом случае микросекунды задержки нам неважны; во втором случае такой метод просится на перетаскивание в менеджед.

S>>Я на своём уровне некомпетентности вижу только одну глобальную проблему: нет, как такового, хотспоттинга. Tiered compilation выглядит как жалкое подобие левой руки.

V>Tiered compilation и есть hotspot.
Ну это очень вольная трактовка. Формально — да, но с тех пор, как появилась сама идея "оптимизируем только узкие места", её стандартная трактовка расширилась до "runtime profile-based dynamic optimization".
То есть "учитываем счётчик вызовов для применения tier1" — это очень, очень примитивный уровень. Чтобы, к примеру, заработал спекулятивный инлайнинг, нужно:
— прикрутить инструментирование кода для определения частотности call targets
— прикрутить умение JIT-тить инлайн ожидаемого таргета с guard condition
— прикрутить умение откатывать оптимизацию (или применять повторный JIT) при превышении порога частоты срабатывания guard condition.
Это одно стоит в разы больше, чем, собственно, tiered compilation. А ведь помимо этого в настоящем хотспоте (т.е. в profile guided optimization) ещё много чего прикручено.

V>В моём примере с IConfig до появления Tiered compilation джит сразу генерил свой оптимизированный, но глупый код.
V>Теперь этот код надо исполнять сколько-то раз в цикле, чтобы джит его соптимизировал, иначе там 1-в-1 с исходником.
Ну, именно поэтому BDN имеет фазу прогрева

V>Средней величины дотнетное приложение до него запускалось по 600-800 ms, сейчас примерно вдвое быстрее.
Ну почему же "ничего более". Прямо в анонсе показывали ускорение steady state, местами почти двукратное.

V>Особенно чувствительны к этой технологии те приложения, где инициализируется много статических данных (например, WPF и прочие, где описаны мильоны dependency property).
V>Cтоимость джита инициализирующего кода была в разы больше стоимости его исполнения, а код-то одноразовый.
Возможно. Я WPF приложения никогда не видел

V>Спасёт только качественный AOT.
Это для десктопа. А для любимого мной бэкенда важен именно хотспот, т.к. никакой AOT не предскажет реальную нагрузку.
V>К нашей пенсии всё будет ОК, не переживай. ))
А вот я уверен, что и тогда будет к чему стремиться.

V>Ммм...
V>В общем, там несравнимые объемы и сложность кода, имелось ввиду это.
V>Если тебе Рослин кажется сложным проектом — ты сильно заблуждаешься.
V>Рослин простой как балалайка, хотя и достаточно объемный.
Ну так его пилили не столько лет, сколько GCC

V>И что странно — нормального оптимизирующего компилятора C# всё еще нет.
V>Т.е. слишком многое оставлено джиту такого, что можно причесать и до джит.
Да, с этим согласен.

V>Например, тот же пример с SomeClass<Config1> c1 = ...; c.Foo();
V>Если все типы объявлены в одной сборке, там нефик делать соптимизировать лишнее компилятором.
Да пусть хотя бы свой dup для value типов уберут А то смешно сказать — два совершенно семантически эквивалентных куска С# кода порождают совершенно разный бинарь. Ну куда это годится?

V>Аналогично куча строковых вычислений и прочих, особенно при инициализации — компилятор честным образом отдаёт это всё в рантайм, хотя там до половины и более зачастую вычислимы в compile time.
Как раз простые строковые вычисления компилятор делает сразу.

V>Основное при разработке сложных проектов — хорошо понимать собственный код.
V>Итеративность в этом смысле привносит оперативность.
V>Т.е., в чём-то больше работы, да, но в целом происходящее оперативнее, т.к. некоторые бока/недоработки нового кода раньше вскрываются.
Ну о какой итеративности можно тут говорить? Они же не могли выпустить "рослин шарп 1.0" без генериков и прочих плюшек, и потом итеративно его деливерить.
Внутри проекта, понятное дело, были какие-то майлстоуны и дедлайны, но снаружи всё это не могло быть наблюдаемо.

V>Любому "светлому будущему" надо по классике отводить примерно 9 месяцев на что-то средней сложности и не более 18-ти для чего-то совсем кардинального.
V>А тут 5-6 лет возни.
Ну-ну
V>И не переубедишь. ))
Ну, может вам в Теслу пойти? А то с анонса автопилота прошло уже существенно больше 18 месяцев, а он всё ещё не ездит.

S>>Многие компании на этом вообще ломаются.

V>Спас ход конём — выкатили для линухов и ушли в опенсорс, аудитория потихоньку возвращается.
Да, шанс есть. Но надо ещё пилить, пилить, и пилить.