Здравствуйте, fddima, Вы писали:
F>При этом это элементарная оптимизация которая доступна для JIT не включая мозг. ADD: Более того — очевидно, разработчики компилятора C# на это и расчитывали, поэтому всегда не стеснялись эмиттить callvirt, даже там, где они могли бы генерировать call.
Я кстати вчера ещё забыл один момент — это сборки:
1. Определяем SealedClass в сборке A.
2. Определяем метод Foo в сборке B. Предположим, что компилятор делает оптимизацию.
3. Однажды, в сборке A "распечатываем класс" и даём ему новых наследников. Перекомпилируем, деплоим. B — оставляем неизменной.
4. Ooops.
Т.е. в заданной модели деплоймента с символическим связыванием, где зависимые сборки не обязаны быть перекомпилированы — если C# компилятор начнет здесь делать свои оптимизации, то до добра это не доведёт (некорректный код vs потеря оптимазации).
Соответственно — это как раз случай, где JIT и должен блистать на "неоптимизированном" IL + компилятор проще. Опять же начиная с дотнета 1.0 — хаоса в деплойменте было много. Так что (имхо) немаловажный и учтенный фактор.
PS: Хотя, как по мне — вышеописанный сценарий в нормальном понимании не должен существовать — изменение зависимостей является прямой посылкой к соданию нового артефакта/версии (т.е. перекомпиляции B). Но на практике — иногда всё же это удобно опускать. По крайней мере в полновесных дотнетах.
Здравствуйте, Gattaka, Вы писали:
G>Здравствуйте, rameel, Вы писали:
R>>А что там верить, берешь да проверяешь) Вот для твоего примера со стековерфлоу для sealed class / sealed override R>>
Здравствуйте, Sinix, Вы писали:
F>>Можно ли и если да, то с помощью каких подходов/оптимизаций устранить виртуальный вызовы? S>escape analysis + аллокация на стеке => девиртуализация + инлайнинг методов.
Чисто пофантазировать: не мог бы (WPO) компилятор определить реально используемые типы stream, и ввести новый тип MyWriter'1 конструируемый от ConcreteStream? Естественно можно читерить (т.е. безотносительно существующих рантаймов).
Как такой анализ мог бы называться или это вообще не имеет смысла (так как традиционные техники проще и дают лучшие результаты)?
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Sinix, Вы писали:
F>>>Можно ли и если да, то с помощью каких подходов/оптимизаций устранить виртуальный вызовы? S>>escape analysis + аллокация на стеке => девиртуализация + инлайнинг методов. F> Чисто пофантазировать: не мог бы (WPO) компилятор определить реально используемые типы stream, и ввести новый тип MyWriter'1 конструируемый от ConcreteStream? Естественно можно читерить (т.е. безотносительно существующих рантаймов).
F> Как такой анализ мог бы называться или это вообще не имеет смысла (так как традиционные техники проще и дают лучшие результаты)?
Ну в C++ компилятор то так и делает.
При этом оптимизацию можно делать еще на этапе CIL кода
Здравствуйте, Serginio1, Вы писали:
S> Ну в C++ компилятор то так и делает.
Что-то очень сомневаюсь. В C++ дополнительные специализации легко вводятся через шаблоны, а с остальным, имхо, справляется как раз то, что описал Sinix, ну и куча других приблуд.
S>При этом оптимизацию можно делать еще на этапе CIL кода S>roslyn-linq-rewrite
Это немножко из другой оперы: это локальный "lowering". То, что появляются такие проекты — это хорошо. Но дело в том, что качественный инлайнинг (или в случае отказа инлайна => порождение специализации) и девиртуализация могут существенно снизить выигрыш от таких конкретных трансформаций или же вообще сделать их ненужными. Ровно как могут сделать ненужными и динамическую диспетчеризацию Linq/Enumerable.cs,19 (ну или конкретно подавить из генерируемого кода всё что не относится к типу с которым работаем, сохраняя при этом это всё в обобщенных случаях).
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
S>> Ну в C++ компилятор то так и делает. F> Что-то очень сомневаюсь. В C++ дополнительные специализации легко вводятся через шаблоны, а с остальным, имхо, справляется как раз то, что описал Sinix, ну и куча других приблуд.
S>>При этом оптимизацию можно делать еще на этапе CIL кода S>>roslyn-linq-rewrite F> Это немножко из другой оперы: это локальный "lowering". То, что появляются такие проекты — это хорошо. Но дело в том, что качественный инлайнинг (или в случае отказа инлайна => порождение специализации) и девиртуализация могут существенно снизить выигрыш от таких конкретных трансформаций или же вообще сделать их ненужными. Ровно как могут сделать ненужными и динамическую диспетчеризацию Linq/Enumerable.cs,19 (ну или конкретно подавить из генерируемого кода всё что не относится к типу с которым работаем, сохраняя при этом это всё в обобщенных случаях).
Давай возьмем С++. Там компилятор работает с кодом и с генерацией кода при специализации шаблона.
Здесь вопрос, что проще раскрутить CIL или C#. Например с лямбдами по моему проще исходный код. Но я не спец в компиляторах.
Плюс оптимизация при компиляции в СIL код, уменьшает затраты при JIT компиляции.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Давай возьмем С++. Там компилятор работает с кодом и с генерацией кода при специализации шаблона.
Это не сильно что-то меняет — JIT тоже генерирует код. Даже кое-какие оптимизации есть. Здесь же ж ключевое это AOT vs JIT (и то — в основном — количество времени которое мы готовы отдать на оптимизацию). Но создать набор хинтов JIT-у во время компиляции или во время исполнения — никто не мешает. Я же говорил немного иное — если грубо — в C++ с шаблонами — оптимизатору не нужно пытаться самому выявлять шаблоны — программист об этом уже озаботился (может быть). Если же шаблоны не использовать — мы и в C++ получим те же самые виртуальные вызовы в общем случае. И их устранение в довольно конкретных. Я и грю — что не видел что бы оптимизаторы вводили новые типы как этот процесс. Если это не так — рад любой ссылке на тему.
S> Здесь вопрос, что проще раскрутить CIL или C#. Например с лямбдами по моему проще исходный код. Но я не спец в компиляторах. S>Плюс оптимизация при компиляции в СIL код, уменьшает затраты при JIT компиляции.
Это ж классический вопрос между если-бы и есть-сейчас. Сейчас — однозначно рослином проще. Потом... это не один год с неясным результатом. Сейчас отсутствие хороших оптимизаций — вынуждает делать их уровнем выше, без возможности опереться на оптимизацию которая бы эффективно снизила стоимость абстракций.
S>> Здесь вопрос, что проще раскрутить CIL или C#. Например с лямбдами по моему проще исходный код. Но я не спец в компиляторах. S>>Плюс оптимизация при компиляции в СIL код, уменьшает затраты при JIT компиляции. F> Это ж классический вопрос между если-бы и есть-сейчас. Сейчас — однозначно рослином проще. Потом... это не один год с неясным результатом. Сейчас отсутствие хороших оптимизаций — вынуждает делать их уровнем выше, без возможности опереться на оптимизацию которая бы эффективно снизила стоимость абстракций.
Ну насчет девиртуализации и инлайнинга то можно и на этапе компиляции в CIL делать. Зачем насиловать JIT?
Тем более в debug делать без оптимизаций, а один раз скомпилировать под Release это не проблема. JIT должен быстро компилировать.
Проблема то оптимизаций в том, что JIT должен работать быстро. Но никто не запрещает долго компилировать в CIL. Либо перекомпилировать сырой CIL в оптимизированный CIL
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну насчет девиртуализации и инлайнинга то можно и на этапе компиляции в CIL делать. Зачем насиловать JIT? S>Тем более в debug делать без оптимизаций, а один раз скомпилировать под Release это не проблема. JIT должен быстро компилировать. S>Проблема то оптимизаций в том, что JIT должен работать быстро. Но никто не запрещает долго компилировать в CIL. Либо перекомпилировать сырой CIL в оптимизированный CIL
Так... я не утверждал, что генерировать оптимизированный код — это не нужно. Я говорил, что, был бы хорошо оптимизирующий JIT — было бы видно где оно нужно, а где нет.
В этом же треде это и обсуждалось — есть набор даже довольно простых оптимизаций которые никогда не были воплощены в дотнете. Т.е. в этой подветке — это был sealed. Зачем в рантайме генерировать виртуальный вызов для sealed типа? При этом C# компилятор может делать это и сам, но безопасно — только в рамках сборки. А cross-assembly calls — это всё таки работа для JIT.
В этом же треде я приводил в пример кратко словами — тут расширю:
class A
{
int _x;
public virtual void Increment() { _x++; }
}
class Program
{
static void Main(string[] args)
{
Debugger.Launch(); // что-бы получить дизасмvar a = new A();
for (var i = 0; i < 100000; i++)
{
a.Increment();
}
}
}
и
--- h:\!temp\ConsoleApplication17\ConsoleApplication17\Program.cs --------------
21: Debugger.Launch();
00007FFAF0820482 48 83 EC 28 sub rsp,28h
00007FFAF0820486 E8 95 FE 28 3E call 00007FFB2EAB0320
22: var a = new A();
00007FFAF082048B 48 B9 70 5A 71 F0 FA 7F 00 00 mov rcx,7FFAF0715A70h
22: var a = new A();
00007FFAF0820495 E8 96 20 60 5F call 00007FFB4FE22530
00007FFAF082049A 48 8B F0 mov rsi,rax
23: for (var i = 0; i < 100000; i++)
00007FFAF082049D 33 FF xor edi,edi
24: {
25: a.Increment();
00007FFAF082049F 48 8B CE mov rcx,rsi
00007FFAF08204A2 48 8B 06 mov rax,qword ptr [rsi] ; виртуальный вызов в цикле
00007FFAF08204A5 48 8B 40 40 mov rax,qword ptr [rax+40h] ; 3 зависимые инструкции
00007FFAF08204A9 FF 50 20 call qword ptr [rax+20h] ;
23: for (var i = 0; i < 100000; i++)
00007FFAF08204AC FF C7 inc edi
00007FFAF08204AE 81 FF A0 86 01 00 cmp edi,186A0h
00007FFAF08204B4 7C E9 jl 00007FFAF082049F
00007FFAF08204B6 48 83 C4 28 add rsp,28h
00007FFAF08204BA 5E pop rsi
00007FFAF08204BB 5F pop rdi
00007FFAF08204BC C3 ret
Оптимизирующий компилятор вполне способен увидеть что "a" — неизменяется в цикле. Вычисление адреса подпрограммы (Increment) можно вынести за тело цикла. В худшем случаем — код может содержать что-то вроде
call qword ptr [rsp+_a_Increment_addr] ; a_Increment_addr - на стэке
— в лучшем —
call rdx ; если цикл игрушечный и регистр сохраняется
. Это же можно делать для любых косвенных вызовов (Action, Func<>).
C Action на вызывающей стороне кстати нормально — но вызов не просто косвенный, а очень косвенный.
Т.е. генерируется что-то вроде:
WPF?! Тьфу... WTF!?! o_O
Что-то я такого сам не ожидал... мож кто поправит, что тут не так. Пример брался банальный:
var a = new A();
var action = new Action(a.Increment);
action();
Debugger.Launch();
action(); // смотрел вызов тут
...
Короче JIT просто должен делать свою работу и делать её хорошо, там где это можно. И так же желательно, что бы он активно спекулировал теми вещами которые доступны исключительно ему (в отличие от классических AOT). При этом опять же — классическая profile-based code generation которая помогает развернуть код в более выгодное русло с точки зрения предсказания бранчей — это как раз вещи которые можно вынести за пределы JIT (ничего не мешает профиль встраивать/деплоить — а лучше переписывать IL с хинтами бранчевания). Или если без изменения формата — решить, что переходы которые не совершаются — предпочитаемые.
HotSpot в Яве же себя хорошо зарекомендовал — а оптимизаций он делает кучу, в том числе довольно тяжелые.
Кстати какой .Net использовал? Core кстати оптимизирован под .Net Native В чем разница между NetFramework и NetCore
F> Короче JIT просто должен делать свою работу и делать её хорошо, там где это можно. И так же желательно, что бы он активно спекулировал теми вещами которые доступны исключительно ему (в отличие от классических AOT). При этом опять же — классическая profile-based code generation которая помогает развернуть код в более выгодное русло с точки зрения предсказания бранчей — это как раз вещи которые можно вынести за пределы JIT (ничего не мешает профиль встраивать/деплоить — а лучше переписывать IL с хинтами бранчевания). Или если без изменения формата — решить, что переходы которые не совершаются — предпочитаемые. F> HotSpot в Яве же себя хорошо зарекомендовал — а оптимизаций он делает кучу, в том числе довольно тяжелые.
Ну в UWP есть еще и .Net Native. Может MS выгоднее её оптимизировать?
Подвижки есть. Посмотрим, что дальше
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Кстати какой .Net использовал? Core кстати оптимизирован под .Net Native
S>Слушайте, перестаньте отбивать хлеб у камрадов. Для постинга полного бреда у нас уже есть специально обученные люди
S>Если серьёзно — я бы подучил матчасть.
Ну дык я рад любой ссылочке. А насчет .Net Core
Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)
В чем бред? Тот же Core Clr значительно меньше жрет памяти.
и солнце б утром не вставало, когда бы не было меня
S>Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native.
... а в киеве дядька.
.net core — это набор из хоста (dnx + ко, он же dotnet cli) рантайма (coreclr + несколько pipelines для трансляции в бинарный код, как jit, так и AOT) и базовых библиотек (corefx).
.net native — комбинация из урезанного winrt runtime + пайплайн для AOT-трансляции поверх ms c++ backend. Набор базовых библиотек для него, внезапно, — не corefx а всё тот же winrt bcl, что принципиально тянется со времён восьмёрки. Точнее, с wp7, который в свою очередь немало утащил с silverlight, а тот кое-что позаимствовал от .net compact.
В общем, ты сравниваешь свежий форк дотнета с частью более древнего форка и заявляешь, что первый оптимизирован под второй. Как-то так.
S>Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры.
Снова бред полный, без обид. Поделитесь ссылочкой на первоисточник, аж интересно стало, кто у нас такой криптоисторик.
.net native — это доведённый до ума project N, который наследник т.н. compiler in the cloud, который в свою очередь наследник одного из проектов ms research, если ничего не забыл. Проект из времён wp7, когда .core в сегодняшнем понимании не было даже в зародыше. И да, проект от ms research взял за основу "урезанный" фреймворк не по каким-то маркетинговым причинам, всё проще: его было на порядок проще транслировать в натив за счёт сильно урезанных функций рантайма.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. S>... а в киеве дядька.
S>.net core — это набор из хоста (dnx + ко, он же dotnet cli) рантайма (coreclr + несколько pipelines для трансляции в бинарный код, как jit, так и AOT) и базовых библиотек (corefx).
S>.net native — комбинация из урезанного winrt runtime + пайплайн для AOT-трансляции поверх ms c++ backend. Набор базовых библиотек для него, внезапно, — не corefx а всё тот же winrt bcl, что принципиально тянется со времён восьмёрки. Точнее, с wp7, который в свою очередь немало утащил с silverlight, а тот кое-что позаимствовал от .net compact.
S>В общем, ты сравниваешь свежий форк дотнета с частью более древнего форка и заявляешь, что первый оптимизирован под второй. Как-то так.
Я говорю, о том, что сборки под .Net Core оптимизированы для .Net Native. А вот и мне интересно если разница в JIT компиляции CoreClr и обычного CLR. Вероятно есть но интересны факты.
S>>Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. S>Снова бред полный, без обид. Поделитесь ссылочкой на первоисточник, аж интересно стало, кто у нас такой криптоисторик.
Дэниэл Якобсон. Так я же давал. Ты не читаешь. Microsoft .NET Framework — Разработка с использованием .NET и Universal Windows Platform
S>.net native — это доведённый до ума project N, который наследник т.н. compiler in the cloud, который в свою очередь наследник одного из проектов ms research, если ничего не забыл. Проект из времён wp7, когда .core в сегодняшнем понимании не было даже в зародыше. И да, проект от ms research взял за основу "урезанный" фреймворк не по каким-то маркетинговым причинам, всё проще: его было на порядок проще транслировать в натив за счёт сильно урезанных функций рантайма.
Ну в итоге то они и стали развивать .Net Core плюс купили xamarin которые кстати тоже Net Native занимались.
Кстати
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности. Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.
Значит и JIT генерирует другой нативный код. Я просто попросил сравнить код для CoreClr.
Microsoft.NETCore.Runtime.CoreCLR — Represents the object allocator, garbage collector (GC), class loader, type system, interop and the most fundamental parts of the .NET class library (e.g. System.Object, System.String ...)
It also contains the source code for the following closely related support packages.
Microsoft.NETCore.Jit — The Just In Time (JIT) compiler for the .NET Intermediate language (IL)
Microsoft.NETCore.ILAsm — An assembler for the .NET Intermediate language (IL)
Microsoft.NETCore.ILDAsm — A disassembler (Pretty printer) for the .NET Intermediate language (IL)
Microsoft.NETCore.TestHost — This contains the corehost.exe program, which is a small wrapper that uses the .NET Runtime to run IL DLLs passed to it on the command line.
Microsoft.TargetingPack.Private.CoreCLR — A set of assemblies that represent the compile time surface area of the class library implemented by the runtime itself.
и солнце б утром не вставало, когда бы не было меня
S>>В общем, ты сравниваешь свежий форк дотнета с частью более древнего форка и заявляешь, что первый оптимизирован под второй. Как-то так.
S> Я говорю, о том, что сборки под .Net Core оптимизированы для .Net Native.
*терпеливо*
Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework?
S>А вот и мне интересно если разница в JIT компиляции CoreClr и обычного CLR. Вероятно есть но интересны факты.
*Ещё более терпеливо*
При чём тут full .net fw JIT? он в .net native не используется.
Серьёзно, давай всё-таки излагать мысли связно, и, главное, по теме
Полный .net fw не поддерживается .net native по двум простым причинам:
1. Технологии, на которых основан .net native чисто исторически затачивались под нужды мобильных приложений, в частности, под быстрый запуск.
2. Полный .net framework принципиально нельзя перенести под winrt, т.к. там недоступно множество нативных API на которых завязан код в BCL.
Всё остальное — это уже следствия.
S>>.net native — это доведённый до ума project N... S> Ну в итоге то они и стали развивать .Net Core плюс купили xamarin которые кстати тоже Net Native занимались.
*терпение кончилось*
... а в киеве дядька, как и было сказано.
В общем перстаньте путать два похожих, но не одинаковых форка .net fw.
Здравствуйте, Sinix, Вы писали:
S>Полный .net fw не поддерживается .net native по двум простым причинам: S>1. Технологии, на которых основан .net native чисто исторически затачивались под нужды мобильных приложений, в частности, под быстрый запуск. S>2. Полный .net framework принципиально нельзя перенести под winrt, т.к. там недоступно множество нативных API на которых завязан код в BCL. S>Всё остальное — это уже следствия.
Дай побуквоедничать!
0. Он в полном объеме там и не тарахтел... ну т.е. не нужен теоретически. Он и на десктопе ведь в полном объеме не очень нужен в основном. Но вот когда нужен и оно есть — это и есть плюсище.
А вот всё остальное — уже следствие.
Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды. Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.
PS: Я в уме держал мобилы. А в десктопе — мы раз и кастанули любой нативный артефакт и никто не помеха. И кстати, это, имхо,
Всем бы твой задор а потом ещё и в мирное русло. Цены бы вам не было б. Я серьезно. Я не думаю что у нас огромная разница в возрасте или что-то такое, более того — я последние годы — везде тыкаю дотнет в грязь, если могу это по делу. Но. Ты окрылён чем-то, — а я нет. Sinix — тоже нет. Вашему TS2 всё ещё нужен сторонний транспилер что-бы это работало в реальных браузерах. Потом выясниться что всё тот же TS2 делает что-то не так. Потом когда до кого-то дойдет что он способен язык ради фана — он сделает XS1 который будет компилироваться сразу в вебассембли что несмотря на мегабайты TS — видимо не дано. Я это к чему — я лучше буду из C++ эти самые web assembly генерить, новаторы эти малёха поднадоели. При том, противно, что самый говёный продукт подхватывается на ура. Angular1 + TS — отличные примеры. За ангуляром1 кроме персистентных утечек в "родном" хроме но не фф и ие — ничего не стояло. Ах, забыл. Гугл стоял. А за — TS "экс" сотрудник, да такое экс, что вдруг получил первоклассную поддержку языка в студии из коробки. Тьфу.
Более того — NIMH/NIH — это то чем должен пользоваться разработчик, но TS выстрелил так быстро, что в независимость я не верю.
С дотнетом и неткорой лучше. Много лучше.
Здравствуйте, fddima, Вы писали:
F> Ещё, что ты собственно и написал — я согласен на все сто. Более того, я попробовал неткору в 2017 и почти рарыдался сразу по мелочам. Всё ещё очень похоже на сторонний плагин от сторонней команды. Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. Хотя и катастрофы нет никакой. Просто имхо планка качества упала. Правда скорость реакции повысилась, а это нынче модно.
Sinix вот поставил мне... весьма высокую оценку за вполне флеймовый вброс. Отработаю.
Банально. Они решили,
<Compile Include="**/*.cs" />
что это правило хорошо подходит всем. Я категорический противник этого. Всё что должно компилироваться в проект — должно быть явно описано и включено. Особенно, когда мы таргетимся на как минимум 3 мажорных платформы и в реальной жизни мы имеем 3 файла на разные платформы. Они могут как угодно извращаться у себя — но зачем людей насиловать?! Я не понял.
Конечно же — страшный энтэрпрайз об этом позаботился.
разрешает эту проблему. Теперь мы должны указать через ItemGroup/Compile файлы которые компилировать. Почему это важно?
1. Так было всегда ДО того как их "индусы" осознали что есть шаблоны включения файлов.
2. Я практически генерирую .csproj проект, файлы в него. Я когда указываю файлы явно — могу не заботится о чистоте директорий. Согласитесь — это же естественно для любого итерационного билд скрипта. Оказался лишний файл в выходной директории? Ну и хер с ним — он просто не включён в проект и потому не компилируется.
3. Естественно студия совершенно не знает ничего о EnableDefaultCompileItems. Если оно запрещено оно всё равно не добавляет новосозданные файлы в проект. Простите, но мы более 10 лет 99% правок в csproj проводим как раз через студию и лишь некоторые включения делаем руками, которые студия давно не трогает. Есть отличнейше отлаженный механизм.
Я на фоне этого чувствую себя обманутым — слава богу что нет более project.json и настоящий msbuild работает! Ура! Ура! Ура! Но поддержка тех же самых проектов в студии — стала много хуже.
Add: По сути это означает коммиты "у меня всё работает", без изменения файла проектов. Upd: Ну т.е. — у меня оно собирается, но т.к. я файл не зачекинил — у всех оно отламывается. При этом все другие участники проекта даже не догадываются о том что какой-то файл просто не зачекинен — записей об этом в файле проекта нет.
Для людей которым достаточно **/*.cs — достаточно было и project.json. Но это бред, особенно учитывая насколько это тесно интегрировано в тулчейн.
Теперь вопрос на очереди у меня такой: можно ли работать с .net core в таком русле, что бы output директории вынести out-of-source-tree? Это более чем стандартный подход. Более того, я считаю его единственно вменяемым. То, что они ложат bin/obj прям рядом... какая разница куда ложить это тулчейну? Ему нужно знать только где искать и куда ложить. С копыт — получил только ошибки. Может и можно. Не знаю. Но, афаик — они это прошили везде где могли. Так или иначе — это ещё один, уже традиционный идиотизм. Можете спорить с этим, но 99% всех проектов которые мне встречались — либо не навязывают, либо out директория лежит вне src. Это банально удобно. С нормальным дотнетом для не вебовых проектов — это было возможно. Сейчас сходу (переопредив OutputPath — получаешь ошибки — часть пишет в OutputPath — часть нихера не находит). Извините — output директории — это личное дело проекта. Если "технология" настолько тупа — то... страшно даже предположить что они ещё наворотили там.
Как-то так.
PS: Все возможные оценки за это сообщение получено в предыдущем сообщении.
PPS: В общем если в итоге окажется, что изменить выходную директорию совсем никак нельзя — то, я скажу, что это не технология, а... "новогодняя ёлка" и это слово — буду использовать или до тех пор пока не пофиксят или до 2018. Вот согласитесь — как звучит хорошо-то — я придумал новую новогоднюю ёлку...
PPPS: Нет. Давайте не так. Вмето .Net Core — я всегда буду говорить "новогодняя ёлка". По моему должно быть довольно прикольно.
PPPPS: Не, ну, за язык цеплять не надо — конечно только до 2018. Конечно ради меня форматер портить не стоит, но на 1-ое апреля — например если рсдн форматтер так сделает — я не обижусь.
Здравствуйте, 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 не используется.
Мне интересно если разница между нативным кодом
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.
Или тебе опять слово оптимизировано не нравится
и солнце б утром не вставало, когда бы не было меня
Ещё и в msdn magasine. Самое смешное, что в том же абзаце есть ссылка на интервью
Я лично, да и энтэрпрайз с таким подходом думаю, как минимум до нетстандарт2.0 даже не начнет шевелится. Имхо. А кто и начнет — то подальше от. 
