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

S> Да кстати посмотрел на количество чтений того же Удобный REST для Xamarin-приложений
S>всего 4.6 к .Как то грустно становится.

4.6к — это ещё много. Статьи на хабре за редчайшими исключениями читать бесполезно, вот навскидку:
* https://habrahabr.ru/post/311094/ — замеряем аллокации при суммировании элементов в массиве.
* https://habrahabr.ru/post/302076/ — читаем учебник, эмоции выкладываем в бложик.
* https://habrahabr.ru/post/309462/ — проверки на null и [NotNull] — это у нас антипаттерн.

И самое прекрасное
* https://habrahabr.ru/post/310314/ , вот этот сок мозга комментировать вообще не буду.

Что печально, уровень комментариев в топиках соответствует.
Нафиг-нафиг. Связываться с этим рен-тв от it — только карму портить.

https://github.com/dotnet/corefx/issues/15135

• 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)

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


Почему то новость стороной прошла
Optimising LINQ

А то копья все ломают про производительность Linq

roslyn-linq-rewrite

.NET Standard 2.0 is final

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

S> Почему то новость стороной прошла
S>Optimising LINQ

Не прошла, постить смысла 0, ибо народу нет. Раз уж не поленился, то докину:
https://twitter.com/xjoeduffyx/status/771023674694524932
http://xoofx.com/blog/2015/10/08/stackalloc-for-class-with-roslyn-and-coreclr/

плюс пару отличных выступлений на тему "как с этим жить"
https://www.infoq.com/presentations/csharp-systems-programming
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/DEV-B333

и под конец — пара proposals, которые добивает оставшиеся типовые грабли с GC.
https://github.com/dotnet/coreclr/issues/1235
https://github.com/dotnet/coreclr/issues/1236

S>А то копья все ломают про производительность Linq
Да не ломает никто, кому работать надо — всё давно хожено и перехожено.

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


https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/

Результаты в сравнении с 4.7 впечатляют

Вот еще тесты Акиншина

http://aakinshin.net/blog/post/stephen-toub-benchmarks-part1/

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

S> .NET Standard это стандарт для библиотек. .NET Standard Library – адекватный стандарт?
Охх, переставайте читать хабр. По ссылке — заповедник наркоманов качественная_журналистика™. Или дурь в каждом приложении, или устаревшая информация.

Вскорости Microsoft приобрел Xamarin, что сразу привнесло поддержку Xamarin в PCL

Xamarin PCL support — 2013й год, покупка Xamarin — 2016й. "Не выиграл, а проиграл…" и далее по тексту

Не, ну как? Как можнописать что-то по теме, поленившись проверить инфу?
Тынц на статью здорового человека.


S>А какой смысл MS делать WPF кроссплатформенным? Зачем делать конкурента для декстопа?
Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.


S>Asp.Net Core для поддержки Azure. Их главная цель Azure именно на ней они зарабатывают и будут зарабатывать.
Зарабатывать пока не очень получается, но тенденция явно положительная. Вот из годового fiscal report:

"Note: Service revenue exceeded 10% of total revenue for the first time in fiscal year 2016. As a result, we have separately disclosed product revenue from service and other revenue in our consolidated income statements.

Product revenue includes sales from operating systems; cross-device productivity applications; server applications; business solution applications; desktop and server management tools; software development tools; video games; hardware such as PCs, tablets, gaming and entertainment consoles, phones and other intelligent devices and related accessories; training and certification of computer system integrators and developers.

Service and other revenue includes sales from cloud-based solutions that provide customers with software, services, platforms, and content such as Office 365, Azure, Dynamics CRM Online, and Xbox Live; solution support; and consulting services. Service and other revenue also includes sales from online advertising.
"

(c)

Здравствуйте, 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.

(c)

*quadro_facepalm.png*

QrystaL выше то же самое запостил.

AVK>Зачем тащить все это порно, если под кором я код не запускал и не собираюсь?

А это log4net не смогли в dependencies в nuspec.

  <group targetFramework="net40">...</group>  для кого придумали, спрашивается?:))

UPD Починено.
Я таки ничего не буду говорить, но в приличных домах на ci-сервере таки крутится догфудинг-версия тестов. Именно по этой причине.

The RyuJIT transition is complete!
Радует

ARM64 architecture support in RyuJIT is close to preview quality in .NET Core 2.1, and was built from the start of its implementation on the RyuJIT architecture. We’ve actually been working on ARM64 support in RyuJIT for over four years, and this work was pushed forward more recently with significant work by Qualcomm contributors.
Overall, our RyuJIT investments have been focused on evolving the code base towards enabling better support for:
Multiple code generation targets (instruction sets and operating systems),
Improved optimizations,
Better and more flexible code generation, and
Open, flexible, and robust design and implementation.
We believe that the new RyuJIT compiler architecture is a major improvement over the (now-removed) legacy code generator for achieving these goals.
We have recently invested in new code generation technology solely in the RyuJIT code generator, for example, SIMD support, architecture-specific hardware intrinisics, and support for the Linux software conventions.
It’s very satisfying to get to this point, and we can already see how removing all this old code will free us to be more agile going forward.
Thanks to everyone who contributed to this long effort!

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

AVK>>При чем тут DirectX? Речь о публичном API WPF.
T>И где там камень преткновения?

А это уже ХЗ, я настолько глубоко в тему не вникал. Но те кто вникал один голос говорят, что WPF кроссплатформенно реализовать нельзя.

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

S> Дя я про то, что мою статью закинули в чулан.

Ну дык хабр же. Там в комментариях всё написано —

Вставлю свои 5 копеек. Про Хабр часто говорят, что дескать нет технических статей, только реклама. Вот вам автор, который написал 9 статей. Хороших таких статей про работу .NET/1C, котоые потом вполне возможно будутпользоваться спросом, в свое время. Но его заминусовали (карма) за руслиш

Дело в том, что хабр — развлекательный ресурс (у администрации немножко пена изо рта капает, когда им про это намекают, но это их проблемы). Поэтому уникальный контент, если он тяжело читается (а читается действительно адово), там неформат.
Ближайший аналог — всякие какэтосделано, в которых скучный хардкор не катит, ибо не цепляет аудиторию.

Рекомендую не заморачиваться и подобрать нормальную площадку, или завести блог и кросспостить статьи и туда.

S>Updating Visual Studio 2017 Release Candidate
Нет, только Release + SP3 можно начинать смотреть.

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

Кстати интересная статья .NET Native Performance and Internals

Там по сути там любимые сишниками тесты

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 студии.

Вот данные в VS 2015

AddVectors — 1.35302ms
NativeAddVectors — 0.93864ms
AddScalarToVector — 1.18009ms
NativeAddScalarToVector — 0.7964ms
InterfaceDevirtualization — 3.06194ms
AbstractClassDevirtualization — 2.22129ms
Memcpy — 1.07673ms
NativeMemcpy — 0.45323ms
MulDivShifts — 5.24405ms
NativeMulDivShifts — 4.65341ms
RectangularMatrixMultiplication — 83.31062ms
JaggedMatrixMultiplication — 44.85074ms
NativeMatrixMultiplication — 18.64064ms
Mandelbrot — 11.69964ms
NativeMandelbrot — 15.41565ms
Discrepancies on Mandelbrot: 0

Вот тот же код для VS 2017 только для манагед. С++ пока ошибка. Нужно скомпилировать под win 10

