Комментарии 99
C# 9 определенно не является серьезным мотивом для переезда на новый дотнет


Узнаю старый-добрый контур.
Рано узнавать старый-добрый, я тут всего месяц!
А вообще — я и впрямь не вижу ничего особо впечатляющего в C# 9. Приятные мелочи, не более.

Если вы собираетесь использовать Nullable Reference Types то до C#9 писать обобщённые методы было немного затруднительным.

Да, мне тоже очень этот момент понравился.


А что особенно понравилось, так это что тулчейном .NET 5.0 можно собирать проекты и .NET Core, и .NET Framework, задействуя новые возможности языка. То есть нет смысла ломать проект и менять целевую платформу на .NET 5.0. Достаточно просто обновить компилятор и радоваться жизни.

Это так происходит с незапамятных времён начиная с C# 3 разве что кроме Expression, которому нужна поддержка самого .NET.


Кстати если нужна поддержка старых фреймворком с новыми компиляторами есть замечательный проект
https://github.com/theraot/Theraot/

Начиная с .NET 5 SDK, этот нугет нет необходимости указывать — сдк сделает это за вас :)

Можно указать единственный net5.0 TargetFramework и при этом остаться на .NET Framework 2.0 ;)


Целевая платофрма не так важна, как TargetFrameworkIdentifier

У меня есть проект с WPF, который где то под 4.7, если не 4.6. Оставлено так ради поддержки Windows Vista \ 7.
Если я обновлюсь на net5, мой проект на WPF сможет запускаться хотя бы на Win7? Ну и сюда же в кучу — WPF на свежих дотнетах теперь требует self-host приложения с кучей длл, нельзя просто exe файл буквально использовать? =)
> exe файл буквально использовать?
Можно, если не использовать self-hosted )
Ну давайте до конца тогда уж — потребуется установка каких то рантаймов на машину, наверное? WPF работает из коробки, self-host от netcore3 с например avaloniaui после установки свежего vcredist — тоже заводится. Заведется ли так net5 c WPF?

Лично у меня с net5 были проблемы. В self-contained app то одного не хватает, то другого, то вообще запуститься не в состоянии. А вот при сборке под netcoreapp3.1 работает всегда и везде. Принципиальной разницы между по функционалу net5.0 и netcoreapp3.1 не вижу, поэтому остаюсь на netcoreapp3.1, но с новыми фишками c#9.0

Время установки пакетов (desktop runtime) драматично сократилось, где то в десятки раз. Это же неспроста…
В связи с этим чисто утилитарные вопросы:
— Если на голую win7 установить только dot5, то будут ли работать приложения, которые в своих требованиях хотят dot4.x, нативно не представленной в win7?
— Для x64-сборок достаточно ли установить только x64-инсталлятор, или дополнительно требуется и x86-установка для x86-приложений?
— Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)?

Присоединяюсь к вопросу.
Вот только сегодня помогал человеку установить одну софтину (как обычно, простой пользователь сообщения об ошибках не читает никогда, максимум "он там что-то написал, я закрыл, ну и все закрылось"). Сообщение установщика заключалось в том, что ему требуется для установки .NET 4.5, а на Windows 7 на тот момент был установлен 4.8. Проблему удалось решить удалив 4.8 и установив 4.5, затем установив 4.8 обратно. Понятно, что в установщике зачем-то жестко прописано "==" вместо ">=", и сам .NET тут возможно не при чем. Но это просто последний такой случай в моей практике из множества аналогичных, т.е. тенденция имеется, вопрос: сохранится ли?

