Optimized ThreadStatic field access for GC-type
Field accesses that are marked as ThreadStaticLocal are now optimized for primitive types. With PR#85619, we have optimized reference type field access as well. These changes have led some really good improvements in a number of benchmarks: (133 on windows/arm64, 23 on windows/x64, 16, 13, 11 improvements).
Arm64
Preview 5 also brings a number of few peephole optimizations:
With PR#85032, we enabled peephole optimization to replace str pair with stp.
With PR#85657, we enabled peephole optimization of replacing pair of ldr/str with ldp/stp inside prolog.
General optimizations
Our team has released a number of general optimizations that include:
x64 instructions such as movzx, movsx and movsxd have been optimized in PR#85780, which slightly improved code-gen by eliminating more redundant mov instructions.
PR#86318 improved constant folding for some frozen objects (non-GC objects). It reduced the size of the generated code by almost 10 times (e.g., 424 bytes to 41 byte).
AVX-512
PR#85389 enabled AVX-512 for block unrollings, which increases ranges where it previously used to fallback to memcpy/memset and reduced the execution time by half.
Various integer intrinsics are enabled for AVX512F, AVX512BW and AVX512CD, PR#85833.
S> Мне например понравилось https://github.com/dotnet/runtime/issues/81741
Чёт мне после таких PR, того как легко через рефлексию залазят в приватные поля, и т.д., кажется что вся идея с Member Visibility на уровне CLR провалилась, и её надо уверенно отламывать. В итоге на уровне CLR все поля и свойства изначально должны быть public, а проверки на видимость должны делаться на уровне компилятора. Собственно они уже начали уползать в компилятор (file class это оно).
Здравствуйте, Osaka, Вы писали:
O>Есть хоть что-нибудь полезное, или как обычно только новые средства ребусо-строения?
А всё! ООП фичи давно закончились. Из ФП подтянули всё необходимое. Ну может только поддержку монад сделать (хотя...) вменяемую. А так осталось только переходить к реализации полноценного метапрограммирования с блекджеком макросами и шлюхами расширением синтаксиса.
Если нам не помогут, то мы тоже никого не пощадим.
Интересный вариант, но есть риск растерять еще бОльшую часть аудитории и устроит нездоровуюь конкуренцию с F sharp. Уже сейчас отдача от внедрения новомодных загогулин мягко говоря близка к нулю. Интерфейсы с дефолтной имплементацией, нулабл реф типы и так далее — все это больше путает и так не сильно крепкие мозги молодой аудитории основных потребителй.
Здравствуйте, Osaka, Вы писали:
O>Есть хоть что-нибудь полезное, или как обычно только новые средства ребусо-строения?
Previously, .NET apps produced a deep and complex set of output paths for different build artifacts. The new, simplified output path structure gathers all build outputs into a common location, which makes it easier for tooling to anticipate.
...
By default, the common location is a folder named .artifacts in the root of your repository rather than in each project folder.
— https://learn.microsoft.com/en-us/dotnet/core/whats-new/dotnet-8
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Osaka, Вы писали:
O>>Есть хоть что-нибудь полезное, или как обычно только новые средства ребусо-строения?
IT>А всё! ООП фичи давно закончились. Из ФП подтянули всё необходимое. Ну может только поддержку монад сделать (хотя...) вменяемую. А так осталось только переходить к реализации полноценного метапрограммирования с блекджеком макросами и шлюхами расширением синтаксиса.
Нет С++ шаблонов! Надо срочно завезти, ибо generic вообще ни разу не шаблон!
Здравствуйте, fdn721, Вы писали:
F>Нет С++ шаблонов! Надо срочно завезти, ибо generic вообще ни разу не шаблон!
Есть SG и кстати Generic Math
Так, что любой каприз!
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> F>Нет С++ шаблонов! Надо срочно завезти, ибо generic вообще ни разу не шаблон!
S> Есть SG и кстати Generic Math S> Так, что любой каприз!
Костыли это, конечно, хорошо, но шаблоны луччччче!
Здравствуйте, hi_octane, Вы писали:
S>> Мне например понравилось https://github.com/dotnet/runtime/issues/81741 _>Чёт мне после таких PR, того как легко через рефлексию залазят в приватные поля, и т.д., кажется что вся идея с Member Visibility на уровне CLR провалилась, и её надо уверенно отламывать. В итоге на уровне CLR все поля и свойства изначально должны быть public, а проверки на видимость должны делаться на уровне компилятора. Собственно они уже начали уползать в компилятор (file class это оно).
Ну вот иногда нужен доступ к внутренностям. Это бывает нечасто, раз в пятилетку. Приходится через рефлексию.
Это может быть и ошибки при невозможности поменять версию или всевозможные хаки.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rudzuk, Вы писали:
R>Костыли это, конечно, хорошо, но шаблоны луччччче!
Ну шаблон это текст для кодогенерации. В SG можно прикрутить, что угодно. Просто нужно больше инструментов для кодогенерации.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, 尿컙拋㕪⬎⤇Ǥ꧃푙刾ꄔ, Вы писали: 尿Ǥ푙>нулабл реф типы
А вот это вот — святое. Позволяет не только найти косяки с обнуляемостью, но и найти смысловые недостатки в самих алгоритмах. Помимо этого, обнуляемость публично и формально декларирует ожидания того или иного метода, что значительно облегчает его использование — сразу видно можно ли в параметр null совать иль нет.
Называть новые фичи пустыми — это больше от неведения, чем от реальности.
Здравствуйте, IT, Вы писали:
IT> Шаблоны — это и есть костыли. Нужна нормальная compile time генерация кода, которой являются макросы.
IT> ЗЫ. Не те макросы, которые в C/C++, а те, которые в Немерле.
Макросы позволяющие менять синтаксис языка не нужны. Они может и хороши в качестве игрушек для церебральных соитий, но в практическом смысле несут больше вреда, нежели пользы. Как и чистая функциональщина, например.
R>Макросы позволяющие менять синтаксис языка не нужны. Они может и хороши в качестве игрушек для церебральных соитий, но в практическом смысле несут больше вреда, нежели пользы. Как и чистая функциональщина, например.
Я дико извиняюсь, но, например, async/await, yield return, foreach и using это всё макросы. И даже '.' (точка) это тоже макрос — её смысл радикально меняется в зависимости от того, какие сущности она разделяет. Просто создатели компилятора сделали эти макросы ковыряясь ручками в кишках компилятора. А могли бы за то же время сделать вменяемое API для макросов, и затем всё самое полезное просто "само" появилось бы в nuget.
То что каждый релиз C# в нём что-то улушчается, показывает что улучшать язык нужно. Но у команды авторов куда меньше ресурсов, фантазии, и опыта работы в разных предметных областях, по сравнению со всем миром, чтобы написать макросы для всех предметных областей и всех возможных фишек. А ещё их сдерживают огромные риски что вкорячат в язык что-то неудачное, и придётся потом все следующие 100 лет это тащить по соображениям обратной совместимости.
Быстрое развитие языка в строну удобства возможно только через macro api и усилия комьюнити. А авторам языка останется выбирать самые удачные изобретения, полировать до блеска и вносить в стандартную библиотеку. Примерно как они сделали с System.Text.Json (переосмыслив Newtonsoft.Json и uft8json), только с фичами языка.
А твой страх что "в практическом смысле больше вреда" — это просто указание что культура подключения языковых наворотов пока не сформирована. Но она не сложнее чем культура подключеням библиотек. Посмотреть, почитать, попробовать на тестовом проектике, подумать, полезно ли оно, и только потом подключать.
Здравствуйте, hi_octane, Вы писали:
h> R>Макросы позволяющие менять синтаксис языка не нужны. Они может и хороши в качестве игрушек для церебральных соитий, но в практическом смысле несут больше вреда, нежели пользы. Как и чистая функциональщина, например.
h> Я дико извиняюсь, но, например, async/await, yield return, foreach и using это всё макросы. И даже '.' (точка) это тоже макрос — её смысл радикально меняется в зависимости от того, какие сущности она разделяет.
Это не макросы, это языковые сущности, которые понимает каждая кухарка, взявшаяся читать код — ибо они часть языка.
h> То что каждый релиз C# в нём что-то улушчается, показывает что улучшать язык нужно.
Это, скорее, показывает, что МС всенепременно хочется его "улучшать". Информационные поводы нужны, а иначе нытье о стагнации от паствы.
h> А твой страх что "в практическом смысле больше вреда" — это просто указание что культура подключения языковых наворотов пока не сформирована.
А это не страх, это понимание в какую жопу превратиться код, особо одаренных личностей. Людям этот код читать потом, но райтонли пейсателям на это пофиг. Не, можно, конечно, ввести ограничения в проект на использование некоторых фичей языка... Ой, чего-то плюсами напахнуло.
Я уже это всё проходил 10+ лет назад в "священных войнах", поэтому воевать буду в полсилы, без огонька
R>Это не макросы, это языковые сущности,
То что это некие "сущности" лишь следствие негибкости языка и мышления авторов. В языке с макросами никакие "сущности" изобретать не нужно.
R>которые понимает каждая кухарка, взявшаяся читать код — ибо они часть языка.
Вот в реальном проекте у меня когда-то использовались макросы readlock(obj) и writelock(obj)
. Использовались foreach {} else { то что выполняется если IEnumerable пустой }. Использовались переменные которые объявлялись как interlocked int, и дальше все операции +/-/++/-- выполнялись через Interlocked.*. Использовали макрос который внутри функций позволяет объявляеть приватные члены
, которые больше внутри класса никому не видны, и не замусоривают пространство имён — это позволяет, например, не мусорить с disposing/disposed внутри класса при реализации IDisposable, и скрывать всякие одноразовые wasInitialized, кэши, и DateTime _lastRetryTime. Вот любую из этих фич никому в команде особо объяснять не надо было. Один раз увидели и пользовались. Так что про непонятность мимо. Люди с прямыми руками используют все возможности языка чтобы было удобнее и понятнее. Люди с кривыми руками самый просто вложенные if-ы так завернут, что чёрт ногу сломит.
Собственно если бы какая-то "кухарка" завопила что любая из перечисленных фич "абсолютно непонятна и вредит читабельности", впору было бы поднимать вопрос о профпригодности.
R>А это не страх, это понимание в какую жопу превратиться код, особо одаренных личностей.
Понимание может быть только у человека который пользовался и тем и другим. Я вот пользовался, результат отличный, достоинств вижу в разы больше чем недостатков. Собственно Roslyn и Source Generators это такой вялый дрейф в сторону тех самых макросов. Ещё лет 10 подрейфуют и приплывут.
R>Людям этот код читать потом, но райтонли пейсателям на это пофиг. Не, можно, конечно, ввести ограничения в проект на использование некоторых фичей языка... Ой, чего-то плюсами напахнуло.
И снова ограничения по фичам в случае макросов вводить куда удобнее — ты можешь просто не включать их в свой проект. Они обычные библиотеки, просто с фичами а не классами. Если лид или команда решили в каком-то проекте использовать какой-то макрос — значит он удобен, понятен, и облегчает работу. А если решили ничего не использовать — то code review закончится на этапе изучения "что ты за новые либы в проект притащил, нам не надо". И в исходники смотреть не придётся.
Здравствуйте, rudzuk, Вы писали:
R>Макросы позволяющие менять синтаксис языка не нужны.
Такие заявления не нужны ещё больше.
R>Они может и хороши в качестве игрушек для церебральных соитий, но в практическом смысле несут больше вреда, нежели пользы. Как и чистая функциональщина, например.
Признайся честно, ты никогда не пользовался ничем подобным и понятия не имеешь как оно там всё вот это вот работает. Просто понаслушался всяческих околомакросовских глупостей. Иначе бы ты знал, что при желении можно написать макрос (плагин к компилятору), который запретит использование нежелательных макросов.
ЗЫ. У нас в команде есть один девелопер, который упорно не ставит пробел между 'if' и '('. Любые воздействия и задушевные беседы бесполезны. Один единственный макрос решил бы эту проблему раз и навсегда.
ЗЫ2. Это я к тому, что плагинами к компилятору можно решать огромный круг задач, не только по генерации кода, но и по его контролю, высокоуровневой оптимизации (типа переписывания Enumerable в циклы) и т.п.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>ЗЫ. У нас в команде есть один девелопер, который упорно не ставит пробел между 'if' и '('. Любые воздействия и задушевные беседы бесполезны. Один единственный макрос решил бы эту проблему раз и навсегда.
в шарпе нет автоформатеров/линтеров?
проблема должна решаться не задушевными разговорами, а автоматическим запретом коммита кода, не соответствующего заданным правилам
Если нам не помогут, то мы тоже никого не пощадим.