AddVectors — 0,83342ms
AddScalarToVector — 0,50806ms
InterfaceDevirtualization — 2,14707ms
AbstractClassDevirtualization — 2,16749ms
Memcpy — 0,68196ms
MulDivShifts — 4,61984ms
RectangularMatrixMultiplication — 37,0944ms
JaggedMatrixMultiplication — 36,38963ms
Mandelbrot — 9,40842ms

То есть ускорение в 1.5-2 раза
И очень близко к реальному нативу

Cltkfk

Сделал отчет для .Net Core

AddVectors — 1,2154ms
AddScalarToVector — 0,99208ms
InterfaceDevirtualization — 2,79406ms
AbstractClassDevirtualization — 2,14465ms
Memcpy — 0,6675ms
MulDivShifts — 4,8818ms
RectangularMatrixMultiplication — 85,2632ms
JaggedMatrixMultiplication — 40,28376ms
Mandelbrot — 10,1158ms

Для .Net Core 2

AddVectors — 1,14375ms
AddScalarToVector — 0,79344ms
InterfaceDevirtualization — 0,308ms
AbstractClassDevirtualization — 0,30543ms
Memcpy — 0,666 ms
MulDivShifts — 4,97312ms
RectangularMatrixMultiplication — 125,5858ms
JaggedMatrixMultiplication — 67,31645ms
Mandelbrot — 10,0221ms

Интересно, что

InterfaceDevirtualization,AbstractClassDevirtualization ускорился раз в 10, а скорость
RectangularMatrixMultiplication,JaggedMatrixMultiplication наоборот увеличилась в 1,5 раза

Для .Net Native
Просто выбросила
InterfaceDevirtualization — 9E-05ms
AbstractClassDevirtualization — 3E-05ms

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

S>Надо как то собрать все новости в одну кучу. Пока все разрозненно
Кэп:

	открою страшную тайну
	RSS. В частности, The Morning Brew + остальное по вкусу.

.Net core 1.1 RTM

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

V>>Заметь, что в виндах для разных процов используются разные "драйвера" этих процессоров. А на самом деле там разные микроядра для каждой архитектуры, ведь банально сохранять при переключении контекста надо разный набор регистров (даже не углубляясь в другие отличия процов).
S> Угу как раз компиляция то идет в магазине или подбирается код к уже скомпиленному коду для этой машины.
S>Ты хоть читаешь про технологии о чем обсуждаешь?

.NET Native в случае x64 компилирует для некоей универсальной машины, заточки под конкретную архитектуру там нет. Если что — это информация из первых рук, от авторов.

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


Надо как то собрать все новости в одну кучу. Пока все разрозненно

Удобный REST для Xamarin-приложений
Reusing Configuration Files in ASP.NET Core

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

S>>Announcing the October 2016 Update for .NET Core 1.0
S> Почемуто в edge вставка ссылки не работает

ну это совсем не для всех актуально. Только инсталлятор под МакОсь обновлен:

We are releasing an update today which addresses an issue installing on a clean macOS Sierra system. The change is limited to the macOS installer. There are no changes in the runtime or tools; .NET Core 1.0.1 remains the latest release for Windows and Linux and the latest Microsoft.NETCore.App version remains 1.0.1.

S>Introducing .NET Standard
S>Удобный REST для Xamarin-приложений

В чем смысл .NET Standard?
Почему не сделать .NET Framework наконец то кроссплатформенным, каким он собственно и должен был быть с самого начала. Может быть я хочу на WPF писать под iOS. А нет жуйте сырой хамарин.

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

AVK>>Нереально обеспечить 100% совместимость со старыми версиями, оставаясь кроссплатформой.
T>Совместимость MS обеспечивает установкой всех предыдущих версий, например DirectX-ов.

При чем тут DirectX? Речь о публичном API WPF.

S> Интересное интервью «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)

Это не хаос, а попытка без какой либо стратегии со стороны MS объять необъятное (надо же чем то занять 100 тыщ. программистов).

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

S> Кстати а есть возможность компилировать TS в asm.js?
S> Нашел только старую тему https://github.com/Microsoft/TypeScript/issues/375

Прямо по ссылке расписано почему нет
То же самое касается WebAssembly. GC там пока тоже нет.

.NET Core 3.0 is already battle-tested by being hosted for months at dot.net and on Bing.com. Many other Microsoft teams will soon be deploying large workloads on .NET Core 3.0 in production.

Announcing .NET Core 3.0

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

S>>>>Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.
S>>> Ну Xamsrin то не для декстопа. Там авалония пробивается, но ...
S>>UWP поддерживается. В любом раскладе портировали бы не взрослый WPF, а наследника silverlight, т.е. получилось бы то же самое.

S>Хотя здесь пишут https://habrahabr.ru/post/255683/ что для silverlight использует для отрисовки CPU

Именно так. При чем ускорить сервелат в ряде сценариев можно очень просто — работать прямо с массивом байт/пикселей. Что интересно, JS + Canvas будет работать гораздо быстрее а проблем гораздо меньше.

Вообще, у Микрософта кучка софта выходит именно на JS. Например Visual Studio Code, Azure Explorer и тд. Вот такие нынче дотнеты.

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

AVK>>
AVK>>Где ты этого надмозга откопал?
S> Ну это типа
S>

S>Марко Чеккони, инженер Stack Overflow из Лондона.

http://lurkmore.to/%D0%9D%D0%B0%D0%B4%D0%BC%D0%BE%D0%B7%D0%B3

S> А что такое Vanilla?

https://en.wikipedia.org/wiki/Plain_vanilla

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

S> А вот нет там ссылок на русскоязчные сайты

А вот нет нормальных русскоязычных блоггеров по дотнету почти. Смысла 0, ибо аудитории нет.
Только Сергей Тепляков и Андрей Акиньшин изредка что-то постят. Да и то у последнего статьи сначала на английском выходят как правило.

Announcing UWP Support for .NET Standard 2.0

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

S>Хотя здесь пишут https://habrahabr.ru/post/255683/ что для silverlight использует для отрисовки CPU

Как обычно, есть нюанс.
И оттуда же

Important Note:
Silverlight for Windows Phone has a different set of operations that can use GPU acceleration, and a different default behavior; for more information, see Graphics in Silverlight for Windows Phone.

В WinRT/UWP с отрисовкой всё очень неплохо. И не только с отрисовкой. Большинство встроенных приложений десятки, включая новый скайп — c# + .net native. Как там насчёт тормозов?

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

S>Introducing .NET Standard

Это единственное, что может выжить после .NETCore-апокалипсиса. Окно возможностей стало закрываться в начале весны. Хипстеры-разработчики почувствовали скорый зашквар и спешно сплюнули "релиз", который даже не смогли переименовать в релиз, так и оставив Preview2.

После обьявлении о .NET Standard, про .NET Core даже говорить нечего, просто почитайте комментарии по ссылке. Это уже не конвульсии, это — последние исдыхания.

Ну и в довесок: .NET Core Google Trends. Там только Редмонд и раджикумары.

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

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

S>>Хотя здесь пишут https://habrahabr.ru/post/255683/ что для silverlight использует для отрисовки CPU

S>Как обычно, есть нюанс.
S>И оттуда же
S>

S>Important Note:
S>Silverlight for Windows Phone has a different set of operations that can use GPU acceleration, and a different default behavior; for more information, see Graphics in Silverlight for Windows Phone.

