Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>> Угу, а как тебе кестрел? Посмотри бенчмарки https://github.com/aspnet/benchmarks
A>Это дутые бенчмарки, потому что Кестрел никто в здравом уме не выставит на прямую на 80/443 порт из-за соображений безопасности. Сначала пропустят через Nginx или тот же IIS в прокси режиме. И какую производительность получим в результате? Как минимум такую же как у IIS или Nginx в прокси режиме или хуже.
У меня нет других бенчмарков. Но суть в том, что .Net Core и NetStandard развиваются. Обычный .Net никуда не уйдет, а .Net Core развивается в том числе и UWP, Xamarin. Это все нужно изучать и использовать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> У меня нет других бенчмарков. Но суть в том, что .Net Core и NetStandard развиваются.
Но еще совсем недавно Portable Class Libraries тоже развивалась. И где она теперь?
Я уж не говорю что с NetStandard опять какие то чудеса. Решил я проапгрейдить log4net с 2.0.5 (вообще без зависимостей) на 2.0.6. А оно мне фигакс и предлагает заодно еще 26 пакетов поставит. Не, я понимаю, шимы, совсмертикость с кором, но нафига мне все это на веб-сервере, где гарантированно всегда стоит самый свежий обычный фреймворк?
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Serginio1, Вы писали:
S> У меня нет других бенчмарков. Но суть в том, что .Net Core и NetStandard развиваются.
Насчет .NET Standard сомнений нет, так как он наследник PCL.
Хотелось бы верить в лучшее, но у .NET Core туманное будущее. Дело не сколько в бенчмарках, сколько в людях которые им занимаются. Подмена понятий, имитация релизов, отстутствие итеративности в проекте, попытки обьять необьятное, некоторая технологическая и идеологическая отсталость, сверх-минимальные API которые граничат с бесполезностью, постоянные изменения ради изменений. История показывает, что такие проекты не выстреливают. Буду очень удивлен если ошибаюсь.
Re[4]: «Производительность – это фича». Интервью с Марко Чек
Здравствуйте, Serginio1, Вы писали:
S>Ты хоть смотрел или читал данную ссылку? Там много интересного, в том числе и .Net Core
Статью читал. Захожу по ссылке, нажимаю Ctrl+F, ищу "kestrel", "кестрел", ".NET Core" и ничего не нахожу. Я признаю, что есть вероятность, что я делаю что-либо не так. Но за ссылку спасибо, она интересная.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
S>> У меня нет других бенчмарков. Но суть в том, что .Net Core и NetStandard развиваются.
AVK>Но еще совсем недавно Portable Class Libraries тоже развивалась. И где она теперь?
Плавно переходит в NetStandard AVK>Я уж не говорю что с NetStandard опять какие то чудеса. Решил я проапгрейдить log4net с 2.0.5 (вообще без зависимостей) на 2.0.6. А оно мне фигакс и предлагает заодно еще 26 пакетов поставит. Не, я понимаю, шимы, совсмертикость с кором, но нафига мне все это на веб-сервере, где гарантированно всегда стоит самый свежий обычный фреймворк?
Там log4net был видно старый NetStandard, а в 2.0.6 скорее 1.6 который сделан под .Net Core и тащит кучу библиотек.
Ждемс .Net Core 1.2 и NetStandard 2.0 который кстати ориентирован на .Net 4.6.1
Здравствуйте, Serginio1, Вы писали:
AVK>>Но еще совсем недавно Portable Class Libraries тоже развивалась. И где она теперь? S> Плавно переходит в NetStandard
Плавно? Ну ну.
S> Там log4net был видно старый NetStandard
Там вообще никаких зависимостей не было, ни старых, ни новых.
S>а в 2.0.6 скорее 1.6 который сделан под .Net Core и тащит кучу библиотек.
1.3
Только к чему эти все рассказы, если оно хочет 26 пакетов поставить? Ну стоит же в настройках проекта — FW 4.6.2. Зачем тащить все это порно, если под кором я код не запускал и не собираюсь?
S>Ждемс .Net Core 1.2 и NetStandard 2.0 который кстати ориентирован на .Net 4.6.1
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>>Ты хоть смотрел или читал данную ссылку? Там много интересного, в том числе и .Net Core
A>Статью читал. Захожу по ссылке, нажимаю Ctrl+F, ищу "kestrel", "кестрел", ".NET Core" и ничего не нахожу. Я признаю, что есть вероятность, что я делаю что-либо не так. Но за ссылку спасибо, она интересная.
Здравствуйте, AndrewVK, Вы писали:
AVK>1.3 AVK>Только к чему эти все рассказы, если оно хочет 26 пакетов поставить? Ну стоит же в настройках проекта — FW 4.6.2. Зачем тащить все это порно, если под кором я код не запускал и не собираюсь?
Возможно они Scripting Api (Roslyn), а он как раз и тащит кучу библиотек S>>Ждемс .Net Core 1.2 и NetStandard 2.0 который кстати ориентирован на .Net 4.6.1
AVK>Ну жди, чо.
Мы все ждем, что бы и ты не тащил в дальнейшем кучу библиотек
и солнце б утром не вставало, когда бы не было меня
И я сильно сомневаюсь, что в старой версии https://www.nuget.org/packages/log4net/2.0.5 был NetStandard
Просто сейчас они сделали кроссплатформенный вариант, но тащат с собой те библиотеки которые сделаны под .Net Core.
Впринципе они тебе не мешают. Они лежат в c:\Users\AndrewVK\.nuget\packages\
и особо есть то не просят, правда при компиляции они в паке с целевым файлом. В .Net Core есть режимы компиляции когда ты будешь использовать файлы из NuGet или из
Когда .NET Core устанавливается, то он находится, например, в C:\program files\dotnet на Windows. В директории “Shared” есть куча .NET штук, которые, скажем так, shared т.е. общие. Может быть множество директорий внутри, как вы можете увидеть ниже в моей папке на скриншоте. У вас может быть множество установок .NET Core.
Когда вы устанавливаете свое приложение и его зависимости, НО НЕ .NET Core само, то вы зависите от .NET Core, которое уже установлено на целевой машине. Это прекрасно для Web Apps или для систем с большим количеством приложений, но что если я захочу написать приложение и дать его вам в качестве zip или на usb флешке и я просто хочу чтобы оно работало. Я могу включить .NET Core в придачу, тогда из всего это и получится Self Contained Deployment.
и солнце б утром не вставало, когда бы не было меня
Build from source
Value: Simplify on-boarding of new Linux distros
As we have worked more in the open source space we finally made the realization that the source itself is also a product and we need to enable others to easily consume and build our full product from the source code itself. Our engineering system had numerous problems that made it difficult to bootstrap and build a full product from source with minimal external dependencies.
Package reduction
Value: .NET Core is now 1 package instead of 100's of tiny packages
We realized that we went overboard with the number of individual library packages we have. While it enables a very flexible system it also greatly increases the complexity of composing a fully functional framework.
Other changes
Build produces flat product layout which is ready for execution
Better build defaults (use your environment)
Здравствуйте, AndrewVK, Вы писали:
AVK>Я уж не говорю что с NetStandard опять какие то чудеса. Решил я проапгрейдить log4net с 2.0.5 (вообще без зависимостей) на 2.0.6. А оно мне фигакс и предлагает заодно еще 26 пакетов поставит. Не, я понимаю, шимы, совсмертикость с кором, но нафига мне все это на веб-сервере, где гарантированно всегда стоит самый свежий обычный фреймворк?
А это последствия NIH и попытки изобрести сборки заново, в виде нюгет-пакетов. Три года про неизбежный бардак предупреждали, результат — "изобретение" метапакетов, которые работают только с новым форматом проектов и толком будут работать только в следующем .net standard, не 2.0 который, а следующий. Энжой, как говорится.
UPD: да ёжтвоютак, они сделали это снова:
Package reduction
Value: .NET Core is now 1 package instead of 100's of tiny packages
We realized that we went overboard with the number of individual library packages we have. While it enables a very flexible system it also greatly increases the complexity of composing a fully functional framework.
MatrixMultiplication — Выполняет наивное O (n ^ 3) умножение двух целых матриц. Есть две версии этого кода — для прямоугольных (многомерных) и неровных массивов. Хороший оптимизирующий компилятор может выполнять здесь несколько оптимизаций, таких как замена циклов, векторизация, FMA и т. Д.
Рабочий стол JIT RectangularMatrixMultiplication — 50.30814ms
.NET Native RectangularMatrix Multiplication — 187.3474ms
Рабочий стол JIT JaggedMatrixMultiplication — 33.11678ms
.NET Native JaggedMatrixMultiplication — 33.08566ms
C ++ Matrix Multiplication — 21.11234ms
Мандельброт — вычисляет множество Мандельброта в заданных измерениях. Это контрольный показатель, который не имеет доступа к большому количеству памяти, но работает с узким циклом с умножениями и дополнениями, которые могут извлечь выгоду из векторизации, интеллектуального распределения регистров, переопределения команд и других соображений, которые использует оптимизирующий компилятор. Из всех приведенных выше показателей это, пожалуй, самый реалистичный с точки зрения количества и качества кода.
Обои для рабочего JIT Mandelbrot — 32.18214ms
.NET Native Mandelbrot — 46.48744ms
C ++ Mandelbrot — 15.26277ms
Полученные результаты довольно убедительны. На данный момент .NET Native не использует никаких оптимизаций супер-умного компилятора, которые приводят его производительность в соответствие с кодом на C ++. В некоторых случаях он даже генерирует код, который не подпадает под JIT рабочего стола (в частности, прямоугольные массивы и тесты Mandelbrot). Важно помнить, что это все еще предварительный просмотр, и я буду очень рад повторить эти измерения, когда будет выпущена обновленная версия .NET Native. Я знаю, что команда .NET Native активно работает над оптимизацией компилятора.
Пока C++ в сложных для .Net Jita алгоритмах проигрывает C++ в 2 раза. .Net Native пока сырой
Это данные от 14 года.
Скомпилировал на 2017 студии.
InterfaceDevirtualization,AbstractClassDevirtualization ускорился раз в 10, а скорость
RectangularMatrixMultiplication,JaggedMatrixMultiplication наоборот увеличилась в 1,5 раза
Для .Net Native
Просто выбросила
InterfaceDevirtualization — 9E-05ms
AbstractClassDevirtualization — 3E-05ms
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, KRT, Вы писали:
KRT>Здравствуйте, Serginio1, Вы писали:
S>> .Net Native пока сырой
KRT>Есть подозрение, что со времени выхода статьи (Apr. 29, 14) его немного допилили.
Опаньки! Сейчас проверю на 2017. Спасибо!
и солнце б утром не вставало, когда бы не было меня
S>MatrixMultiplication — Выполняет наивное O (n ^ 3) умножение двух целых матриц. Есть две версии этого кода — для прямоугольных (многомерных) и неровных массивов. Хороший оптимизирующий компилятор может выполнять здесь несколько оптимизаций, таких как замена циклов, векторизация, FMA и т. Д.
S>Рабочий стол JIT RectangularMatrixMultiplication — 50.30814ms
S>.NET Native RectangularMatrix Multiplication — 187.3474ms
S>Рабочий стол JIT JaggedMatrixMultiplication — 33.11678ms
S>.NET Native JaggedMatrixMultiplication — 33.08566ms
S>C ++ Matrix Multiplication — 21.11234ms
По-идее, при одинаковом уровне косвенности и в сценарии возможной оптимизации в дотнете проверки на границы массива в цикле, дотнетный код должен вести себя практически так же как нейтивный в целочисленных операциях. Я это еще лет 10 назад озвучивал, т.к. тоже получал близкие значения. Там нейтив немного выигрывал лишь за счёт раскрутки тела цикла с кратностью 8/16/32 и т.д. (зависит от объема тела цикла).
V>По-идее, при одинаковом уровне косвенности и в сценарии возможной оптимизации в дотнете проверки на границы массива в цикле, дотнетный код должен вести себя практически так же как нейтивный в целочисленных операциях. Я это еще лет 10 назад озвучивал, т.к. тоже получал близкие значения. Там нейтив немного выигрывал лишь за счёт раскрутки тела цикла с кратностью 8/16/32 и т.д. (зависит от объема тела цикла).
Ну еще есть SIMD оптимизации. JIT должен отрабатывать быстро, а вот Net Native может оптимизировать машинный код.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>По-идее, при одинаковом уровне косвенности и в сценарии возможной оптимизации в дотнете проверки на границы массива в цикле, дотнетный код должен вести себя практически так же как нейтивный в целочисленных операциях. Я это еще лет 10 назад озвучивал, т.к. тоже получал близкие значения. Там нейтив немного выигрывал лишь за счёт раскрутки тела цикла с кратностью 8/16/32 и т.д. (зависит от объема тела цикла). S>Ну еще есть SIMD оптимизации. JIT должен отрабатывать быстро
SIMD — это НЕ оптимизации. Это задействование имеющихся дополнительных регистров и операций над ними или нет. Т.е. речь лишь о том, что для плавающей арифметики использование SIMD не было реализовано, но могло бы быть запросто.
S>а вот Net Native может оптимизировать машинный код.
Что является минусом как раз для случая SIMD, где в ходу машинки с минимум 5-ю поколениями/версиями этого SIMD, т.е. заранее не угадаешь. И, напротив, технологии JIT или AOT могут переводить исходный байт-код в нейтивный, нацеленный на конкретный проц в системе.
Заметь, что в виндах для разных процов используются разные "драйвера" этих процессоров. А на самом деле там разные микроядра для каждой архитектуры, ведь банально сохранять при переключении контекста надо разный набор регистров (даже не углубляясь в другие отличия процов).
V>Что является минусом как раз для случая SIMD, где в ходу машинки с минимум 5-ю поколениями/версиями этого SIMD, т.е. заранее не угадаешь. И, напротив, технологии JIT или AOT могут переводить исходный байт-код в нейтивный, нацеленный на конкретный проц в системе.
V>Заметь, что в виндах для разных процов используются разные "драйвера" этих процессоров. А на самом деле там разные микроядра для каждой архитектуры, ведь банально сохранять при переключении контекста надо разный набор регистров (даже не углубляясь в другие отличия процов).
Угу как раз компиляция то идет в магазине или подбирается код к уже скомпиленному коду для этой машины.
Ты хоть читаешь про технологии о чем обсуждаешь?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
V>>Заметь, что в виндах для разных процов используются разные "драйвера" этих процессоров. А на самом деле там разные микроядра для каждой архитектуры, ведь банально сохранять при переключении контекста надо разный набор регистров (даже не углубляясь в другие отличия процов). S> Угу как раз компиляция то идет в магазине или подбирается код к уже скомпиленному коду для этой машины.
-1
Это не работает для десктопной 10-ки.
S>Ты хоть читаешь про технологии о чем обсуждаешь?