.NET Framework — компонент Windows, поэтому нельзя параллельно установить несколько разных версий его. .NET Core / .NET 5 более автономный, вплоть до того, что приложение может таскать его с собой (штатный режим сборки, включается буквально парой ключей) или вообще завернуть в один жирный экзешник (тоже штатный режим).
Ну как я понимаю, есть какая-то мажорная версия фреймворка, которая с собой для совместимости таскает некоторый набор предыдущих версий. Насколько мне известно, невозможно параллельно установить несколько мажорных версий .NET Framework (4.5 и 4.8, к примеру, как в ситуации выше по треду). Я не настоящий сварщик, так что выводы сделал по пользовательским ситуациям, подобным описанным выше, когда приходилось удалять и устанавливать разные версии фреймворка, чтобы заставить работать приложение.
Формально да — 2.Х и 4.Х. Но по факту 4.Х действительно только один.
Ноу, 3.5 это расширение 2.Х. Там хитрая система с тем что часть фреймворка в этом случае лежит в 3.5 директориях а часть в 2.Х. Но при этом формально на машине будет стоять 3.5 и 4.Х.
1) Если под «голой» win7 вы подразумеваете Windows 7 SP1 без единого установленного обновления — то dot5 у вас установится, но приложения работать не будут, пока вы не поставите обновление KB2533623 (ныне доступно только через Web Archive) или его заменитель KB3063858 (доступно на сайте MS) — обсуждение на github
2) «будут ли работать приложения, которые в своих требованиях хотят dot4.x, нативно не представленной в win7» — если имеется в виду, что приложение dot5 использует библиотеку например dot4.8 — то устанавливать dot4.8 придётся. Причём опять же таки, если речь идёт о Windows 7 SP1 без единого установленного обновления — то установщик dot4.8 выдаст ошибку какого-то там сертификата, пока вы не поставите обновление KB3004394-v2
3) «Для x64-сборок достаточно ли установить только x64-инсталлятор, или дополнительно требуется и x86-установка для x86-приложений» — к сожалению не понял вопроса, их же тут два… Если Вы собирали под x64 — то для работы понадобится x64 runtime, если собирали под x86 — то для работы понадобится x86 runtime (т. е. если в вашем софте есть смешение архитектур — то придётся ставить оба runtime)
4) Как вам уже написали ниже:
Net Runtime — минимальный набор (только для библиотек и консольных приложений)
ASP .Net Core Runtime = Net Runtime + поддержка ASP .Net Core
Desktop Runtime = Net Runtime + поддержка десктопного UI (WPF/WinForms)
Спасибо, всё ясно.
1) эти обновления в системе есть.
2) Да, это я тоже замечал, проблема появилась после dotnet 4.6.2. Я добавлял сертификаты через политики.
3)- я не девелопер, просто потребитель и мне неизвестно, что заложено в приложении. Судя по ответу — да, нужно устанавливать оба x64+x86, если система 64, для всех вариантов (возможных) приложений. И впридачу, крайняя 4.х версия тоже необходима.
3) Для ОС x64 минимально необходимый набор — это .NET Farmework 4.8 и .NET 5.0 x64. (т. к. подавляющее большинство приложений собирается в конфигурации Any CPU — на OC x64 приложение тоже будет x64). Но чисто теоретически ничто не мешает разработчику собрать приложение в конфигурации x86 — для таких (довольно редких) случаев вам всё же придётся поставить и .NET 5.0 x86.
Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)

Не совсем корректный вопрос, потому что
ASP.Net Core Runtime = Net Runtime + поддержка ASP.Net
Desktop Runtime = Net Runtime + поддержка десктопного UI
В регулярных выражениях помимо увеличения производительности, также исправили серьезную ошибку совместимости с ECMAScript. В предыдущих версиях .NET при создании регулярных выражений с флагом RegexOptions.ECMAScript возникали ошибки при разборе шаблонов, содержащих следующий символьный класс – [^] (например, ^(\s*)([^]*\S)(\s*)$). Данная ошибка создавала множество проблем при работе с JavaScript-движками, написанными на чистом .NET (Jint, Jurassic и NiL.JS).
C# 9 определенно не является серьезным мотивом для переезда на новый дотнет

Добавлю. Новый шарп — это в основном синтаксические накрутки, генерируемый IL не изменяется. Например, record — это на самом деле класс под капотом. А значит можно использовать многие фичи девятого шарпа даже на netstandard2.0.