S>В WinRT/UWP с отрисовкой всё очень неплохо. И не только с отрисовкой. Большинство встроенных приложений десятки, включая новый скайп — c# + .net native. Как там насчёт тормозов?
Я к тому, что WPF, XAML UWP ориентирован на DirectX который есть и на мобильниках. Про Xamarin.Forms не знаю.
Только вижу, что MS наплевать на кроссплатформенный декстопный ГУИ.

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

T>В чем смысл .NET Standard?
T>Почему не сделать .NET Framework наконец то кроссплатформенным, каким он собственно и должен был быть с самого начала.

В основном потому что требования у классического виндового корпоративного сектора и у всяких линукс-сообществ довольно сильно разнятся.

T> Может быть я хочу на WPF писать под iOS. А нет жуйте сырой хамарин.

WPF практически невозможно портировать. С другой стороны, на винде это хорошее решение, в которое инвестирована куча бабла. Поэтому в кроссплатформенной версии его нет и не будет. Возможно, когда нибудь до хорошего качества дорастет похожая на WPF Авалония.

S>Пока Xamarin Forms не ахти развиваются. Очень мало контролов.

Оно то и понятно — это ж не обёрточки писать, а нужно проделать очень много работы.

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

S>>То же самое касается WebAssembly. GC там пока тоже нет.

S> Я плох в английском и перевожу с помощью Гугл переводчика
S>https://github.com/WebAssembly/design/blob/master/GC.md

Я ж не зря написал про _пока_ нет По ссылке, в первом абзаце, жирным заголовком:

NOTE: This is a future 🦄 feature!

Т.е. когда-нибудь, но не сейчас.

Здравствуйте, 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

Ну жди, чо.

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

AVK>Там вообще никаких зависимостей не было, ни старых, ни новых.

Вот смотрю я на project.json

И вижу

 "dependencies": {

        "System.AppContext": "4.1.0",

        "System.Collections.NonGeneric": "4.0.1",

        "System.Console": "4.0.0",

        "System.Diagnostics.Debug": "4.0.11",

        "System.Diagnostics.Process": "4.1.0",

        "System.Diagnostics.StackTrace": "4.0.1",

        "System.Diagnostics.TraceSource": "4.0.0",

        "System.IO.FileSystem": "4.0.1",

        "System.IO.FileSystem.Watcher": "4.0.0",

        "System.Linq": "4.1.0",

        "System.Net.NameResolution": "4.0.0",

        "System.Net.Requests": "4.0.11",

        "System.Net.Sockets": "4.1.0",

        "System.Reflection": "4.3.0",

        "System.Reflection.Extensions": "4.0.1",

        "System.Reflection.TypeExtensions": "4.1.0",

        "System.Runtime.Extensions": "4.1.0",

        "System.Runtime.InteropServices": "4.1.0",

        "System.Runtime.InteropServices.RuntimeInformation": "4.0.0",

        "System.Runtime.Serialization.Formatters": "4.3.0",

        "System.Text.RegularExpressions": "4.1.0",

        "System.Threading": "4.0.11",

        "System.Threading.Thread": "4.0.0",

        "System.Threading.Timer": "4.0.1",

        "System.Xml.ReaderWriter": "4.0.11",

        "System.Xml.XmlDocument": "4.0.1"

      }

И я сильно сомневаюсь, что в старой версии https://www.nuget.org/packages/log4net/2.0.5 был NetStandard
Просто сейчас они сделали кроссплатформенный вариант, но тащат с собой те библиотеки которые сделаны под .Net Core.
Впринципе они тебе не мешают. Они лежат в c:\Users\AndrewVK\.nuget\packages\
и особо есть то не просят, правда при компиляции они в паке с целевым файлом. В .Net Core есть режимы компиляции когда ты будешь использовать файлы из NuGet или из

Self-contained дистрибуция .NET Core приложений

Когда .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.

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

S>

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 и т.д. (зависит от объема тела цикла).

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


V>Что является минусом как раз для случая SIMD, где в ходу машинки с минимум 5-ю поколениями/версиями этого SIMD, т.е. заранее не угадаешь. И, напротив, технологии JIT или AOT могут переводить исходный байт-код в нейтивный, нацеленный на конкретный проц в системе.

V>Заметь, что в виндах для разных процов используются разные "драйвера" этих процессоров. А на самом деле там разные микроядра для каждой архитектуры, ведь банально сохранять при переключении контекста надо разный набор регистров (даже не углубляясь в другие отличия процов).

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

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

S>Introducing .NET Standard

Было уже когда-то, когда регили C# и основные классы дотнета в ECMA.
Не взлетело.
Потому что нельзя ограничивать возможность развивать либы.

По-сути, стандартом можно описать лишь минимально-возможные требования, например интерфейс базовых типов — String, Object, Int32 и т.д.
Ну еще основной ввод-вывод, потоки и таски.

Остальное должно отдаваться на откуп свободному конкурентному развитию.

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

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

S>>Introducing .NET Standard

V>Было уже когда-то, когда регили C# и основные классы дотнета в ECMA.
V>Не взлетело.
V>Потому что нельзя ограничивать возможность развивать либы.

Почитай хоть статью. Сейчас по сути 3 Net а. Обычный, PCL (Xamarin) и .Net Core.

Сейчас есть NetStandart от 1 до 1.6 который прекрасно работает. И есть куча библиотек.

V>По-сути, стандартом можно описать лишь минимально-возможные требования, например интерфейс базовых типов — String, Object, Int32 и т.д.
V>Ну еще основной ввод-вывод, потоки и таски.

V>Остальное должно отдаваться на откуп свободному конкурентному развитию.

Угу.
https://blogs.msdn.microsoft.com/dotnet/2017/03/28/the-week-in-net-on-net-with-sidarth-gupta-on-tizen-happy-birthday-net-with-bertrand-le-roy-json-net-10-gunnar-peipman/

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

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

S>>Но если можно перенести библиотеки под cshtml5, то, что мешает сделать общими библиотеки на уровне Net?

V>Я уже говорил — нельзя вносить прикладные библиотеки в некий "стандарт".
V>Любой стандарт — это гиря на ногах.
V>Каждая библиотека пусть живет своей жизнью.
V>Зависимые приложения/библиотеки пусть указывают зависимости.
V>Всё уже изобретено, не надо фантазировать.

Какие библиотеки? TS компилируется в JS и им прекрасно пользуются.
C# тоже компилируется в JS.
Это делается и прекрасно работает.

При этом в .Net Core существует модульность. Что позволяет при компиляции в .Net Native выдергивать только необходимый код.
Конечно нужно учитывать, что JS не все компоненты поддерживает. Но многое из нынешнего .Net Core вполне.

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

S>>>Но если можно перенести библиотеки под cshtml5, то, что мешает сделать общими библиотеки на уровне Net?
V>>Я уже говорил — нельзя вносить прикладные библиотеки в некий "стандарт".
V>>Любой стандарт — это гиря на ногах.
V>>Каждая библиотека пусть живет своей жизнью.
V>>Зависимые приложения/библиотеки пусть указывают зависимости.
V>>Всё уже изобретено, не надо фантазировать.

S> Какие библиотеки? TS компилируется в JS и им прекрасно пользуются.

Похоже, ты окончательно перешел на разговор с голосами в голове. ))

