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

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


S>>>В общем, ты сравниваешь свежий форк дотнета с частью более древнего форка и заявляешь, что первый оптимизирован под второй. Как-то так.

S>> Я говорю, о том, что сборки под .Net Core оптимизированы для .Net Native.
S>*терпеливо*
S>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework?

Компиляция через .NET Native — сложный процесс, немного медленнее традиционной в .NET компиляции. Преимущества, упомянутые чуть ранее, даются ценой увеличения времени компиляции. Вы могли бы выбрать компиляцию в «родной» код всякий раз, когда запускается приложение, но тогда вы тратили бы дополнительное время, ожидая окончания сборки. Инструментарий Visual Studio предназначен для устранения этой проблемы и создания максимально комфортных для разработчиков условий.
Скомпилировав и запустив программу в конфигурации Debug, вы выполняете код Intermediate Language (IL) в CoreCLR, упакованной вместе с приложением. Системные сборки .NET упаковываются наряду с кодом вашего приложения, и это приложение получает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR). Если инфраструктура CoreCLR отсутствует на устройстве, где вы тестируете, Visual Studio автоматически обнаружит это и установит ее до развертывания вашего приложения.
Это означает, что получаете максимум удобств при разработке: быструю компиляцию и установку, богатые средства отладки и диагностики и весь инструментарий, к которому вы привыкли при .NET-разработке.

Когда вы переключаетесь в режим Release, ваше приложение по умолчанию использует цепочку инструментария .NET Native. Поскольку пакет компилируется в неуправляемый двоичный код, в этом пакете не нужны библиотеки .NET Framework. Более того, пакет зависим от новейшей установленной версии исполняющей среды .NET Native в противоположность пакету CoreCLR. Исполняющая среда .NET Native на устройстве будет всегда совместима с пакетом вашего приложения.

То есть CoreClr и .Net Native выполняют один и тот же CIL код.
S>>А вот и мне интересно если разница в JIT компиляции CoreClr и обычного CLR. Вероятно есть но интересны факты.
S>*Ещё более терпеливо*
S>При чём тут full .net fw JIT? он в .net native не используется.



S>Серьёзно, давай всё-таки излагать мысли связно, и, главное, по теме
Еще раз. Был приведен код в рантайме генерировать виртуальный вызов для sealed типа

Автор: fddima
Дата: 07.03.17

Мне интересно если разница между нативным кодом
1. JIT .Net CLR
2. JIT CoreCLR
3. Net Native

Например девиртуализация есть только для CoreCLR и скорее всего и для .Net Native.

S>>>Снова бред полный, без обид. Поделитесь ссылочкой на первоисточник, аж интересно стало, кто у нас такой криптоисторик.

S>>Дэниэл Якобсон. Так я же давал. Ты не читаешь. Microsoft .NET Framework — Разработка с использованием .NET и Universal Windows Platform

S>Ухтыж, там правда такое написано Ещё и в msdn magasine. Самое смешное, что в том же абзаце есть ссылка на интервью
S>https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native
S>где говорится полностью противоположное. с 05:34, к примеру.

S>Полный .net fw не поддерживается .net native по двум простым причинам:
S>1. Технологии, на которых основан .net native чисто исторически затачивались под нужды мобильных приложений, в частности, под быстрый запуск.
S>2. Полный .net framework принципиально нельзя перенести под winrt, т.к. там недоступно множество нативных API на которых завязан код в BCL.

S>Всё остальное — это уже следствия.

И чем же оно противоречит приведенное мною?

Может основная причина все таки

Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности . Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.

А все остальное следствие?

S>>>.net native — это доведённый до ума project N...
S>> Ну в итоге то они и стали развивать .Net Core плюс купили xamarin которые кстати тоже Net Native занимались.

S>*терпение кончилось*
S>... а в киеве дядька, как и было сказано.
S>В общем перстаньте путать два похожих, но не одинаковых форка .net fw.

Еще раз, где и что я путаю?
Я специально выделил жирным что есть общего у .Net Core и Net Native и их отличие от обычного fw.
Или тебе опять слово оптимизировано не нравится

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

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