Для этого вам нужно написать следующий костыль где-нибудь.


Либо почитайте пост от автора Nullables, который сделал nuget-пакет для этой же цели (чтобы использовать девятый шарп в < 5 версиях)


У меня есть проект (библиотека), таргетящий 2.0, и при этом использующий девятый шарп. Очень удобно

генерируемый IL не изменяется

Разве это не основной смысл иметь IL не привязанный к языку? Или вы хотите, чтобы была версия .NET с изменённым IL?

Ну а как добавлять какие-то вещи типа generics? Или вот DIM (default interface member)? Хотя про последнее не уверен, может это только от рантайма зависит

Если что-то можно добавить без внедрения несовместимого IL — назовите хоть одну причину почему это не добавить без внедрения несовместимого IL?
Generics требовали переделки архитектуры, но это было очень давно, когда C# был молод и когда ещё не был основательно продуман.
И то, что практически все новые фичи под капотом являются просто сахаром, это однозначный плюс — если что непонятно, всегда можно заглянуть под капот и понять что как работает.

Так можно говорить про каждую версию и остаться в итоге на net20 ;)


Теже рекорды особо не нужны, когда можно было просто использовать ValueObject. Но всеже, в каждом релизе, что-то да новое есть, например аттрибут ModuleInitializer или SkipLocalsInit, поднимающие версии рантайма. Да и всякий синтаксический сахар, все-таки, упращает читаемость кода. Поэтому как-то неочень ультимативно заявлять, что новая версия языка, рантайма или SDK ничего не приносит

Теже рекорды особо не нужны, когда можно было просто использовать ValueObject.

Вы бы исходники того проекта хотя бы почитали. Как proof-of-concept — норм, но в продакшн я бы и на пушечный выстрел такое не подпустил.

Я её и имею в виду. Там оно сделано через рефлексию со всеми её минусами.

Это опенсорс решение. У кого есть желание, может улучшить предложенный вариант. И кажется, что этот репозиторий будет хорошей песочницей перед тем, как предложить свои измнения в код, который используется в проде

Ну конкретно этот метод — затычка, он не нуждается в оптимизации, потому что вы не можете в пользовательском коде унаследоваться от System.ValueType. От него неявно наследуются типы-структуры, но если вы структуры сравниваете через object.Equals(), то вы делаете что-то не так.


Да, теоретически можно было бы его расширить и на пользовательские классы, добившись той же логики сравнения, что и для структур, но зачем это нужно, когда ввели более эффективные рекорды?

Так можно говорить про каждую версию и остаться в итоге на net20

Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).
ValueObject выполняет другую задачу. С рекордами вы получаете возможность построить граф из коробки. Ну и паттерн матчинг.


ValueObject обычно для небольших оберток, я никогда не видел структуры, которая достаточно самостоятельна и выполняет какую-то ключевую задачу.

Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).

Про легаси. Речь шла больше про те проекты, где не находят применения новым возможностям по каким-либо причинам. Больше удручает, когда это проиводит к затяжному застою без каких-либо проблем в применимости


С рекордами вы получаете возможность построить граф из коробки

С таким не приходилось связываться, поэтому не могу оценить о чем идет речь :)


Для меня, пока что, рекорды убирают бойлерплейт, связанный с реализацией IEquatable<T>

НЛО прилетело и опубликовало эту надпись здесь

Можно расходится, снова nodejs Electron программисты будут тыкать пальцем и смеяться над кроссплатформенностью .Net. Майкрософт, ну как так???


P.S. Не надо писать про сторонние фреймворки типа авалонии — куда смотрят мелкомягкие??? 2021 год на носу, а они нам дальше консольку и веб парят. А я так ждал гуй из коробки...

Кроссплатформенный GUI обещают в .NET 6, MAUI. Но да, не в этой версии.
Кстати, можно поучиться у тех самых nodejs Electron программистов и пользоваться Electron.NET. На все той же .NET Conf был неплохой доклад про это.