S>https://blogs.msdn.microsoft.com/dotnet/2017/06/07/performance-improvements-in-net-core/
S>Результаты в сравнении с 4.7 впечатляют
S> Вот еще тесты Акиншина
S>http://aakinshin.net/blog/post/stephen-toub-benchmarks-part1/

Тоже мне открыли Америку: если все чемоданы из самолета выкинуть то он станет легче и быстрее.

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

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

S>>Надо как то собрать все новости в одну кучу. Пока все разрозненно
S>Кэп:
S>

	открою страшную тайну
	S>RSS. S>В частности, The Morning Brew + остальное по вкусу.

А вот нет там ссылок на русскоязчные сайты

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

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

S>> А вот нет там ссылок на русскоязчные сайты

S>А вот нет нормальных русскоязычных блоггеров по дотнету почти. Смысла 0, ибо аудитории нет.
S>Только Сергей Тепляков и Андрей Акиньшин изредка что-то постят. Да и то у последнего статьи сначала на английском выходят как правило.

Да кстати посмотрел на количество чтений того же Удобный REST для Xamarin-приложений
всего 4.6 к .Как то грустно становится.

Здравствуйте, Sinix, Вы писали:
На самом деле мне очень нравятся твои комментарии. И много мне лично помог. Я сейчас в среде 1С ников белая ворона. В большинстве своем они предпочитают Java, .Net как красная тряпка для быка.
Сначала кричали про кроссплатформенность и размеры. Сделал на .Net Core итог обозвали адептом майкрософт. 1С это тоже не нужно. Хотя странно дают возможность расширить язык, но молчание.
При этом язык удобный, развивается активно.
Вывод нужно .Net Core (Xamarin)как то популязировать.

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

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

S>> Да кстати посмотрел на количество чтений того же Удобный REST для Xamarin-приложений
S>>всего 4.6 к .Как то грустно становится.

S>4.6к — это ещё много. Статьи на хабре за редчайшими исключениями читать бесполезно, вот навскидку:
S>* https://habrahabr.ru/post/311094/ — замеряем аллокации при суммировании элементов в массиве.
S>* https://habrahabr.ru/post/302076/ — читаем учебник, эмоции выкладываем в бложик.
S>* https://habrahabr.ru/post/309462/ — проверки на null и [NotNull] — это у нас антипаттерн.

S>И самое прекрасное
S>* https://habrahabr.ru/post/310314/ , вот этот сок мозга комментировать вообще не буду.

S>Что печально, уровень комментариев в топиках соответствует.
S>Нафиг-нафиг. Связываться с этим рен-тв от it — только карму портить.

А мою .Net Core, обмен с 1C по TCP/IP между различными устройствами
хотя и в чулане много кому понравилось. Я понимаю, что не Лев Толстой и Руслиш, но

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

S> А мою .Net Core, обмен с 1C по TCP/IP между различными устройствами
S> хотя и в чулане много кому понравилось. Я понимаю, что не Лев Толстой и Руслиш, но
Я ж сказал про "за редчайшими исключениями" ; )

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

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

S>> А мою .Net Core, обмен с 1C по TCP/IP между различными устройствами
S>> хотя и в чулане много кому понравилось. Я понимаю, что не Лев Толстой и Руслиш, но
S>Я ж сказал про "за редчайшими исключениями" ; )
Дя я про то, что мою статью закинули в чулан.

Статья осталась на сайте, просто она перемещена в хаб-оффтопик «Чулан» — своего рода место, куда отправляется всё, чему так или иначе сложно найти место в других разделах. Посты из данного хаба:
— не приносят приглашений, рейтинга, не участвуют в ППА;
— не индексируются поисковиками.
— не попадают в раздел «Лучшее»;
— не транслируются в наши сообщества в социальных сетях.

Если вы будете более внимательно вычитывать свои статьи (можно попросить коллег), то тогда ваши статьи будут находиться в профильных тематических разделах, где их будет читать целевая аудитория.

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


Огромное спасибо посмотю.
S>>А то копья все ломают про производительность Linq
S>Да не ломает никто, кому работать надо — всё давно хожено и перехожено.

Ну например
http://rsdn.org/forum/dotnet/6506104.1

Автор: Sinix
Дата: 15.07.16

Например MaxItem

int max = items.Max(i => i.ID);
var item = items.First(x => x.ID == max);

Или

Item itemMax = (from i in items
     let maxId = items.Max(m => m.ID)
     where i.ID == maxId
     select i).FirstOrDefault();

Или

var item =items.orderbydescending(i=>i.id).take(1)

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


S>Introducing .NET Standard
S>Удобный REST для Xamarin-приложений

Вот кстати перевод >Анонс .NET Standard 2.0

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


S>Announcing the October 2016 Update for .NET Core 1.0
Почемуто в edge вставка ссылки не работает

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

S>>Introducing .NET Standard
S>>Удобный REST для Xamarin-приложений

T>В чем смысл .NET Standard?
T>Почему не сделать .NET Framework наконец то кроссплатформенным, каким он собственно и должен был быть с самого начала. Может быть я хочу на WPF писать под iOS. А нет жуйте сырой хамарин.

.NET Standard это стандарт для библиотек. .NET Standard Library – адекватный стандарт?

.Net Core это кроссплатформенный Фреймворк без WPF
А какой смысл MS делать WPF кроссплатформенным? Зачем делать конкурента для декстопа?
Asp.Net Core для поддержки Azure. Их главная цель Azure именно на ней они зарабатывают и будут зарабатывать

S>.Net Core это кроссплатформенный Фреймворк без WPF
S>А какой смысл MS делать WPF кроссплатформенным? Зачем делать конкурента для декстопа?
Ты думаешь на десктопе кого то держит WPF?

S>Asp.Net Core для поддержки Azure. Их главная цель Azure именно на ней они зарабатывают и будут зарабатывать
ASP.NET обычный работает на Azure. Возможно имело бы смысл чтобы не только на Azure но нужно ли? Ведь все тогда сбегут от Azure на дешевые линуксовые сервера.
Я так понимаю делают все ради поддержки Docker-а.

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



S>Не, ну как? Как можнописать что-то по теме, поленившись проверить инфу?
S>Тынц на статью здорового человека.

Ну первая попавшаяся ссылка
Хотел Перевод адекватного человека
S>>А какой смысл MS делать WPF кроссплатформенным? Зачем делать конкурента для декстопа?
S>Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.

Ну Xamsrin то не для декстопа. Там авалония пробивается, но ...
S>>Asp.Net Core для поддержки Azure. Их главная цель Azure именно на ней они зарабатывают и будут зарабатывать.
S>Зарабатывать пока не очень получается, но тенденция явно положительная. Вот из годового fiscal report:
S>

S>"Note: Service revenue exceeded 10% of total revenue for the first time in fiscal year 2016. As a result, we have separately disclosed product revenue from service and other revenue in our consolidated income statements.

S>Product revenue includes sales from operating systems; cross-device productivity applications; server applications; business solution applications; desktop and server management tools; software development tools; video games; hardware such as PCs, tablets, gaming and entertainment consoles, phones and other intelligent devices and related accessories; training and certification of computer system integrators and developers.

S>Service and other revenue includes sales from cloud-based solutions that provide customers with software, services, platforms, and content such as Office 365, Azure, Dynamics CRM Online, and Xbox Live; solution support; and consulting services. Service and other revenue also includes sales from online advertising.
S>"

S>(c)

Ну Наделла возлагает именно на неё все надежды и вкладывают миллиарды в железо https://www.crn.ru/news/detail.php?ID=114535