S>>>В общем, ты сравниваешь свежий форк дотнета с частью более древнего форка и заявляешь, что первый оптимизирован под второй. Как-то так.

S>> Я говорю, о том, что сборки под .Net Core оптимизированы для .Net Native.
S>*терпеливо*
S>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework?

Компиляция через .NET Native — сложный процесс, немного медленнее традиционной в .NET компиляции. Преимущества, упомянутые чуть ранее, даются ценой увеличения времени компиляции. Вы могли бы выбрать компиляцию в «родной» код всякий раз, когда запускается приложение, но тогда вы тратили бы дополнительное время, ожидая окончания сборки. Инструментарий Visual Studio предназначен для устранения этой проблемы и создания максимально комфортных для разработчиков условий.
Скомпилировав и запустив программу в конфигурации Debug, вы выполняете код Intermediate Language (IL) в CoreCLR, упакованной вместе с приложением. Системные сборки .NET упаковываются наряду с кодом вашего приложения, и это приложение получает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR). Если инфраструктура CoreCLR отсутствует на устройстве, где вы тестируете, Visual Studio автоматически обнаружит это и установит ее до развертывания вашего приложения.
Это означает, что получаете максимум удобств при разработке: быструю компиляцию и установку, богатые средства отладки и диагностики и весь инструментарий, к которому вы привыкли при .NET-разработке.

Когда вы переключаетесь в режим Release, ваше приложение по умолчанию использует цепочку инструментария .NET Native. Поскольку пакет компилируется в неуправляемый двоичный код, в этом пакете не нужны библиотеки .NET Framework. Более того, пакет зависим от новейшей установленной версии исполняющей среды .NET Native в противоположность пакету CoreCLR. Исполняющая среда .NET Native на устройстве будет всегда совместима с пакетом вашего приложения.

То есть CoreClr и .Net Native выполняют один и тот же CIL код.
S>>А вот и мне интересно если разница в JIT компиляции CoreClr и обычного CLR. Вероятно есть но интересны факты.
S>*Ещё более терпеливо*
S>При чём тут full .net fw JIT? он в .net native не используется.



S>Серьёзно, давай всё-таки излагать мысли связно, и, главное, по теме
Еще раз. Был приведен код в рантайме генерировать виртуальный вызов для sealed типа

Автор: fddima
Дата: 07.03.17

Мне интересно если разница между нативным кодом
1. JIT .Net CLR
2. JIT CoreCLR
3. Net Native

Например девиртуализация есть только для CoreCLR и скорее всего и для .Net Native.

S>>>Снова бред полный, без обид. Поделитесь ссылочкой на первоисточник, аж интересно стало, кто у нас такой криптоисторик.

S>>Дэниэл Якобсон. Так я же давал. Ты не читаешь. Microsoft .NET Framework — Разработка с использованием .NET и Universal Windows Platform

S>Ухтыж, там правда такое написано Ещё и в msdn magasine. Самое смешное, что в том же абзаце есть ссылка на интервью
S>https://channel9.msdn.com/Shows/Going+Deep/Inside-NET-Native
S>где говорится полностью противоположное. с 05:34, к примеру.

S>Полный .net fw не поддерживается .net native по двум простым причинам:
S>1. Технологии, на которых основан .net native чисто исторически затачивались под нужды мобильных приложений, в частности, под быстрый запуск.
S>2. Полный .net framework принципиально нельзя перенести под winrt, т.к. там недоступно множество нативных API на которых завязан код в BCL.

S>Всё остальное — это уже следствия.

И чем же оно противоречит приведенное мною?

Может основная причина все таки

Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности . Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.

А все остальное следствие?

S>>>.net native — это доведённый до ума project N...
S>> Ну в итоге то они и стали развивать .Net Core плюс купили xamarin которые кстати тоже Net Native занимались.

S>*терпение кончилось*
S>... а в киеве дядька, как и было сказано.
S>В общем перстаньте путать два похожих, но не одинаковых форка .net fw.

Еще раз, где и что я путаю?
Я специально выделил жирным что есть общего у .Net Core и Net Native и их отличие от обычного fw.
Или тебе опять слово оптимизировано не нравится