Да, обещают уже давно. И в 5ке обещали.
Авалония вполне годный вариант. Вопрос в развитии продукта от самого майкрософта. Обидно ж.

Это те ребята у которых хело волд занимает полгектара в памяти и пару сотен метров на диске?..
Индийский сахар какой-то. Как-то мало полезного из синтаксиса.
Как по мне — и фиг бы с ним, с синтаксисом. C# и без того мощный язык, а вот перфоманса и багфиксов много не бывает.
Как по мне, сейчас главная проблема .NET — не язык, в котором уже столько сахара, что жопа слипается (и бойлерплейты не страшны, благодаря стандартным практикам, кодогенератору и автодополнению). Главная проблема — это плодящийся зоопарк: .NET Framework, .NET Standard, .NET Core, Mono, Xamarin, UWP… Без политуры новичку уже и не разберёшь за что браться, что устарело, а что ещё слишком ново.

Да ладно новичку… Вот решил вспомнить и попробовать утилиту сделать… И выходит что winforms живее всех живых среди мёртвых а на чём начинать на будущее непонятно.

Мне на ARM64 нужны были интерфейсы, в том числе блютуз, и конечно формочки. Пощупал .NET 5 и перешёл на Qt. Там тоже есть вопросы, но вроде пока всё решаемо...

Поэтому и подводят всё к одному .NET. Часть названных это фреймворки для разработки под мобилку, десктоп-планшеты.
.NET Standard — просто общая API для всего этого зоопарка. С зоопарком JS'а ничего не сравнится.
Я-то знаю и я нарочито смешал всё до кучи.
А так — сравнивать с худшими не повод для радости. Старый .NET был хорош именно тем, что это была единая среда с разными версиями, а весь «зоопарк» состоял из WinForms vs WPF, ну и Mono где-то рядом бегал и пытался не отставать. Хочешь создавать что-то новое — создаёшь на последней версии и не паришь себе мозг.
(окей, да, я явно лукавлю, т.к. если делается dll расширения для старых приложений, то выбора что использовать не было — только старый фреймворк)
Вот да. А фундаментальные недостатки некоторые так и не решены: generic арифметика и классы типов.
— Чем отличается инсталляция от перфоманса? Если ты, допустим, насрал человеку под дверь, а потом уже позвонил в звонок – это инсталляция. А вот если ты сначала человеку позвонил, а когда он вышел из квартиры, то ты сел перед ним и насрал, – это уже перфоманс.


А в программировании как-то всё больше скорость вычислений или производительность.

Еще любят генерацию вместо поколений использовать почему-то.
А что будет, если таргет будет старый (netstandard2.0, например), а рантайм новый? Плюшки по производительности будут? Или всё-таки IL-код оптимизируется ещё новым тулчейном?
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.

.NET Standard — это лишь API. Ему можно подсунуть любой удовлетворяющий рантайм. .NET — это продолжение идей .NET Standard. Поэтому, если вам не нужны фичи из .NET, то можете смело оставаться на стандарте


When to target net5.0 vs. netstandard

Это я понимаю, но вопросы были в следующем:
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
Насколько я понимаю — в обоих случаях ответ ДА.
Но убирать реализацию врядли будут, скорее наоборот — добавят для каких то вещей.
ПС: мне казалось, net core 3 уже целиком реализовывал стандарт? Остались методы без реализации, но заявлены в стандарте?
Похоже, всё-таки не всё будет гладко.
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
МС не рекомендовали им пользоваться со времен появления тасок =)

Более того, работать с ним было намного неудобнее, чем с тасками.

Да, кому то обновление будет не бесплатно. Но судя по МСДН — будет варнинг, кто пользуется — должны быть внимательнее.
Он по-другому работает. Таска сама проверяет, что её попросили сдохнуть и делает всё для этого, а это насильное убийство. Нужно обычно как средство последнего шанса, но бывают ситуации, когда очень нужно.
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
1. Будет ли прирост производительности просто от подсовывания нового рантайма