Microsoft достигла сейчас уровня дохода 13 млрд. долл. в пересчете на год в своем коммерческом облачном бизнесе, что позволяет ей рассчитывать достичь поставленной цели — 20 млрд. долл. дохода к 2018 году. (Для сравнения: Amazon Web Services (AWS) готовится превысить 10 млрд. долл. объема продаж в этом году.)

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

S>>Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.
S> Ну Xamsrin то не для декстопа. Там авалония пробивается, но ...
UWP поддерживается. В любом раскладе портировали бы не взрослый WPF, а наследника silverlight, т.е. получилось бы то же самое.


S> Хотел Перевод адекватного человека

Тоже не айс. Там не перевод, а пересказ, причём здорово урезанный. Прочитать оригинал проще выйдет, чем восстанавливать Карузо по перепеву Рабиновича.

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

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

S>>>Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.
S>> Ну Xamsrin то не для декстопа. Там авалония пробивается, но ...
S>UWP поддерживается. В любом раскладе портировали бы не взрослый WPF, а наследника silverlight, т.е. получилось бы то же самое.
Да и там поддержка то UWP на уровне Xamarin.Forms

Ну, а нормальный UWP я так понимаю это тот же WPF с поддержкой DirectX. Snapdragon поддерживает DirectX. И кстати только они рекомендованы для WinMo.

А вот под другие процессоры нужно использовать OpenGL. Только MS я так понимаю это не нужно. 97% декстопов это Windows. Зачем им плодить конкурентов?

А так есть авалония https://github.com/AvaloniaUI/Avalonia

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

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

S>>>Не WPF, а аналог WinRT XAML. В итоге приобрели Xamarin.
S>> Ну Xamsrin то не для декстопа. Там авалония пробивается, но ...
S>UWP поддерживается. В любом раскладе портировали бы не взрослый WPF, а наследника silverlight, т.е. получилось бы то же самое.


Хотя здесь пишут https://habrahabr.ru/post/255683/ что для silverlight использует для отрисовки CPU

Я мог бы заняться Silverlight, но это будет излишним. Производительность рендеринга в Silverlight тоже низкая, но причины иные. Он использует для отрисовки CPU (даже для шейдеров, насколько я помню, они частично написаны на ассемблере), но CPU как минимум в 10-30 раз медленнее GPU. Это оставляем вам гораздо меньше процессорной мощности для рендеринга пользовательского интерфейса и еще меньше для логики вашего приложения. Его аппаратное ускорение очень слабо развито и почти в точности повторяет кэшированное построение WPF и ведет себя аналогичным образом, осуществляя вызов отрисовки для каждого объекта с BitmapCache (BitmapCached visual).

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

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

S>>Хотя здесь пишут https://habrahabr.ru/post/255683/ что для silverlight использует для отрисовки CPU

S>Как обычно, есть нюанс.
S>И оттуда же
S>

S>Important Note:
S>Silverlight for Windows Phone has a different set of operations that can use GPU acceleration, and a different default behavior; for more information, see Graphics in Silverlight for Windows Phone.

S>В WinRT/UWP с отрисовкой всё очень неплохо. И не только с отрисовкой. Большинство встроенных приложений десятки, включая новый скайп — c# + .net native. Как там насчёт тормозов?
Кстати, а на MONO WinForms? WPF или аналога нет?
https://www.ibm.com/developerworks/ru/library/l-Mono_5/

AVK>В основном потому что требования у классического виндового корпоративного сектора и у всяких линукс-сообществ довольно сильно разнятся.

Например?
Можно сделать в режимах:
— адаптированный (например стиль UI должен соответствовать стилю и поведению окружения на которой запущено приложение);
— не адаптированный (запускать тупо виндовые формы не смотря на окружение);
— нейтральный (разработать нейтральную тему которая устроит все платформы);

AVK>WPF практически невозможно портировать.

Сделать поддержку OpenGL нереально для WPF? Не верю.

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

AVK>>В основном потому что требования у классического виндового корпоративного сектора и у всяких линукс-сообществ довольно сильно разнятся.
T>Например?

Например, для первых неприемлемы частые релизы. Или регулярная чехарда с совместимостью.

AVK>>WPF практически невозможно портировать.
T>Сделать поддержку OpenGL нереально для WPF?

Нереально обеспечить 100% совместимость со старыми версиями, оставаясь кроссплатформой.

T>>Сделать поддержку OpenGL нереально для WPF?
AVK>Нереально обеспечить 100% совместимость со старыми версиями, оставаясь кроссплатформой.

Совместимость MS обеспечивает установкой всех предыдущих версий, например DirectX-ов.
То есть приложение писанное на DirectX 10 не будет работать через более новое API DirectX 12, а будет работать по старинке через библиотеки DirectX 10.
Возможно сейчас и приложение написанное на .NET 1.0 не запустится на .NET 4.5, а нужно будет доставлять .NET 1.0 — здесь не знаю, не проверял.

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

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

AVK>>>Нереально обеспечить 100% совместимость со старыми версиями, оставаясь кроссплатформой.
T>>Совместимость MS обеспечивает установкой всех предыдущих версий, например DirectX-ов.

AVK>При чем тут DirectX? Речь о публичном API WPF.

А как на счет XAML UWP?

AVK>При чем тут DirectX? Речь о публичном API WPF.
И где там камень преткновения?

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

S> А как на счет XAML UWP?

UWP тем более не кроссплатформенный.

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

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

S>> А как на счет XAML UWP?

AVK>UWP тем более не кроссплатформенный.
Ну относительно он все же кроссплатформенный. При этом только под 10 ки. То есть нет проблем с совместимостью со старыми версиями.
Есть Api, а что там внутри мало интересует. Он же совместим XAML Xamarin

AVK>А это уже ХЗ, я настолько глубоко в тему не вникал. Но те кто вникал один голос говорят, что WPF кроссплатформенно реализовать нельзя.

Вот тут утверждают что смогли.

_>Вот тут утверждают что смогли.

Если все так чудесно, то почему MS их не купил? А вместо этого купил какой то никому не интересный хамарин.

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

AVK>>А это уже ХЗ, я настолько глубоко в тему не вникал. Но те кто вникал один голос говорят, что WPF кроссплатформенно реализовать нельзя.
_>Вот тут утверждают что смогли.

И где там WPF?

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


S>В WinRT/UWP с отрисовкой всё очень неплохо. И не только с отрисовкой. Большинство встроенных приложений десятки, включая новый скайп — c# + .net native. Как там насчёт тормозов?

Кстати AndrewVK писал, что нельзя сделать WPF кроссплатформенным из-за совместимости со старыми версиями.
Насколько WinRT/UWP отличается от WPF?

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


S> Кстати AndrewVK писал, что нельзя сделать WPF кроссплатформенным из-за совместимости со старыми версиями.
S>Насколько WinRT/UWP отличается от WPF?
Концептуально — очень близко к silverlight, рантайм — к .net core. Точнее, это API .net core API — наследник .net WinRT, который наследник WP7, который утащил многое от silverlight+.net compact. Кто удивляется, почему в UWP нельзя создавать аппдомены — это отсюда.

Но сам UWP портировать особого смысла нет, низкоуровневые вещи выгоднее родные использовать. Поэтому как ни крути, получается всё тот же xamarin: рантайм от .net core + кроссплатформенное API для UI, включая XAML (кто тут принимает ставки? пять копеек на поддержку XAML в .core и XAML editor как часть OmniSharp API). Ну и интеграция с нативными контролами, куда ж без неё.

Плохая новость: эта тягомотина ещё на пару релизов минимум, как у MS с стабильностью планов — все уже видели?

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

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


S>> Кстати AndrewVK писал, что нельзя сделать WPF кроссплатформенным из-за совместимости со старыми версиями.
S>>Насколько WinRT/UWP отличается от WPF?
S>Концептуально — очень близко к silverlight, рантайм — к .net core. Точнее, это API .net core API — наследник .net WinRT, который наследник WP7, который утащил многое от silverlight+.net compact. Кто удивляется, почему в UWP нельзя создавать аппдомены — это отсюда.

Ну я так и предполагал В чем разница между NetFramework и NetCore

S>Но сам UWP портировать особого смысла нет, низкоуровневые вещи выгоднее родные использовать. Поэтому как ни крути, получается всё тот же xamarin: рантайм от .net core + кроссплатформенное API для UI, включая XAML (кто тут принимает ставки? пять копеек на поддержку XAML в .core и XAML editor как часть OmniSharp API). Ну и интеграция с нативными контролами, куда ж без неё.

S>Плохая новость: эта тягомотина ещё на пару релизов минимум, как у MS с стабильностью планов — все уже видели?

Кстати посмотрел новую студию, а там для Xamarin так и не появился визуальный редактор Xaml. Для UWP он есть.

А насчет стабильности, то в .Net Core уже вложили, и собираются вкладывать. Тот же Samsung c Tizen
Да и для Azure им .net core нужен и на нем они собираются зарабатывать. А вот декстопный кроссплатформенный аналог WPF в этом я сомневаюсь.
Пока Xamarin Forms не ахти развиваются. Очень мало контролов.


Если ошибаюсь, то ткни пальцем.

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

S>>Пока Xamarin Forms не ахти развиваются. Очень мало контролов.

T>Оно то и понятно — это ж не обёрточки писать, а нужно проделать очень много работы.

А вот интересные новости

Windows-смартфоны с чипами ARM могут получить режим эмуляции x86

S>Windows-смартфоны с чипами ARM могут получить режим эмуляции x86

эмуляция у меня ассоциируется с тормозами и главное чем это поможет?

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

S>>Windows-смартфоны с чипами ARM могут получить режим эмуляции x86

T>эмуляция у меня ассоциируется с тормозами и главное чем это поможет?

Ну для многих приложений это не проблема.
Главное это Continuum. То есть смартфон как компьютер.
И на смартфоне можно выполнять кучу приложений, аналогов которых ни на Андрюше ни на айфоне нет

S> Главное это Continuum. То есть смартфон как компьютер.

Сейчас это решается через RDP.

S>И на смартфоне можно выполнять кучу приложений, аналогов которых ни на Андрюше ни на айфоне нет

А нужно ли выполнять именно на смартфоне?

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

S>> Главное это Continuum. То есть смартфон как компьютер.

T>Сейчас это решается через RDP.

Для RDP нужно личные данные на сервере держать.
Кроме того если приложение активно использует видеокарту то не айс.
S>>И на смартфоне можно выполнять кучу приложений, аналогов которых ни на Андрюше ни на айфоне нет

T>А нужно ли выполнять именно на смартфоне?
Ну это считай ноутбук в кармане. Пришел в любое место где есть монитор и мышка и работай.

T>>А нужно ли выполнять именно на смартфоне?
S> Ну это считай ноутбук в кармане. Пришел в любое место где есть монитор и мышка и работай.

Это да неплохо было бы, но VS2015 никакой смартфон не потянет.

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

T>>>А нужно ли выполнять именно на смартфоне?
S>> Ну это считай ноутбук в кармане. Пришел в любое место где есть монитор и мышка и работай.

T>Это да неплохо было бы, но VS2015 никакой смартфон не потянет.

Ну сейчас смартфоны мощнее моего ноута. Но и он VS 2015 тянет.
Посмотрим. MS нужна какая то фишка, что бы WinMo популяризировать, а с ним и магазин

S> Ну сейчас смартфоны мощнее моего ноута. Но и он VS 2015 тянет.
В смартах мощность какая то не такая (вроде и ядер много афишируют и всякие видеоакселераторы но по итогу всегда фуфло выходит по сравнению с ноутом) конечно WinXP потянет с VisualStudio 6.0 но кому это сейчас нужно.

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

S>> Ну сейчас смартфоны мощнее моего ноута. Но и он VS 2015 тянет.
T>В смартах мощность какая то не такая (вроде и ядер много афишируют и всякие видеоакселераторы но по итогу всегда фуфло выходит по сравнению с ноутом) конечно WinXP потянет с VisualStudio 6.0 но кому это сейчас нужно.

https://www.pcweek.ru/mobile/article/detail.php?ID=190258

Один из сотрудников HP пояснил изданию, что для запуска x86-приложений в режиме Continuum используется программный комплекс виртуализации Citrix — с его помощью сотрудники крупных предприятий могут работать на смартфонах Elite x3 с бизнес-софтом. СМБ тем временем подключают требуемый x86-софт посредством службы HP Workspace. Надо полагать, что поддержка эмуляции на процессорном уровне может избавить бизнес-пользователей от подключения отдельной софтверной прослойки эмуляции. Эта дорогостоящая функциональность обычно нацелена на корпоративных клиентов, обходясь им в 579 долл. в год.
По данным источников, технология Cobalt сейчас находится в списке кандидатов на релиз в Redstone 3. Этот апдейт появится в Windows 10 осенью 2017 г. (до этого весной выйдет Redstone 2 «Creators Update»). Как ожидается, осенью того же года на рынок выйдет процессор Qualcomm Snapdragon 830 (MSM8998) со встроенным аппаратным эмулятором. Возможность запускать классические программы Windows на смартфонах может повысить привлекательность будущего аппарата Surface Phone, если он не окажется вымыслом и всё же поступит в продажу.
Пока что Windows 10 Mobile остаётся 32-разрядной системой.
Стоит сказать, что о поддержке ARM64 говорилось еще в начале текущего года. Однако необходимый для ее реализации объем оперативной памяти должен составлять не меньше 3,5 Гб, а такой особенностью могут похвастаться далеко не все винфоны.

Возможность запускать классические программы Windows на смартфонах может повысить привлекательность будущего аппарата Surface Phone

Только UI этих классические программ заточен на Desktop и ручками на нем не поработаешь, разве что только стилусом можно поднапрячься но будет ли его поддерживать Surface Phone неизвестно.

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

T>

T>Возможность запускать классические программы Windows на смартфонах может повысить привлекательность будущего аппарата Surface Phone

T>Только UI этих классические программ заточен на Desktop и ручками на нем не поработаешь, разве что только стилусом можно поднапрячься но будет ли его поддерживать Surface Phone неизвестно.

Это все относится к Continuum. А там и клаыиатура и монитор

T>>Только UI этих классические программ заточен на Desktop и ручками на нем не поработаешь, разве что только стилусом можно поднапрячься но будет ли его поддерживать Surface Phone неизвестно.
S> Это все относится к Continuum. А там и клаыиатура и монитор

Тогда MS-у ничего не светит, потому что клава и монитор не всегда доступны, а приложение нужно использовать здесь и сейчас (в дороге например).

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