Моя библиотека, поддерживающая .NET Standard 2.1, стала быстрее работать на 20-25% при запуске под .NET 5.0 вместо .NET Core App 3.1.



Вопрос: а с чем это связано? С оптимизациями при JIT-компиляции или же с новыми версиями библиотек?

Думаю, что и с тем, и с другим, потому что в моей библиотеке используется много регулярных выражений.
а где полная статья по миграции с 3 на 5?
или опять 100 системных файлов править руками по пиксельно?

В статье упущены значительные улучшения single-file applications — почти полностью ушли от распаковки файлов во временную директорию, скорость первого запуска в связи с этим заметно увеличилась.

Измерения перфоманса
Таки сложно написать «измерения производительности»? Тем более что данный англицизм имеет в русском языке совершенно другое устоявшееся значение.
еще Microsoft выкатили Project Tye, который как раз является инструментом для удобного управления микросервисами. На текущий момент трудно сказать, стоит ли использовать Tye в продакшене, но обратить внимание и поиграться с ним в свободное время определенно нужно.


странная любовь MS к таким названиям, не то кириллица, не то латиница… То бот-расист Tay (Тэй или Тау?), теперь Туя какая-то…
С точки зрения шарписта, есть некоторое количество WTF.
Например, встречал инфу, что «void возвращает null», хотя во второй версии говорят void это вообще тип.
Или отсутствие явных интерфейсов, а не явно каждый class это интерфейс. То есть один и тот же класс, можно как наследовать, так и имплементировать =)

С точки же прикладной, dart похоже выстрелил только на мобилках как flutter, соответственно Dart — язык одного фреймворка. Как в свое время Ruby с Ruby on Rails. Хотя сейчас есть бетка flutter под десктоп, мб и на десктопе выстрелит.
Мы вот Utf8JSON прикрутили давно, и рады. Он сразу в Stream льет, без промежуточных этапов в виде UTF16-строк.

Но вообще, в мире заботы о экологии и энергопотреблении, давно уже пора заменить JSON чем-нибудь менее расточительным. А то всякие возобновляемые источники ставят, и прочее. Чтобы потом в датацентрах процентов 30 сжигать чисто на преобразование в этот уродливый формат.

Меня, лично, останавливает исключительно отсутствие минимальной поддержки в Chrome Dev Tools. Если кто-нибудь прикрутит preview какого-нибудь BSON в Network-табе — я сразу начну свои аппы переводить. А в идеале — сразу брать что-нибудь типа AVRO, чтобы уже два раза не вставать.
Вот чем мне нравится современный МС, так это стремлением всё упростить и сделать удобнее.
Вот есть у меня маленькая консольная утилита, ей ничего особо не нужно для работы, под старый фреймворк я ее компилил очень сложным устаревшим путем вызова csc.exe /target:exe dup.cs /r:… (ну и там всякие фреймворковские длл, не суть). На выходе получался -exe файл в той же папке, что и -cs.

Теперь же у нас всё просто! Нет csc — нет проблем.
1.Сначала надо сделать csproj файл (100500 настроек, наслаждайтесь комбинированием)
2. потом дернуть dotnet build, который сгенерирует 2 папки, с 4 подпапками.в каждой, десяток доп-файлов и наслаждайтесь чтением доков, чтобы это все как-то привести к старому неудобному результату работы csc.exe, ага

… потратил больше двух часов гуглежа на это все — останусь-ка я, пожалуй, на старом фреймворке.

Только что попробовал: csc из .NET 5.0 по-прежнему прекрасно компилирует код из одного файла.


Сначала надо сделать csproj файл

dotnet new console