T>>>Только UI этих классические программ заточен на Desktop и ручками на нем не поработаешь, разве что только стилусом можно поднапрячься но будет ли его поддерживать Surface Phone неизвестно.
S>> Это все относится к Continuum. А там и клаыиатура и монитор

T>Тогда MS-у ничего не светит, потому что клава и монитор не всегда доступны, а приложение нужно использовать здесь и сейчас (в дороге например).
Можешь и в дороге, только это значительно менее удобно. Аналогично RDP.
Но опять же если приложения будут пользоваться спросом, для них будут делать UWP приложения.

T>Если все так чудесно, то почему MS их не купил? А вместо этого купил какой то никому не интересный хамарин.
А нафига нужен чужой WPF если даже на свой забили?

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

T>>Если все так чудесно, то почему MS их не купил? А вместо этого купил какой то никому не интересный хамарин.
_>А нафига нужен чужой WPF если даже на свой забили?
Затем что он кроссплатформенный.

А хамарин и не WPF и псевдокроссплатформенный.

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

T>А хамарин псевдокроссплатформенный.

Это как?

T>>А хамарин псевдокроссплатформенный.
G>Это как?

Под iOS и Android нету единой кодобазы, есть конечное жалкое поделие Forms но оно сырое.

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

T>Под iOS и Android нету единой кодобазы, есть конечное жалкое поделие Forms но оно сырое.
Всмысле?
Там давно уже кросплатформенный xaml во весь рост.

Под капотом конечно треш тот ещё, но оно хотя бы работает.

T>>Под iOS и Android нету единой кодобазы, есть конечное жалкое поделие Forms но оно сырое.
S>Всмысле?
S>Там давно уже кросплатформенный xaml во весь рост.

Это он и есть но он же очень убогий.

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

S>>Там давно уже кросплатформенный xaml во весь рост.

T>Это он и есть но он же очень убогий.
Ну хоть что-то. Дальше лучше будет, если внезапно™ планы не поменяются.

T>>Это он и есть но он же очень убогий.
S>Ну хоть что-то. Дальше лучше будет, если внезапно™ планы не поменяются.

Сомневаюсь

Автор: turbocode
Дата: 22.11.16

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

T>>>А хамарин псевдокроссплатформенный.
G>>Это как?

T>Под iOS и Android нету единой кодобазы, есть конечное жалкое поделие Forms но оно сырое.

Когда говорят о кроссплатформенности Xamarin как раз имеют ввиду Forms. Xamarin без Forms — просто .NET API для каждой конкретной платформы.
Forms достаточно хорошо работает для корпоративных приложений (формочки и списки).

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

T>Сомневаюсь

Автор: turbocode
Дата: 22.11.16

Ну тут как: лучше чем сейчас и сравнимо с любым другим кросплатформенным UI-тулкитом — почему бы и нет?

Лучше, чем родные тулкиты... если Android Studio не перестанет играть в поддавки — всё, что угодно будет лучше.

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

T>>>А хамарин псевдокроссплатформенный.
G>>Это как?

T>Под iOS и Android нету единой кодобазы, есть конечное жалкое поделие Forms но оно сырое.

По этой логике вообще кроссплатформы не существует, в любой системе будут свои фреймворки для UI или будет "жалкое поделие" кроссплатформенного UI.
Разве что консольку можно кроссплатформенной сделать.

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


«Производительность – это фича». Интервью с Марко Чеккони, Stack Overflow

– Ваше решение построено полностью на С#, или есть части на других языках, типа C++, Java, Python или других?

– Я бы сказал, что на 99% у нас С#. У нас, конечно, есть немного на C++ или С, но в строчках кода это совсем мало. Естественно, у нас есть TypeScript и JavaScript. JavaScript у нас на сервере используется для компиляции бандлов и минификации кода. Мы также пользуемся SQL, это другой язык. Вот и все.

– То есть на данный момент у вас есть дополнительные резервы для того, чтобы справиться с резким наплывом посетителей, если таковой случится?

– На данный момент мы работаем на 5% от максимальной мощности. Мы можем выдержать в 20 раз большую нагрузку. Ну, это будет, конечно, тяжело, мы бы не хотели работать на все 100% все время, но в настоящий момент у нас что-то между 5 и 10%.

– Кстати, у вас есть собственная версия C#?

– У нас собственная версия Roslyn-based компилятора, в основном для компиляции razor-шаблонов, но единственное, для чего он используется – это локализация. Мы переделываем только то, что нам нужно, язык мы не расширяем. Язык Vanilla мы используем сам по себе. Основная причина, по которой мы не модифицируем язык – совместимость, это сразу ломает Visual Studio и все прочее, а мы этого не хотим.

– Используете ли какие-либо способы оптимизации железа? Например, многопоточность, hyper-threading, вычисления на GPU?

– Используем. В одном случае мы использовали CUDA для требовательных параллельных вычислений. Мы вообще много используем параллельность, но в основном для таких задач, как build. Когда мы хотим обработать несколько файлов, мы используем параллельные вычисления и многопоточность везде, где это возможно. С точки зрения кода, мы стараемся использовать sync, чтобы избежать всех external weights, таких, как weights БД. Но я не уверен, что это можно назвать истинной многопоточностью. Дайте мне подумать…

В большинстве случаев лучшая стратегия для веб-сервера – это максимальная быстрота, не надо размазываться на разные ядра. Потому что мы постоянно конкурируем с определенным количеством запросов других пользователей. Лучший вариант использования CPU в этом случае, наверное, оставить распределение запросов по ядрам для IAS. В случае использования библиотек или приложений в backend это имеет больше смысла, так как там меньше запросов и лучше использовать больше ядер на запрос. На самом деле именно для этого создавалась CUDA. Мы заметили, что увеличение количества потоков увеличило и производительность, поэтому я сказал: «Давайте это попробуем». Другой разговор, что конкретно я отдам для этого.

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

S>Язык Vanilla мы используем сам по себе.


Где ты этого надмозга откопал?

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

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

S>>Язык Vanilla мы используем сам по себе.

AVK>
AVK>Где ты этого надмозга откопал?

Ну это типа

Марко Чеккони, инженер Stack Overflow из Лондона.

А что такое Vanilla?

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

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

S>>Язык Vanilla мы используем сам по себе.

AVK>
AVK>Где ты этого надмозга откопал?

Это про изменённый компилятор Roslyn он говорил.

We use the Vanilla language itself.

Перевод хромает прост
https://medium.com/@JUGru/its-all-about-the-performance-interview-with-marco-cecconi-stack-overflow-5be0347dccb

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

AVK>Где ты этого надмозга откопал?
Хабр же.

Если устраивает не менее своеобразный английский в вопросах — тынц.

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

_NN>Перевод хромает прост

http://lurkmore.to/%D0%9D%D0%B0%D0%B4%D0%BC%D0%BE%D0%B7%D0%B3

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

I>Вообще, у Микрософта кучка софта выходит именно на JS. Например Visual Studio Code, Azure Explorer и тд. Вот такие нынче дотнеты.

Ну сейчас то интересно сравнивать с Xamarin. Сейчас изучаю Angular 2 так TS очень приятный язык. Так что скорее и у MS напрямую JS навряд ли пользуются.
Кстати а есть возможность компилировать TS в asm.js?

Нашел только старую тему https://github.com/Microsoft/TypeScript/issues/375

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


Интересное интервью «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)

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

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