Да-да, так я его и сгенерировал в итоге. Пришлось правда долго и упорно гуглить, ведь я искал аналог csc — а его там больше нет.
Ну и я ж и не говорю, мой проект не скомпилировался и не заработал в итоге.
Просто по-старому я это делал одной командой имея на руках 1 .cs файл и получая на выходе 1 .exe файл. Итого — 2 (ну ладно, три — третьим идет .bat с вызовом csc, чтобы не вспоминать потом правильный набор ключей и не дергать справку).
Теперь же нужно обязательно иметь .csproj (и + тот самый bat файл), который фиг настроишь самостоятельно (ключей — много) и на выходе вы еще и обязательно получите кучу вспомогательных файлов/папок. Да, там есть команда для авторазвертывания в целевую папку, но это всё равно никак не решает проблемы возникновения кучи доп. файлов.
Ну т.е. если раньше я мог накодить эксперимент чуть ли не в блокноте, скомпилить его и пользоваться, то теперь мне надо сначала настроить практически полноценное окружение (а еще лучше — не париться и взять Visual Studio, которой MS прямо тычет на каждой странице про dotnet и его инсталлятор).
Юзабилити.

P.S.: и да, я сначала установил сам дотнет 5ый, без sdk, в итоге dotnet new console проект-то мне сделал, но после смены там на net5.0 сказал, что у него лапки и компилировать отказался. Пока я не скачал еще и sdk-инсталлятор. Замечу, что предыдущие версии (начиная с первой!) работали и компилировали сразу после установки, являясь цельной средой.
оторый фиг настроишь самостоятельно

Эмм, вот весь csproj-файл, чего там настраивать-то?


<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <RootNamespace>RootNamespace</RootNamespace>
  </PropertyGroup>
</Project>

Потом выполняется dotnet run. Это ещё проще, чем csc с заданием ключей.
А если вдруг раздражают директории bin и obj, ну что ж, внутрь них заглядывать даже не надо.


Ну т.е. если раньше я мог накодить эксперимент чуть ли не в блокноте, скомпилить его и пользоваться

Попробуйте это:
https://habr.com/ru/company/microsoft/blog/475110/

Эмм, вот весь csproj-файл, чего там настраивать-то?

Именно! Да. И на выходе — куча бесполезных для меня файлов. Я, например, так и не понял, зачем мне сгенерировались 2 штуки .dll файлов рядом с .exe (один — в подпапке) и 3 json-файла, в которых в явном виде написана целевая среда исполнения и тоже не очень понятно, что будет если их убрать.

Ну и в конечном итоге — я пишу не о том, что оно не работает… А о том, что простейшая команда в итоге превратилась в какие-то танцы с гуглом и кучей телодвижений — причем итоговый результат тот же.
Попробуйте это:
habr.com/ru/company/microsoft/blog/475110

По сути — visual studio, вид сбоку. Не, ну я утрирую, конечно, но суть в том, что в итоге вместо использования того, что и так уже заведомо есть в ОС (в десятке — даже из коробки уже), необходимо магическими заклинаниями что-то докачивать, устанавливать и только получив полноценную среду разработки — работать дальше.
Удобно же!
Особенно удобно эти магические заклинания гуглить, если про Jupyter Lab и Anaconda Navigator ни разу не слышал. Абсолютно интуитивно понятно же:
dotnet tool install -g dotnet-try
dotnet try jupyter install
jupyter lab
По-моему, релиз сырой. У меня C# компилятор выдаёт internal compiler error на новых указателях на функции:
delegate* unmanaged<RefStruct>
Перестали работать части NonCopyableAnalyzer, тоже из-за внутренних ошибок Roslyn.

П.С. Всё зарепортил уже.
> Релиз MAUI перенесли на .NET 6
Не перенесли, а изначально планировали на .NET 6, пруф

А GUI на Linux (X11) не планируется шоли? "As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS." Ага, еще плагин для тиктока интегрировали бы...

Там вроде MAUI под линукс будет community supported, как с xamarin.
Да и зачем это делать микрософту, когда десктопный UI под линукс и так существует?

Кстати, насчёт производительности. Сравнил следующий код на C#:


[MethodImpl(MethodImplOptions.AggressiveOptimization)]
static unsafe void SumUnmanagedUnsafeScanlineVector(UnmanagedImage<float> img1, UnmanagedImage<float> img2, UnmanagedImage<float> res)
{
    var w8 = res.Width / 8 * 8;

    for (int j = 0; j < res.Height; j++)
    {
        var p1 = img1.GetScanLine(j);
        var p2 = img2.GetScanLine(j);
        var p3 = res.GetScanLine(j);

        for (int i = 0; i < w8; i += 8)
        {
            Avx.Store(p3, Avx.Add(Avx.LoadVector256(p1), Avx.LoadVector256(p2)));
            p1 += 8;
            p2 += 8;
            p3 += 8;
        }

        for (int i = w8; i < res.Width; i++)
            *p3++ = *p1++ + *p2++;
    }
}

и код на C++:


void ImageSumVector(Image<float> &img1, Image<float> &img2, Image<float> &res)
{
    int w8 = res.Width() / 8 * 8;

    for (int j = 0; j < res.Height(); j++)
    {
        float *p1 = &img1(0, j);
        float *p2 = &img2(0, j);
        float *p3 = &res(0, j);

        for (int i = 0; i < w8; i += 8)
        {
            _mm256_storeu_ps(p3, _mm256_add_ps(_mm256_loadu_ps(p1), _mm256_loadu_ps(p2)));
            p1 += 8;
            p2 += 8;
            p3 += 8;
        }

        for (int i = w8; i < res.Width(); i++)
            *p3++ = *p1++ + *p2++;
    }    
}

Код на C# в Release отрабатывал примерно за 4.3 мкс, код на C++ — за 3.75 мкс (одинаково с флагами -O1, -O2 и -O3). Тот же вариант, но невекторизованный, отрабатывал на C# и C++ (-O1) одинаково за 12.5 мкс. Правда, начиная с -O2 в C++ врабалась автовекторизация.


Год назад C# отставал от C++ в этом тесте почти в 2 раза, сейчас — практически паритет. Получается, C++ не нужен, и на C# уже вполне можно писать производительный код?

Год назад C# отставал от C++ в этом тесте почти в 2 раза, сейчас — практически паритет. Получается, C++ не нужен, и на C# уже вполне можно писать производительный код?
Можно, только надо еще с GC моменты учитывать.

Ну если рассматривать обработку изображений, то частых выделений памяти там нет. Только большие куски памяти под сами изображения, которые целесообразнее выделять в unmanaged памяти.

Вот только фактически, ты не управляешь этими моментами, как только вышло за пределы твоего кода.

Есть GC, или нет, сам ты не контролируешь. Дернул стандартную библиотечную ф-цию и все.

Пока Designer не допилят, WinForms под 5.0, к сожалению, не готов к реальной разработке. Мы сделали пробное портиррование нашего немаленького продукта и все на удивление завелось без больших проблем. Там и тут чутка подпилить да подстучать и все работает. Но застопорились на двух проблемах:


  • Дизайнер сырой на удивление, хотя и заявленно, что обкатали его вместе с большими производителями контролов. И что, никто не пробовал иконки из глобальных русурсов использовать? https://github.com/dotnet/winforms/issues/3958
  • Stimulsoft Report, который мы используем для отчетов, под Core не умеет в Compile. Придется видимо отчеты переделывать.

Кто-то пробовал новый Designer в формах с приличным колличеством контролов? Он у вас такой же медленный? У меня после клика контрол фокусируется раздражающе меделенно.

а кто в курсе, какие планы по поводу новой студии? чет не удалось нагуглить сходу. хочется закупиться, но свежей, дабы побольше сохранить актуальность…
А комьюнити издание не устраивает?

Мне хватает на все задачи.
Попробуйте Rider. Он сильно дешевле студии и решарпер ещё бонусом идёт.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
Местоположение
Россия
Сайт
tech.kontur.ru
Численность
5 001–10 000 человек
Дата регистрации

Блог на Хабре