S>> Кстати а есть возможность компилировать TS в asm.js?
S>> Нашел только старую тему https://github.com/Microsoft/TypeScript/issues/375

S>Прямо по ссылке расписано почему нет
S>То же самое касается WebAssembly. GC там пока тоже нет.

Я плох в английском и перевожу с помощью Гугл переводчика
https://github.com/WebAssembly/design/blob/master/FAQ.md

As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++.
However, by integrating with JavaScript at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JavaScript.
Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects 🦄. Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, "compile the VM" strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.

When WebAssembly gains the ability to access garbage-collected objects 🦄, those objects will be shared with JavaScript, and not live in a walled-off world of their own.

https://github.com/WebAssembly/design/blob/master/GC.md

After the MVP, to realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to:
reference DOM and other Web API objects directly from WebAssembly code;
call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript; and
efficiently allocate and manipulate GC objects directly from WebAssembly code.
The following document is a high-level sketch of one approach for implementing the above goals. Consider the contents incomplete and expect change over time.
An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.

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

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

S>>>То же самое касается WebAssembly. GC там пока тоже нет.

S>> Я плох в английском и перевожу с помощью Гугл переводчика
S>>https://github.com/WebAssembly/design/blob/master/GC.md

S>Я ж не зря написал про _пока_ нет По ссылке, в первом абзаце, жирным заголовком:
S>

S>NOTE: This is a future 🦄 feature!

S>Т.е. когда-нибудь, но не сейчас.

Я так понимаю, что он и сейчас еще превью http://webassembly.org/roadmap/

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

Updating Visual Studio 2017 Release Candidate

•We now have offline help available by installing the Help Viewer component in the Visual Studio installer.

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

T>•We now have offline help available by installing the Help Viewer component in the Visual Studio installer.

"Release Candidate" же. Там ещё много чего отваливаться/прикручиваться обратно будет.

P.S. По поводу троллинга вам надо в другие разделы обратиться. У нас тут уже есть ответственный за это дело товарищ, очень ответственный. Вакансия занята, короч.

T>>•We now have offline help available by installing the Help Viewer component in the Visual Studio installer.
S>"Release Candidate" же. Там ещё много чего отваливаться/прикручиваться обратно будет.
S>P.S. По поводу троллинга вам надо в другие разделы обратиться. У нас тут уже есть ответственный за это дело товарищ, очень ответственный. Вакансия занята, короч.

MS сам себя похоже троллит.

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

T>•We now have offline help available by installing the Help Viewer component in the Visual Studio installer.
T>

Хелп в preview 5 был. Видимо, нашли какую то багу, которую к RC пофиксить не успевали. Сейчас пофиксили.

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

Классный шаблон ASP.NET Core + Angular 2 template for Visual Studio

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

Кстати интересная статья про шаблоны Ionic 2 Create great looking, fast, mobile apps using JavaScript, Angular 2, and Ionic 2

Angular 2 наступает по всем фронтам

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

S>«Производительность – это фича». Интервью с Марко Чеккони, Stack Overflow <br />
<span class='lineQuote level1'>S&gt;</span>

Это не имеет никакого отношения к .NET Core.

Вот давно замечал у адептов .NET Core потуги к подмене понятий, чтобы захватить куски пирога, ничего при этом путного не сделав. В статье вообше нет такого сочетания как "Core". Ну прям Геббельсы какие-то.

Напоминаю положение вещей в исчеслении булевой алгебры:

.NET Core != .NET = true
ASP.NET Core != ASP.NET = true

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

S>Introducing .NET Standard
S>Удобный REST для Xamarin-приложений

Если представить, что .NET Framework это процессор Zilog Z80, то ближайшая аналогия для .NET Core это Intel 8008. Другими словами, не жилец в рыночых условиях.

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

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

S>>«Производительность – это фича». Интервью с Марко Чеккони, Stack Overflow <br />
<span class='lineQuote level2'>S&gt;&gt;</span>

A>Это не имеет никакого отношения к .NET Core.

A>Вот давно замечал у адептов .NET Core потуги к подмене понятий, чтобы захватить куски пирога, ничего при этом путного не сделав. В статье вообше нет такого сочетания как "Core". Ну прям Геббельсы какие-то.
Ты хоть смотрел или читал данную ссылку? Там много интересного, в том числе и .Net Core
Там есть и про .Net Core в том числе и про разработку кестрел, и Net Native ( В чем разница между NetFramework и NetCore) и много чего интересного.

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

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

S>>Introducing .NET Standard
S>>Удобный REST для Xamarin-приложений

A>Если представить, что .NET Framework это процессор Zilog Z80, то ближайшая аналогия для .NET Core это Intel 8008. Другими словами, не жилец в рыночых условиях.

Угу, а как тебе кестрел? Посмотри бенчмарки https://github.com/aspnet/benchmarks

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

S> Угу, а как тебе кестрел? Посмотри бенчмарки https://github.com/aspnet/benchmarks

Это дутые бенчмарки, потому что Кестрел никто в здравом уме не выставит на прямую на 80/443 порт из-за соображений безопасности. Сначала пропустят через Nginx или тот же IIS в прокси режиме. И какую производительность получим в результате? Как минимум такую же как у IIS или Nginx в прокси режиме или хуже.

Здравствуйте, 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 пакетов поставит. Не, я понимаю, шимы, совсмертикость с кором, но нафига мне все это на веб-сервере, где гарантированно всегда стоит самый свежий обычный фреймворк?

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

S> У меня нет других бенчмарков. Но суть в том, что .Net Core и NetStandard развиваются.

Насчет .NET Standard сомнений нет, так как он наследник PCL.

Хотелось бы верить в лучшее, но у .NET Core туманное будущее. Дело не сколько в бенчмарках, сколько в людях которые им занимаются. Подмена понятий, имитация релизов, отстутствие итеративности в проекте, попытки обьять необьятное, некоторая технологическая и идеологическая отсталость, сверх-минимальные API которые граничат с бесполезностью, постоянные изменения ради изменений. История показывает, что такие проекты не выстреливают. Буду очень удивлен если ошибаюсь.

Здравствуйте, 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

Кстати обещают к маю ET Core 2.0 Planned for Spring 2017

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

Проблема в том, что MS зарабатывает на Azure, а для неё нужен .Net Core. И нужно чем быстрее трем лучше.

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

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

S>>Ты хоть смотрел или читал данную ссылку? Там много интересного, в том числе и .Net Core

A>Статью читал. Захожу по ссылке, нажимаю Ctrl+F, ищу "kestrel", "кестрел", ".NET Core" и ничего не нахожу. Я признаю, что есть вероятность, что я делаю что-либо не так. Но за ссылку спасибо, она интересная.

Прошу прощения. Был невнимателен. Спутал с другой статьей
Интересное интервью «Хаос в .NET-мире — разумная цена за скорость развития платформы»: интервью с Андреем Акиньшиным (JetBrains)

А та статья просто из мира Net. И прежде всего про stackoverflow как пример успешности .Net.

Здравствуйте, 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>Ну жди, чо.
Мы все ждем, что бы и ты не тащил в дальнейшем кучу библиотек

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

S> .Net Native пока сырой

Есть подозрение, что со времени выхода статьи (Apr. 29, 14) его немного допилили.

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

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

S>> .Net Native пока сырой

KRT>Есть подозрение, что со времени выхода статьи (Apr. 29, 14) его немного допилили.
Опаньки! Сейчас проверю на 2017. Спасибо!