Джит наконец-то научился девиртулизовывать вызов метода, а значит и инлайнить их. Текущий вариант назван simple devirtualization, работы в этом направлении еще много, но то что есть уже приятно радует Если раньше модификатор sealed class и sealed override ничего не говорили джиту, то теперь он их принимает в рассчет. Что может джит делать с виртуальными методами, а что нет, можно глянуть вот сюда: Devirtualization tests
Из примеров:
public static Base M()
{
return new Derived();
}
public static int Main()
{
// M should inline and expose an exact return type
// which will trigger late devirt for both Foo() and Bar().
M().Foo();
M().Bar();
}
// Jit should inline this method and then devirtualize ToString()static void Print(object o)
{
Console.WriteLine(o.ToString());
}
public static int Main()
{
Print("hello, world!");
return 100;
}
1. Устранение пустых finally блоков. Пустой finally получается, например, в случае использования using или foreach для классов с пустым Dispose методом. С учетом девиртуализации это будет работать и с классами, имеюшие пустой виртуальный Dispose.
Блок finally реализован как вызов метода, который теперь устраняется в случае пустых finally блоков.
static int Sum(List<int> x) {
int sum = 0;
foreach(int i in x) {
sum += i;
}
return sum;
}
Остальное побольшей части работает только для CoreCLR, в котором нет Thread.Abort, который мешает делать некоторые оптимизации, но не делает их невозможными, если получить поддержку со стороны рантайма. За подробностями прошу сюда: Finally Optimizations
Здравствуйте, VladD2, Вы писали:
VD>А в основной дотнет то это когда попадет?
Вот этого я не знаю, но Andy Ayers, автор этих изменений, в одном из сообщений на гитхабе выразил надежду, что в ближайший релиз, может с релизом студии Сейчас найти что-то не могу этого сообщения. Кто может знает как посмотреть все сообщения конкретного автора на гитхабе?
Здравствуйте, rameel, Вы писали:
R>Вот этого я не знаю, но Andy Ayers, автор этих изменений, в одном из сообщений на гитхабе выразил надежду, что в ближайший релиз, может с релизом студии Сейчас найти что-то не могу этого сообщения.
Вот что-то я сомневаюсь, что имелась в виду vs2017. С win 10 creators должен выйти 4.7 (раньше 4.6.3 звался) с минорными обновлениями. Вроде бы ничего кроме .net standard 1.6 не обещалось. Но я давно не следил, ждем, чего 7 марта расскажут.
Причём перетаскивать (вроде бы) будут только BCL, без рантайма. См вот этот топик, к примеру.
UPD Пролистал тикеты, в очередной раз вспомнил, почему временно забил на .net core:
The proposal here is to make .Net Core behavior consistent across OS platforms, which means in this area .Net Core and .Net Desktop will diverge.
Under this proposal, for all .Net Core platforms including Windows, exceptions that cross a managed-native or native-managed boundary will cause the runtime to terminate with an unhandled exception
Здравствуйте, Sinix, Вы писали: S>Не, серьёзно? S>Я так понял, тропа к граблям с гравировкой "совместимость" у команды .core не зарастёт никогда.
Я думаю в свете UWP, Xamarin и Asp.Net Core для них главное.
А вот не Core CLR будет постепенно умирать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinix, Вы писали:
S>Не, серьёзно? S>Я так понял, тропа к граблям с гравировкой "совместимость" у команды .core не зарастёт никогда.
В .net куча граблей держущихся на соплях совместимости. Нужно уже как-то это все вычищать. Так что команда CoreCLR — молодцы.
Здравствуйте, Gattaka, Вы писали:
G>В .net куча граблей держущихся на соплях совместимости. Нужно уже как-то это все вычищать. Так что команда CoreCLR — молодцы.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Gattaka, Вы писали:
G>>В .net куча граблей держущихся на соплях совместимости. Нужно уже как-то это все вычищать. Так что команда CoreCLR — молодцы.
S>С интересом: а конкретизировать?
S>>С интересом: а конкретизировать?
S>Например тот же Asp.Net MVC тянул для совместимости кучу анахронизмов. Asp.Net Core выкинули старье, за счет отсутствия совместимости и увеличили скорость в 10 раз
Ну, заявление-то было про грабли и про дотнет в целом. Вы б ещё workflow foundation как пример привели.
И раз зашла речь про веб... на одном из прежних мест работы после полутора лет наблюдения за метаниями с .net core два довольно крупных проекта начинают на ruby, а не на дотнете. По результам будет принято решение о судьбе остальных проектов. Я в детали особо не вдавался, как понял, на ближайшую пару лет риски оценили как неприемлемые.
Ещё один проект, хардкор-энтерпрайз, принципиально не будет переводиться на .core в обозримом будущем. Если пропустить нецензурные высказывания, то предложение самостоятельно найти замену wcf, аппдоменам/песочнице для недоверенного кода, настройкам, бинарной сериализации, ef, wmi, System.DirectoryServices и тыды не нашло горячего одобрения
То же самое наблюдается ещё как минимум у двух человек.
Потому что клиентам пофиг, насколько оно быстрее, их интересует стоимость разработки и совместимость с существующей инфраструктурой. По обоим пунктам у .net core политика поменялась относительно недавно. Сколько теперь времени пройдёт, пока намерения станут реальностью _и_ эта реальность дойдёт до заказчиков — науке теперь неизвестно. Пока впечатления невесёлые, диалог сводится к предложению продолжить смысловую цепочку: silverlight, wpf, lightswich...
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>С интересом: а конкретизировать?
S>>Например тот же Asp.Net MVC тянул для совместимости кучу анахронизмов. Asp.Net Core выкинули старье, за счет отсутствия совместимости и увеличили скорость в 10 раз
S>Ну, заявление-то было про грабли и про дотнет в целом. Вы б ещё workflow foundation как пример привели.
S>И раз зашла речь про веб... на одном из прежних мест работы после полутора лет наблюдения за метаниями с .net core два довольно крупных проекта начинают на ruby, а не на дотнете. По результам будет принято решение о судьбе остальных проектов. Я в детали особо не вдавался, как понял, на ближайшую пару лет риски оценили как неприемлемые.
S>Ещё один проект, хардкор-энтерпрайз, принципиально не будет переводиться на .core в обозримом будущем. Если пропустить нецензурные высказывания, то предложение самостоятельно найти замену wcf, аппдоменам/песочнице для недоверенного кода, настройкам, бинарной сериализации, ef, wmi, System.DirectoryServices и тыды не нашло горячего одобрения
S>То же самое наблюдается ещё как минимум у двух человек.
«Сорок процентов пользователей .NET Core — новые разработчики», — утверждает директор .NET-подразделения Microsoft Скотт Хантер. «Мы хотим привлекать новых людей».
Кстати в интервью с Акиншеным, он говорил про то, что огромный вклад в развитие Kestrel внес чувак не из MS, а из опен сорс сообщества.
S>Потому что клиентам пофиг, насколько оно быстрее, их интересует стоимость разработки и совместимость с существующей инфраструктурой. По обоим пунктам у .net core политика поменялась относительно недавно. Сколько теперь времени пройдёт, пока намерения станут реальностью _и_ эта реальность дойдёт до заказчиков — науке теперь неизвестно. Пока впечатления невесёлые, диалог сводится к предложению продолжить смысловую цепочку: silverlight, wpf, lightswich...
Да выкинули AppDomain, Remoting. Но если добавить для динамиков псевдоинтерфейсы, аналога аннотации типа в TypeScript d.ts, для статической проверки кода и IntelliSense, то это будет мало отличаться от WCF и Remoting
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но можно привести пример сколько пришло новых. Была статья на хабре, что около 40% использующих .Net Core пришло из других платформ языков.
Проблема не в количестве, а в качестве. Для энтерпрайза количество проектов-однодневок не значит ничего. Особенно если сравнить с возросшим риском остаться на неподдерживаемой платформе после полутора десятка лет инвестиций.
S> То, что я вижу это стремление MS перейти к магазину и UWP...
Ну замечательно. Только энтерпрайз, который так-то приносит MS больше половины доходов, все эти бла-бла-бла не интересуют. А вот разнообразные риски, связанные с переносом фокуса от старой инфраструктуры к новым бла-бла-бла интересуют очень даже.
S>Кстати скорость обмена порядка 14 000 вызовов в секунду.
И ещё раз замечательно. Я уверен, что эти цифры убедят заказчика вложиться в .net core. Не смотря на то, что он уже обжёгся на прошлых "у технологии был фатальный недостаток" от MS. Удачи.
S> Да выкинули AppDomain, Remoting.
AppDomain уже вкинули обратно. Но осадочек остался выводы уже сделаны и нужны очень серьёзные причины вкладываться в платформу, в которой половина функционала осталась только под нажимом существующих крупных клиентов.
UPD, пардон, уже выкинули, в итоге добавлено только API для текущего AppDomain.
Здравствуйте, Sinix, Вы писали:
S>UPD, пардон, уже выкинули, в итоге добавлено только API для текущего AppDomain.
Имхо, AppDomain и не нужен сильно: как средство изоляции — это всё равно меньше чем процесс ОС, а как средство динамической выгрузки сборок... как минимум неудобно.
Но конечно прежде чем тупо выпиливать чуть ли не фундаментальные концепции доступные с дотнета 1.0! и успешно разъехавшиеся по самым разным проектам — нехило бы и замену предложить, или опциональную поддержку. Пичалька.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Но можно привести пример сколько пришло новых. Была статья на хабре, что около 40% использующих .Net Core пришло из других платформ языков. S>Проблема не в количестве, а в качестве. Для энтерпрайза количество проектов-однодневок не значит ничего. Особенно если сравнить с возросшим риском остаться на неподдерживаемой платформе после полутора десятка лет инвестиций.
S>> То, что я вижу это стремление MS перейти к магазину и UWP... S>Ну замечательно. Только энтерпрайз, который так-то приносит MS больше половины доходов, все эти бла-бла-бла не интересуют. А вот разнообразные риски, связанные с переносом фокуса от старой инфраструктуры к новым бла-бла-бла интересуют очень даже.
Здравствуйте, Sinix, Вы писали:
S>Проблема не в количестве, а в качестве. Для энтерпрайза количество проектов-однодневок не значит ничего. Особенно если сравнить с возросшим риском остаться на неподдерживаемой платформе после полутора десятка лет инвестиций.
С таким подходом надо сидеть на обычном .net и не выделываться — там лет на ближайшие лет 10 — 20 поддержка никуда не денется.
S>Ну замечательно. Только энтерпрайз, который так-то приносит MS больше половины доходов, все эти бла-бла-бла не интересуют. А вот разнообразные риски, связанные с переносом фокуса от старой инфраструктуры к новым бла-бла-бла интересуют очень даже.
Видно MS посчитал, что в обозримой перспективе основные деньги будут в облаках и предоставлении т.п. сервисов. а там, у кого дешевле затраты на инфраструктуру тот и выиграл.
S>> Да выкинули AppDomain, Remoting. S>AppDomain уже вкинули обратно. Но осадочек остался выводы уже сделаны и нужны очень серьёзные причины вкладываться в платформу, в которой половина функционала осталась только под нажимом существующих крупных клиентов.
Надо понимать, что кроме windows есть еще целый мир в виде linux и т.п. И CoreCLR это отличная возможность соскочить с этого поезда не на полном ходу... такая возможность дорогого стоит
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, fddima, Вы писали:
F> Имхо, AppDomain и не нужен сильно: как средство изоляции — это всё равно меньше чем процесс ОС, а как средство динамической выгрузки сборок... как минимум неудобно.
С точки зрения разработчика — да.
С точки зрения менеджмента ситуация выглядит так:
есть платформа А, где есть функционал, критичный для приложения.
есть форк платформы A+, где используемого функционала нет, никаких комментариев по его отсутствию нет, никакой документации и рекомендации по замене нет, альтернативы (для аппдоменов — штатного IPC) — нет.
И так по целому ряду вопросов.
Это факт раз. Факт два — последние два года инвестиции от владельца платформы идут в платформу А+, по платформе А не было ни официальных анонсов, ни previrew новой версии.
Факт три — и он проверен из нескольких источников — спустя два года после анонса платформа А+ непригодна для использования в продакшне, для неё нет ни штатной документации, ни поддержки на официальных форумах производителя. Несмотря на крайне жёсткий дедлайн в release candidate платформы вносятся ломающие изменения, после которых ваши пробные проекты прекращают собираться.
И теперь, держа в уме этот расклад — что вы ответите на вопрос о платформе для нового проекта?
И контрольный вопрос — с какой аргументацией вы как разработчик сможете переубедить менеджмент?
Вот примерно в таком вот аксепте(с) рассматриваются все новые проекты под дотнет последний год. Так себе поднасрать на своей же поляне — это нечто гениальное.
Здравствуйте, Sinix, Вы писали:
S>И теперь, держа в уме этот расклад — что вы ответите на вопрос о платформе для нового проекта? S>И контрольный вопрос — с какой аргументацией вы как разработчик сможете переубедить менеджмент?
Ну а кто тут писал про Ruby? Сегодня ruby, завтра node и дальше по наклонной. а без core так бы и сидели под asp.net mvc...
S>Вот примерно в таком вот аксепте(с) рассматриваются все новые проекты под дотнет последний год. Так себе поднасрать на своей же поляне — это нечто гениальное.
Так, от создателей Windows Phone
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Intelligent Cloud
Our Intelligent Cloud segment consists of our public, private, and hybrid server products and cloud services that can power modern business. This segment primarily comprises:
* Server products and cloud services, including SQL Server, Windows Server, Visual Studio, System Center, and related CALs, as well as Azure.
* Enterprise Services, including Premier Support Services and Microsoft Consulting Services
и по сегментам
Revenue
Productivity and Business Processes
$26,487
Intelligent Cloud
$25,042
More Personal Computing
$40,460
Corporate and Other
$(6,669)
Operating income (loss) — ещё интересней.
S>Поровну с прочими энтерпрайз-сервисами.
Таки не совсем. Чудеса маркетинга спрятыны в вот этом абзаце
Revenue within the Intelligent Cloud segment alone increased $1.3 billion, or 6 percent, driven in part by impressive gains in our Azure business. Azure revenue and usage grew by more than 100 percent in the final quarter of the year
Как насчёт найти итоговый доход от azure (возьмём самый позитивный расклад: всё увеличение — чисто от azure) — сами справитесь?
Котрольный: сравнить его с общим $25,042 mln от Intelligent Cloud.
S> А там как раз .Net Core востребован.
Без обид, но вы пытаетесь спорить путём механического пересказа рекламных материалов, вообще не вникая в вопрос. Не надо так. По факту sdk для части сервисов azure или недоступен, или недавно появился. К примеру DocumentDB.Core в декабре зарелизился.
Здравствуйте, TK, Вы писали:
TK>С таким подходом надо сидеть на обычном .net и не выделываться — там лет на ближайшие лет 10 — 20 поддержка никуда не денется.
Для существующих проектов — да. Для новых крупных проектов с горизонтом планирования лет в пять всё обстоит заметно веселее. Особенно если принимать в расчёт намёки заказчиков про импортозамещение и отечественные аналоги (читай, локальные дистрибутивы lin и прочее честно портированное).
S>>А вот разнообразные риски, связанные с переносом фокуса от старой инфраструктуры к новым бла-бла-бла интересуют очень даже. TK>Видно MS посчитал, что в обозримой перспективе основные деньги будут в облаках и предоставлении т.п. сервисов. а там, у кого дешевле затраты на инфраструктуру тот и выиграл.
И по этой причине _существующим_ кастомерам не облегчён переход, а предоставлена уникальная возможность свалить в облако конкурентов — всё равно совместимость поломана. Гениальная стратегия, таки да.
TK>Надо понимать, что кроме windows есть еще целый мир в виде linux и т.п. И CoreCLR это отличная возможность соскочить с этого поезда не на полном ходу... такая возможность дорогого стоит
Ну вот сейчас всё выглядит так, что раз уж соскочили — смысл связываться с полуcырым .core?
* тут надо сказать, что процесс принятия решений _очень_ инерционен. Сейчас при обсуждениях в ход идут аргументы, которые были актуальны для .net core полугодовой-годовой давности. Т.е. ещё как минимум год .net core в качестве серьёзного варианта рассматриваться никем не будет.
Здравствуйте, Sinix, Вы писали:
TK>>С таким подходом надо сидеть на обычном .net и не выделываться — там лет на ближайшие лет 10 — 20 поддержка никуда не денется. S>Для существующих проектов — да. Для новых крупных проектов с горизонтом планирования лет в пять всё обстоит заметно веселее. Особенно если принимать в расчёт намёки заказчиков про импортозамещение и отечественные аналоги (читай, локальные дистрибутивы lin и прочее честно портированное).
Думаю, что core под linux в этом плане вполне прокатит. если не рассматривать его как развитие существующих технологий то, как новый проект с "нуля" он вполне ничего
S>И по этой причине _существующим_ кастомерам не облегчён переход, а предоставлена уникальная возможность свалить в облако конкурентов — всё равно совместимость поломана. Гениальная стратегия, таки да.
Существующие кастомеры могут спокойно продолжать пилить старые проекты на обычном .net и в спокойной обстановке присматриваться к core который "такой же но, другой". Зачем сразу то все табором мигрировать?
TK>>Надо понимать, что кроме windows есть еще целый мир в виде linux и т.п. И CoreCLR это отличная возможность соскочить с этого поезда не на полном ходу... такая возможность дорогого стоит
S>Ну вот сейчас всё выглядит так, что раз уж соскочили — смысл связываться с полуcырым .core?
Так, для этого вначале соскочить и надо — набрать экспертизу, людей и т.п
S>* тут надо сказать, что процесс принятия решений _очень_ инерционен. Сейчас при обсуждениях в ход идут аргументы, которые были актуальны для .net core полугодовой-годовой давности. Т.е. ещё как минимум год .net core в качестве серьёзного варианта рассматриваться никем не будет.
Ну а куда с подводной лодки денешься?
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Думаю, что core под linux в этом плане вполне прокатит. если не рассматривать его как развитие существующих технологий то, как новый проект с "нуля" он вполне ничего
Если рассматривать его как новый проект, то .net core — не самый лучший выбор. Официальный тулинг будет только зарелизен (и то, он мягко говоря не блещет), специалистов нет, а те что есть "испорчены" win и окружение linux как воспринимают как забавное недоразумение. Community тож нет, т.е. и риски больше, и платить побольше придётся.
TK>Существующие кастомеры могут спокойно продолжать пилить старые проекты на обычном .net и в спокойной обстановке присматриваться к core который "такой же но, другой". Зачем сразу то все табором мигрировать?
А тут дело не в всё сразу, дело в инерции. Если раньше практически никаких вопросов "что используем?" не было, то в последнее время даже старые заказчики всерьёз готовы рассматривать несколько вариантов. Т.е. поворотный момент (+10 к пафосу, ага. Фиг его знает, как перефразировать) уже пройден, остаётся только наблюдать, в какую сторону оно дальше пойдёт.
Здравствуйте, TK, Вы писали:
TK>Существующие кастомеры могут спокойно продолжать пилить старые проекты на обычном .net и в спокойной обстановке присматриваться к core который "такой же но, другой". Зачем сразу то все табором мигрировать?
«Присматриваться к Core», я так понимаю, означает просто пытаться собрать уже существующие свои библиотеки под Netstandard. Например, есть у тебя несколько библиотек и к ним WPF- или ASP.NET-морда на «полном дотнете». Пытаешься перетаргетить библиотеки на Netstandard, смотришь какие получилось, какие требуют допиливания, оправданы ли усилия на миграцию. При этом всю дорогу целевой продукт остаётся всё так же на «полном дотнете» без ломающих изменений; просто максимально его куски переводишь под Netstandard, делая тем самым их Core-совместимыми. Netstandard поддерживается и «полным дотнетом», и «core-дотнетом».
Пусть будет так. Но вектор развития очевиден.
S>> А там как раз .Net Core востребован. S>Без обид, но вы пытаетесь спорить путём механического пересказа рекламных материалов, вообще не вникая в вопрос. Не надо так. По факту sdk для части сервисов azure или недоступен, или недавно появился. К примеру DocumentDB.Core в декабре зарелизился.
A ASP.Net Core не доступен на Azure
Ну дык и самой то .Net Core всего 8 месяцев от релиза. Опять же UWP, Xamarin и Asp.Net Core однозначно говорят о развтии всего в сторону .Net Core, и Windows 10.
Другое дело, что они хотят избавиться от Windows 7 и прочих анахронизмов. При этом так или иначе Win 10 вытеснит семерку в ближайшие годы. Но сейчас выгоднее делать приложения и по 7 ку и под 10 ку, а вот MS, выгоднее UWP.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, TK, Вы писали:
TK>А зачем обязательно аппдомены для IPC. многие используют пайпы/сокеты — изоляция процессов, если один упадет не потянет за собой другой...
А в .net core нет готового IPC. Только примитивы. Ну, или web api — для настоящих ценителей.
Здравствуйте, Sinix, Вы писали:
TK>>А зачем обязательно аппдомены для IPC. многие используют пайпы/сокеты — изоляция процессов, если один упадет не потянет за собой другой... S>А в .net core нет готового IPC. Только примитивы. Ну, или web api — для настоящих ценителей.
А чем web api не нравится? pipe / unix socket и вперед. а использовать MarhalByRefObject не сказать, что путь в правильно направлении...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
S>>А в .net core нет готового IPC. Только примитивы. Ну, или web api — для настоящих ценителей. TK>А чем web api не нравится? pipe / unix socket и вперед.
Ну, т.е. с нуля переизобретать rpc. С exception propagation, callbacks etc. Я уж молчу о собственно поднятии хоста, мягком unloading, организации песочницы итыды.
Вот примерно после таких ответов заказчик вежливо отвечает "спасибо, мы вас поняли" и уходит к конкуренту.
Здравствуйте, fddima, Вы писали:
S>>UPD, пардон, уже выкинули, в итоге добавлено только API для текущего AppDomain. F> Имхо, AppDomain и не нужен сильно: как средство изоляции — это всё равно меньше чем процесс ОС, а как средство динамической выгрузки сборок... как минимум неудобно.
Основная цель его существования — поддержка Code Access Security. А CAS оказался очень сложным и сдох. Так что и от аппдоменов полезными остались только побочные моменты.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
S>Ну, т.е. с нуля переизобретать rpc. С exception propagation, callbacks etc. Я уж молчу о собственно поднятии хоста, мягком unloading, организации песочницы итыды.
S>Вот примерно после таких ответов заказчик вежливо отвечает "спасибо, мы вас поняли" и уходит к конкуренту.
Держать в своем процессе песочницу для разного недоверенного кода достаточно стременное решение. многие даже контейнеры для этого не используют — только виртуалки и желательно где-то в отдельной сети...
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Здравствуйте, TK, Вы писали:
TK>Держать в своем процессе песочницу для разного недоверенного кода достаточно стременное решение.
Это зависит от сценария использования. Для относительно простых вещей подходит мотель аля sql clr host: низкие накладные расходы, защита от примитивных атак через верификацию il при развёртывании, возможность выгрузить аппдомен и приемлемая живучесть — более чем ок. Для случаев посложнее всю эту радость выносят в отдельный процесс, запихнутый в low integrity sandbox. Наличие аппдоменов позволяет и не плодить процесс для каждой мелкой финтифлюшки и изолировать их друг от друга. Какие альтернативы-то?
Вся теория по этому делу была преотличнейше документировано примерно во времена второго фреймворка. А потом рулить дизайном фреймворка стали люди, которые явно эту документацию не читали
Здравствуйте, Gattaka, Вы писали:
G>Я так пониаю что здесь назвается simple devirutalization основной дотнет уже умеет. Иначе зачем я везде seald расстовляю?
Этого никто не знает. Наверно задел на будущее. На сегодня это ничего не дает.
G>Или я чего-то не знаю?
Видимо многого.
В области оптимизации кода Дотнет очень сильно отстал не только от лучших компиляторов С++, но и от большинства Ява-машин. Они на сегодня умудряются работать быстрее не смотря на море архитектурных проблем в самой Яве.
Было бы очень здорово, если бы Майкрософт такие вложил немного бабла в оптимизации дотнета.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gattaka, Вы писали:
G>>Я так пониаю что здесь назвается simple devirutalization основной дотнет уже умеет. Иначе зачем я везде seald расстовляю?
VD>Этого никто не знает. Наверно задел на будущее. На сегодня это ничего не дает.
Да ладно! Рихтер ведь писал в своей книге. Ничеси...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Gattaka, Вы писали:
G>>Да ладно! Рихтер ведь писал в своей книге. Ничеси...
VD>А что он там такого писал?
Я имею ввиду раздел в главе 6 "Вызов виртуальных методов, свойств и событий в CLR". Где он рассказывает про IL инструкции call, callvirt.
Вот по мотивам:
Здравствуйте, Gattaka, Вы писали:
S>>С интересом: а конкретизировать? G>Автор даже придумал свой костыль и теперь всем его показывает с гордостью. "Посмотрите какой замечательный костыль я придумал".
Ужс-то какой. И это всё?
А теперь давайте немного в матчасть. Вызов Activator.CreateInstance() занимает ~100 нс. Внимание вопрос: с какой частотой надо вызывать Activator.CreateInstance(), чтобы его вызов оказывал влияние на производительность? Намёк: вопрос с подвохом.
Здравствуйте, Sinix, Вы писали:
S>А теперь давайте немного в матчасть. Вызов Activator.CreateInstance() занимает ~100 нс. Внимание вопрос: с какой частотой надо вызывать Activator.CreateInstance(), чтобы его вызов оказывал влияние на производительность? Намёк: вопрос с подвохом.
Это вы все Теплякову пишите
Если вам нужно ужаса так это OutOfMemory. Никогда не знаешь когда ее словишь и что ты при этом будешь делать тоже не понятно. Совсем недавно пытался сделать xslt преобарзование xml файла в 2 ГБ. Так и не получилось ничего. Saxon написанный на Java, что как некотоыре думают жрет память, справился с полпинка.
Здравствуйте, Gattaka, Вы писали:
S>>Внимание вопрос: с какой частотой надо вызывать Activator.CreateInstance(), чтобы его вызов оказывал влияние на производительность? Намёк: вопрос с подвохом. G>Это вы все Теплякову пишите
Не вопрос: товарищ SergeyT! Пожалуйста, прекратите безобразничать, перескакивать с темы на тему и писать от имени Gattaka вот такие вот вещи без пруфов:
В .net куча граблей держущихся на соплях совместимости
Пойдёт?
Вопрос всё ещё в силе, если что. Могу картинкой:
Скрытый текст
G>Если вам нужно ужаса так это OutOfMemory. Никогда не знаешь когда ее словишь и что ты при этом будешь делать тоже не понятно.
Пардон, но "я не в курсе про MemoryFailPoint" и "Никогда не знаешь когда ее словишь" — несколько разные вещи
G>Совсем недавно пытался сделать xslt преобарзование xml файла в 2 ГБ. Так и не получилось ничего.
Если интересует первопричина, то можно посмотреть набор типовых граблей вот тут: http://stackoverflow.com/questions/3777217/c-sharp-xslt-transformation-out-of-memory
Здравствуйте, Sinix, Вы писали:
G>>Если вам нужно ужаса так это OutOfMemory. Никогда не знаешь когда ее словишь и что ты при этом будешь делать тоже не понятно. S>Пардон, но "я не в курсе про MemoryFailPoint" и "Никогда не знаешь когда ее словишь" — несколько разные вещи
Знание того факта, что я не могу выделить память мне как мертвому припарка.
G>>Совсем недавно пытался сделать xslt преобарзование xml файла в 2 ГБ. Так и не получилось ничего. S>Если интересует первопричина, то можно посмотреть набор типовых граблей вот тут: S>http://stackoverflow.com/questions/3777217/c-sharp-xslt-transformation-out-of-memory
Есть такая книжка Stackoverflow driven development, так вот я её как и вы тоже читал. Переписать xslt можно если он простой. Если он сложный — это сложно. Так что не собираюсь я ничего переписывать только ради того чтобы замазать косяки дотнета. Я просто возьму джаву и все. Это проще и правильнее.
S>и проверить на "утёкшие" сборки, как рекомендуется здесь: S>https://blogs.msdn.microsoft.com/tess/2010/05/05/net-memory-leak-xslcompiledtransform-and-leaked-dynamic-assemblies/ S>Ну, и конечно убедиться, что не пытаетесь работать с XmlDocument в памяти, аля тынц.
Палево, ой палево... Sinix зачем мне приводить ссылки если ты и сам их все знаешь?
Здравствуйте, Sinix, Вы писали:
S>А, вам таки посраться, а не решить проблему? Ну, удачи. Вопрос выше снимаю за очевидной бессмысленностью.
Ну у меня после вашей картинки такая я же мысль возникла.
Здравствуйте, Gattaka, Вы писали:
S>>А, вам таки посраться, а не решить проблему? Ну, удачи. Вопрос выше снимаю за очевидной бессмысленностью. G>Ну у меня после вашей картинки такая я же мысль возникла.
Оппс, переборщил с сарказмом
Мои извинения.
По ссылкам для xlst — накосячил. Слона в "xml файл в 2 ГБ" не заметил
Чой-то я сомневаюсь, что дотнетовский XmlTransform тут справится, емнип он не умеет в streamed XSLT. Можно поискать сторонние, но скорее всего это будет тот же Saxon, только под дотнет.
Здравствуйте, Gattaka, Вы писали:
G>Я имею ввиду раздел в главе 6 "Вызов виртуальных методов, свойств и событий в CLR". Где он рассказывает про IL инструкции call, callvirt. G>Вот по мотивам: G>
До текущего момента джит не делал никаких спекуляции на этот счет. Все что так или иначе было связано с оптимизациями виртуальных вызовов, так это игра на уровне IL.
Здравствуйте, rameel, Вы писали:
R>Здравствуйте, Gattaka, Вы писали:
G>>Я имею ввиду раздел в главе 6 "Вызов виртуальных методов, свойств и событий в CLR". Где он рассказывает про IL инструкции call, callvirt. G>>Вот по мотивам: G>>
R>До текущего момента джит не делал никаких спекуляции на этот счет. Все что так или иначе было связано с оптимизациями виртуальных вызовов, так это игра на уровне IL.
Я, честно говоря, не очень понимаю, что там JIT еще может сделать. Но поверю на слово.
Здравствуйте, Sinix, Вы писали:
S>Оппс, переборщил с сарказмом S>Мои извинения.
Да ладно! В полемическом запале чего только не случается Я сам такой, так что никаких обид это уж точно, но и вы на меня не обижайтесь если что.
S>По ссылкам для xlst — накосячил. Слона в "xml файл в 2 ГБ" не заметил S>Чой-то я сомневаюсь, что дотнетовский XmlTransform тут справится, емнип он не умеет в streamed XSLT. Можно поискать сторонние, но скорее всего это будет тот же Saxon, только под дотнет.
А вот нет такого, я искал. Есть msxml, что я скачал с сайта MS, но он тоже не справился. Вобще проблема OutOfMemory то и дело всплывает и не только при работе с XML. На нашем проекте иногда стреляет как правило это большие объемы данных. И не всегда понятно как переписывать.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, TK, Вы писали:
S>>>А в .net core нет готового IPC. Только примитивы. Ну, или web api — для настоящих ценителей. TK>>А чем web api не нравится? pipe / unix socket и вперед.
S>Ну, т.е. с нуля переизобретать rpc. С exception propagation, callbacks etc. Я уж молчу о собственно поднятии хоста, мягком unloading, организации песочницы итыды.
S>Вот примерно после таких ответов заказчик вежливо отвечает "спасибо, мы вас поняли" и уходит к конкуренту.
Есть поддержка асинхронных методов, есть и поднятия хоста через запуск процесса и его выгрузка.
Песочницу можно организовать через терминальные сессии под определенными правами юзера.
и солнце б утром не вставало, когда бы не было меня
Включить в инфраструктуру проект с кодом, написанном на непонятном половине разработчиков языке, без коммитов/issues, без community и без шансов на поддержку?
Спасибо, мы вас поняли
То, что может выглядеть интересно с точки зрения программиста (серьёзно, вполне ок ), внезапно перестаёт таким быть как только нужно оценить потенциальные грабли для всего проекта от завязки на стороннюю библиотеку, вот в чём беда.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Вот примерно после таких ответов заказчик вежливо отвечает "спасибо, мы вас поняли" и уходит к конкуренту. S>> Его изобретать то особо нечего .Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
S>Включить в инфраструктуру проект с кодом, написанном на непонятном половине разработчиков языке, без коммитов/issues, без community и без шансов на поддержку? S>Спасибо, мы вас поняли
Ну я написал решение. Его несложно довести до ума. Если это интересно то можно добить до промышленного уровня. Вопрос это нужно или нет?
S>То, что может выглядеть интересно с точки зрения программиста (серьёзно, вполне ок ), внезапно перестаёт таким быть как только нужно оценить потенциальные грабли для всего проекта от завязки на стороннюю библиотеку, вот в чём беда.
Ну дык, то, что сделал я, не сложно сделать и MS/ Я никто и звать меня никак, но если это сделает MS все будут пользоваться.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Ну я написал решение. Его несложно довести до ума. Если это интересно то можно добить до промышленного уровня. Вопрос это нужно или нет?
С точки зрения менеджмента (а мы сейчас именно этот момент обсуждаем) — нет, заменить одни непонятные до конца риски другими непонятными до конца рисками за решение проблемы не катит
S> Ну дык, то, что сделал я, не сложно сделать и MS/ Я никто и звать меня никак, но если это сделает MS все будут пользоваться.
Ну примерно так, да. Проблема не в отсутствии _теоретической_ возможности, проблема в представлении менеджмента о фактическом положении дел.
И в крайне своебразной политике MS в отношении "как энтерпрайзу жмть с .net core".
Здравствуйте, Sinix, Вы писали:
S>> Ну дык, то, что сделал я, не сложно сделать и MS/ Я никто и звать меня никак, но если это сделает MS все будут пользоваться. S>Ну примерно так, да. Проблема не в отсутствии _теоретической_ возможности, проблема в представлении менеджмента о фактическом положении дел. S>И в крайне своебразной политике MS в отношении "как энтерпрайзу жмть с .net core".
Ну здесь проблема в том, для того, что бы двигаться дальше нужно переходить на .Net Core. C выходом NetStandard 2 возможности будут приблизительно одинаковы, за некоторыми исключениями вроде AppDomain и прочих наворотов. Другое дело, что MS не хочет развивать WPF, а развивает UWP, новые шаблоны и компоненты для работы с Angular 2 выходят только для Asp.Net Core.
Здесь переждать годик и смотреть за развитием .Net Core. При этом они для совместимости NetStandard 2 выбрали .Net 4.6.1
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rameel, Вы писали:
R>А что там верить, берешь да проверяешь) Вот для твоего примера со стековерфлоу для sealed class / sealed override R>
Ну ассемблер я не особо знаю. Из того что вижу — раскидали 3 раза какие-то значения по регистрам процессора и вызвали функцию.
Просто не очень понятно — до JIT доходит какой-то IL, ну и как он сможет что-либо оптимизировать, если JIT приходит постоянно одинаковый.
Т.е. тут оптимизации если какие-то и можно сделать, так это только при генерации этого самого IL.
Здравствуйте, Gattaka, Вы писали:
G>Ну ассемблер я не особо знаю. Из того что вижу — раскидали 3 раза какие-то значения по регистрам процессора и вызвали функцию. G>Просто не очень понятно — до JIT доходит какой-то IL, ну и как он сможет что-либо оптимизировать, если JIT приходит постоянно одинаковый. G>Т.е. тут оптимизации если какие-то и можно сделать, так это только при генерации этого самого IL.
Не вдаваясь в детали конкретной кодогенерации, лень смотреть на исходный пример да и вообще "на пальцах":
00007FFE0AF71B3E mov rax,qword ptr [rax+40h] // (1) получили адрес vtable
00007FFE0AF71B42 call qword ptr [rax+20h] // (2) вызвали метод по адресу который лежит в vtable
Т.е. имеем как минимум 2 уровня косвенности (вычитываем адрес vtable из памяти, вызываем процедуру по адресу который лежит в памяти). ADD: Вдобавок несложно заметить, что две эти инструкции зависимы. Процессор тут спекулировать просто не может (в то время когда независимые инструкции — он может исполнять одновременно).
Для вызова метода DoSmth никакие виртуальные таблицы ненужны и ассемблер должен быть приблизительно таким:
00007FFE0AF71B3E call <адрес>
Или как вариант (тупой с точки зрения быстродействия): одинарная косвенность остаётся, если по этому адресу лежит thunk/trampoline
который инициирует JIT-кодогенерацию этого самого метода, после чего все таблицы методов патчаться что-бы указывать уже на
сгенерированное тело метода.
При этом это элементарная оптимизация которая доступна для JIT не включая мозг. ADD: Более того — очевидно, разработчики компилятора C# на это и расчитывали, поэтому всегда не стеснялись эмиттить callvirt, даже там, где они могли бы генерировать call.
Есть ещё какие-то случаи где это можно делать просто.
А вот, обычно для profile-based компиляторов как AOT так и JIT-ов (скажем HotSpot очевидно тоже сюда можно включить) — практически можно сообразить больше оптимизаций, например:
Так вот — компилятору ничего не мешает создать столько специализаций метода, сколько это необходимо, т.е. DoSomething(sphere) и DoSomething(cube) — т.е. в ассемблере — могут зваться реально разные методы.
Конечно пример этот довольно глупый — тут не нужно профилирование, что бы началь плодить специализации.
Просто пытался объяснить, что когда речь идёт о девиртуализации виртуальных вызовов — обычно всё таки подразумевают такие случаи, где на уровне языка их исключить невозможно или почти невозможно.
Тут ещё надо вспомнить о том, что callvirt в IL используют т.к. он гарантированно проверяет this на null, а с обычным call — этого не происходит, и с ним вполне можно получить this == null. Здесь я правда не помню точно, если что — уточняйте.
Другой пример девиртуализации может быть ещё более изощренным (правда не уверен что это можно назвать девиртуализацией):
Для таких случаев опять же компилятор может обеспечить или дополнительные специализации методов (с конкретным action), либо специализацию с инлайнингом конкретного action, либо генерацию такого кода, который снизит косвенность при вызове action (ну т.е. получили конкретный адрес action за телом цикла, и вызываем метод через call ecx какой-нибудь — но это ещё нужно исхитриться такой код сгенерить, но очевидно что в худшем случае вместо двух-трёх косвенных обращений — можно сократить до одного — но это кстати к девиртуализации слабо касается).
Короче — вариантов масса. Но в дотнете пока что нет даже того варианта, где не нужно включать мозг. Но то, что они наконец-то двигаются в этом направлении — радует. Всё таки более 10 лет ждём.
ADD: Не стоит забывать, что распухание кода — тоже имеет свои недостатки — его меньше помещается в кеш процессора. Соответственно в каких-то случаях наличие дополнительных специализаций наоборот будет давать негативный эффект.
Здравствуйте, Gattaka, Вы писали:
G>Ну ассемблер я не особо знаю. Из того что вижу — раскидали 3 раза какие-то значения по регистрам процессора и вызвали функцию.
Ну, для этого надо гуглить на тему, что такое таблица виртуальных методов и как устроен объект в .NET изнутри. Вот в вики Таблица виртуальных методов.
mov rcx, rsi ; по соглашению, this передается через регистр rcx
mov rax, qword ptr [rsi] ; получаем адрес таблицы методов
mov rax, qword ptr [rax+40h] ; теперь адрес списка методов. Смещение в 64 байта для x64 и 40 для x86
call qword ptr [rax+20h] ; вызов нужного метода
Грубо говоря, сначала получаем адрес таблицы методов, далее по фиксированному смещению грузим список методов, потом производим вызов метода. Это для .NET 4 и выше, для более ранних было чуть иначе, но не суть. Если интересно ищем по Memory Layout в .net и как было, и что изменилось в 4.0. Например, вот статья от Саши Гольдштейна Virtual Method Dispatch and Object Layout Changes in CLR 4.0
G>Просто не очень понятно — до JIT доходит какой-то IL, ну и как он сможет что-либо оптимизировать, если JIT приходит постоянно одинаковый.
Сделать можно многое чего, если знать с каким типом ты работаешь.
G>Т.е. тут оптимизации если какие-то и можно сделать, так это только при генерации этого самого IL.
Не только, смотри выше и стартовое сообщение, плюс ссылки, которые я там дал.
Здравствуйте, Gattaka, Вы писали:
G>Я так пониаю что здесь назвается simple devirutalization основной дотнет уже умеет. Иначе зачем я везде sealed расставляю? G>Или я чего-то не знаю?
А расставляешь ты везде sealed правильно — только классы предназначенные для наследования должны его (наследование) позволять. А то как это сказывается на возможности оптимизаций — это уже вторично.
PS: В C# это немного уныло (всегда нужно писать этот sealed), но я для себя решил это просто — шаблон нового класса сразу содержит internal sealed. С другой стороны иоё внутренне чувство прекрасного требует наличие везде модификаторов доступа, соответственно — вклад sealed в синтаксический оверхед
Здравствуйте, 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.
Или тебе опять слово оптимизировано не нравится
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F> Всем бы твой задор а потом ещё и в мирное русло. Цены бы вам не было б. Я серьезно. Я не думаю что у нас огромная разница в возрасте или что-то такое, более того — я последние годы — везде тыкаю дотнет в грязь, если могу это по делу. Но. Ты окрылён чем-то, — а я нет. Sinix — тоже нет. Вашему TS2 всё ещё нужен сторонний транспилер что-бы это работало в реальных браузерах. Потом выясниться что всё тот же TS2 делает что-то не так. Потом когда до кого-то дойдет что он способен язык ради фана — он сделает XS1 который будет компилироваться сразу в вебассембли что несмотря на мегабайты TS — видимо не дано. Я это к чему — я лучше буду из C++ эти самые web assembly генерить, новаторы эти малёха поднадоели. При том, противно, что самый говёный продукт подхватывается на ура. Angular1 + TS — отличные примеры. За ангуляром1 кроме персистентных утечек в "родном" хроме но не фф и ие — ничего не стояло. Ах, забыл. Гугл стоял. А за — TS "экс" сотрудник, да такое экс, что вдруг получил первоклассную поддержку языка в студии из коробки. Тьфу. F> Более того — NIMH/NIH — это то чем должен пользоваться разработчик, но TS выстрелил так быстро, что в независимость я не верю. F> С дотнетом и неткорой лучше. Много лучше.
Предложи это мирное русло. Мне 53 годика. Кстати ищу работу.
Что касается web assembly то это аналог asm.js. Ты
выиграешь только в скорости выполнения на примитивных типов. JS объекты web assembly, компоненты ты на нем писать не сможешь.
Ну это аналог asm.js. То есть код на C++ компилируется в Wasm который дергается из JS
WebAssembly призвана дополнить и работать вместе с JavaScript — с помощью API-интерфейсов WebAssembly JavaScript, вы можете загрузить модули WebAssembly в приложение JavaScript и обмениваться функциональность между ними. Это позволяет воспользоваться преимуществами производительности и мощности WebAssembly и выразительность и гибкость в JavaScript в тех же программах, даже если вы не знаете, как писать код WebAssembly.
Сборка из C / C ++ для WebAssembly (ТБД) Когда вы написали модуль кода на языке , как C / C ++, вы можете скомпилировать его в .wasm с помощью инструмента Emscripten . Давайте посмотрим, как это работает.
Что касается TS то он лучше JS компилируется при изменении итд. Все можешь настроить в tsConfig, WebPack. И в Edge и Хроме ты отлаживаешь именно TS, а не JS.
Что касается Angular 2, то вполне себе нормальеый фремворк поле Jqury UI и прочих. Мне как 1с/C# программисту далекому от Web программирования очень понятны.
Был вчера под впечатлением, так что в целом — забей.
S> Предложи это мирное русло. Мне 53 годика.
Тут осечка вышла. Но... тогда вдвойне уважуха. Когда я ходил в офисы на работу — люди твоего возраста с трудом числа складывали.
S> Кстати ищу работу.
Тут ничем не могу помочь, увы.
S> Что касается web assembly то это аналог asm.js. Ты S> выиграешь только в скорости выполнения на примитивных типов. JS объекты web assembly, компоненты ты на нем писать не сможешь. S>http://rsdn.org/forum/flame.comp/6693034.1
люди пишут что из webasm не будет доступа к DOM.
S>
S>WebAssembly призвана дополнить и работать вместе с JavaScript — с помощью API-интерфейсов WebAssembly JavaScript, вы можете загрузить модули WebAssembly в приложение JavaScript и обмениваться функциональность между ними. Это позволяет воспользоваться преимуществами производительности и мощности WebAssembly и выразительность и гибкость в JavaScript в тех же программах, даже если вы не знаете, как писать код WebAssembly.
Это же, но простыми словами — мы добавили webasm, но JavaScript мы убирать не будем, т.к. потерять совместимость — это значит выкинуть браузер на мусорку. С помощью webasm вы сможете делать тоже самое что и на JS (обмениваться функциональностью между модулями).
S>
S>Сборка из C / C ++ для WebAssembly (ТБД) Когда вы написали модуль кода на языке , как C / C ++, вы можете скомпилировать его в .wasm с помощью инструмента Emscripten . Давайте посмотрим, как это работает.
S>https://developer.mozilla.org/en-US/docs/WebAssembly S> От JS ты не избавишься.
Тогда мы возвращаемся опять к началу — нафига оно тогда? Ну т.е. почему нельзя было сделать так, что бы от JS можно было избавиться?
S> Что касается TS то он лучше JS компилируется при изменении итд. Все можешь настроить в tsConfig, WebPack. И в Edge и Хроме ты отлаживаешь именно TS, а не JS.
То, что TS лучше JS — я и не спорю. Но по факту — от остальных его выгодно отличает только разкрученность. Опять таки — да, это хорошо, что появился инструмент который быстро развивается и имеет первоклассную поддержку. Но и ты пойми — google-closure-compiler умел при своей source-to-source компиляции: a) inlining b) dead code elimination. Поэтому какой-нибудь google-closure или даже маргинальный haxe на порядок мощнее как инструменты, позволяющий использовать несколько мегабайтные библиотеки и не затаскивать весь код библиотек в браузер (что всё ещё критично для скорости загрузки).
Насчет отладки я не понял. sourcemaps работают для любых языков, с TS это никак не связано. Это же свойство дебаггера, а не языка.
S> Что касается Angular 2, то вполне себе нормальеый фремворк поле Jqury UI и прочих. Мне как 1с/C# программисту далекому от Web программирования очень понятны. S> Что касается размеров, то пример в https://yadi.sk/d/0If7C5jZ3CEhmf жмутся webpack менее 5 mb S> Кстати Angular 1 и 2 это несколько разные вещи
Разные. Полность. Тем не менее — репутацию они у заработали именно на angular 1. Моя инертность мышления отвергает их изделие просто потому что angular 1 в моё время добавил исключительно только проблемы. Кстати, приблизительно о такой инертности говорит и Sinix со своим великим и ужасным энтерпрайзом.
В любом случае — дружба мир жвачка.
Я в любом случае рад, что инструменты развиваются. Как только мне попадёт в руки веб-проект — обязательно рассмотрю возможность связки TS2+A2. До того я активно использовал TS1 в некоторых местах — но не без проблемно. Куча подводных камней с той же студией и т.п.
Здравствуйте, fddima, Вы писали:
F> Опять таки — да, это хорошо, что появился инструмент который быстро развивается и имеет первоклассную поддержку. Но и ты пойми — google-closure-compiler умел при своей source-to-source компиляции: a) inlining b) dead code elimination. Поэтому какой-нибудь google-closure или даже маргинальный haxe на порядок мощнее как инструменты
И поэтому же они пока пролетают со свистом — технологии слишком пока завязаны на JS и слишком далекий от него уход приводит к сложностям.
TS практичен в том числе и тем, что очень недалеко отходит от JS, сохраняя с ним почти полную обратную совместимость и весьма прозрачную транслируемость.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>И поэтому же они пока пролетают со свистом — технологии слишком пока завязаны на JS и слишком далекий от него уход приводит к сложностям. AVK>TS практичен в том числе и тем, что очень недалеко отходит от JS, сохраняя с ним почти полную обратную совместимость и весьма прозрачную транслируемость.
Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Здравствуйте, fddima, Вы писали:
F> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Тем не менее практика показала, что TS однозначно самый популярный JS транспилер в истории. Еще хоть сколько нибудь заметная популярность была у CoffeeScript, который, что характерно "The golden rule of CoffeeScript is: “It’s just JavaScript”.". А вот перечисленные тобой языки остались на маргинальной обочине.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
F> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Кодогенерация это про шаблоны?
На самом деле у них есть кодогенерация для async await
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
F>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. AVK>Тем не менее практика показала, что TS однозначно самый популярный JS транспилер в истории. Еще хоть сколько нибудь заметная популярность была у CoffeeScript, который, что характерно "The golden rule of CoffeeScript is: “It’s just JavaScript”.". А вот перечисленные тобой языки остались на маргинальной обочине.
Да, но closure-compiler и closure-libary — основа для широко используемых приложений от гугла. В своё время — первопроходцев из области "самых используемых браузерных приложений в истории". Проблема в том, что closure-compiler — не имеет своего внятного языка, а использует размеченный JS комментариями и доступ к свойствам объектам странный (a.b и a["b"] — для него разные вещи). Разумеется такой подход не мог и не может хорошо работать — порождает кучу ошибок на ровном месте.
haxe — я привёл только как пример подобного компилятора, но в котором уже есть и типы и модульность и компиляция в JS с оптимизациями (самая важная — выкидывать ненужный библиотечный код). Учитывая, что над ним работают три "коллеги" и не используется он широко — понятно, что шероховатостей там масса.
Здравствуйте, Serginio1, Вы писали:
F>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. S> Кодогенерация это про шаблоны? S> На самом деле у них есть кодогенерация для async await
Я знаю про async/await. Это опять таки хорошо, — но это синтаксический сахар вокруг высокоуровневых вещей.
Но, нет, я же писал выше, что кодогенерация — это инлайнинг и dead code elimination (да и куча других довольно мелких вещей). Сейчас типичный деплоймент это использование готовых библиотек — они в свою очередь бывают весьма пузатые (даже минифицированные). Если к примеру взять туже closure-libary — то исходники всех компонент — 24Мб. Очевдно, что всё и сразу не нужно.
Тоже самое касается и остальных библиотек — половина jquery в полном объеме сразу тоже мало кем используется. Add: Они он даже выпустили 2 версии, полную и slim. Совершенный ручник.
Здравствуйте, AndrewVK, Вы писали:
F>> Да, но closure-compiler и closure-libary — основа для широко используемых приложений от гугла. AVK>Ключевое слово тут гугл, а не closure.
Ключевое — это практическое существование не малых продуктов созданных на конкретном тулчейне, которые демонстрируют сильные стороны подхода. Но, пожалуй хватит спорить ни о чём.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F>>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. S>> Кодогенерация это про шаблоны? S>> На самом деле у них есть кодогенерация для async await F> Я знаю про async/await. Это опять таки хорошо, — но это синтаксический сахар вокруг высокоуровневых вещей. F> Но, нет, я же писал выше, что кодогенерация — это инлайнинг и dead code elimination (да и куча других довольно мелких вещей). Сейчас типичный деплоймент это использование готовых библиотек — они в свою очередь бывают весьма пузатые (даже минифицированные). Если к примеру взять туже closure-libary — то исходники всех компонент — 24Мб. Очевдно, что всё и сразу не нужно. F> Тоже самое касается и остальных библиотек — половина jquery в полном объеме сразу тоже мало кем используется.
Он и пакует и HTML и CSS и JavaScript в 3 файла. В моем проекте есть и JQuery и Angular 2 плюс Proxy Promise. и Все это упаковывается в менее 5 МБ.
И при этом с файлами можно работать локально без сервера.
Возможно как и в .Net можно делать оптимизации на уровне компиляции TS в JS. Но думаю, что развитие WebPack более универсально.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Понятно, но для этого и существует webPack CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части
Минификация != dead code elimination, последний должен выкидывать ненужные классы, ненужные методы уменьшая общий объем кода, что для чистого JS — невозможно и часто сопряжено со знанием об устройстве модулей. Элементарнейший случай — не включать не нужные модули. Наподобии как в C# — наличие референса на сборку во время компиляции не означает что результирующая сборка будет её референсить, в случае если она не используется. В традиционной нативной линковке (тоже простой случай) — неиспользуемые объектные модули не включаются в результирующий исполнимый модуль, поэтому линкуя статическую стандартную библиотеку => мы платим более-менее только за то, что используем.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
S>> Понятно, но для этого и существует webPack CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части F> Минификация != dead code elimination, последний должен выкидывать ненужные классы, ненужные методы уменьшая общий объем кода, что для чистого JS — невозможно и часто сопряжено со знанием об устройстве модулей. Элементарнейший случай — не включать не нужные модули. Наподобии как в C# — наличие референса на сборку во время компиляции не означает что результирующая сборка будет её референсить, в случае если она не используется. В традиционной нативной линковке (тоже простой случай) — неиспользуемые объектные модули не включаются в результирующий исполнимый модуль, поэтому линкуя статическую стандартную библиотеку => мы платим более-менее только за то, что используем.
Net Core так и поступает. Правда там модульность плюс ограничен Reflection/ А так согласен из-за отсутствия типизации, сложно отследить какие классы нужно выбрасывать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework? S>То есть CoreClr и .Net Native выполняют один и тот же CIL код.
Ну да. _рантайм_ CoreClr используется для отладки, а библиотеки BCL UWP были синхронизированы с CoreClr. Но как из этого следует, что "сборки под .Net Core оптимизированы для .Net Native" — я
S> Мне интересно если разница между нативным кодом S>1. JIT .Net CLR S>2. JIT CoreCLR S>3. Net Native
На сегодня — есть. Первые два используют разные версии RyuJit, в .net core более свежая. Бинарный код .net native порождает бэкэнд от ms с++.
S>>Всё остальное — это уже следствия. S> И чем же оно противоречит приведенное мною?
Я уже пару раз писал, если с вашей точки зрения разницы нет — значит нет
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework? S>>То есть CoreClr и .Net Native выполняют один и тот же CIL код. S>Ну да. _рантайм_ CoreClr используется для отладки, а библиотеки BCL UWP были синхронизированы с CoreClr. Но как из этого следует, что "сборки под .Net Core оптимизированы для .Net Native" — я
Возможно я не прав , но я имел ввиду разбиение на модули
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности . Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.
Кстати ILSpy не читает сборки Core. Не подскажешь, каким рефлектором можно пользоваться?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>> Кстати ILSpy не читает сборки Core. Не подскажешь, каким рефлектором можно пользоваться?
Q>dotPeek?
Спасибо. Только я не понял. Смотрю классы, методы. А они с комментариями. Понял, что показываются реальные модули или это декомпилированный код?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Спасибо. Только я не понял. Смотрю классы, методы. А они с комментариями. Понял, что показываются реальные модули или это декомпилированный код?
Там можно включить показ именно декомпилированного кода; как C#, так и IL.
Здравствуйте, vorona, Вы писали:
V>Здравствуйте, Serginio1, Вы писали:
V>У меня читает, только местами криво дизассемблирует и не показывает места вызовов реализаций интерфейсов.
Ну вот DotPeek мне посоветовали. Вроде все читает.
и солнце б утром не вставало, когда бы не было меня
Using opaque reference types, JavaScript values could be made accessible to WebAssembly code through a builtin js module providing:
an exported string opaque reference type and exported functions to allocate, query length, and index string values;
an exported object opaque reference type and exported functions that correspond with the ES5 meta-object protocol including the ability to [Call]] function objects;
further exported opaque reference types for symbols and value types (including SIMD);
an exported value opaque reference type with exported functions for constructing values from integers, floats, objects, strings, etc and with exported functions for querying the type of a value and extracting the abovementioned payload types.
Since a browser's WebAssembly engine would have full knowledge of the js builtin module, it should be able to optimize string/object accesses as well as a normal JavaScript JIT compiler (perhaps even using the same JIT compiler).
Using opaque reference types, JavaScript values could be made accessible to WebAssembly code through a builtin js module providing:
an exported string opaque reference type and exported functions to allocate, query length, and index string values;
an exported object opaque reference type and exported functions that correspond with the ES5 meta-object protocol including the ability to [Call]] function objects;
further exported opaque reference types for symbols and value types (including SIMD);
an exported value opaque reference type with exported functions for constructing values from integers, floats, objects, strings, etc and with exported functions for querying the type of a value and extracting the abovementioned payload types.
Since a browser's WebAssembly engine would have full knowledge of the js builtin module, it should be able to optimize string/object accesses as well as a normal JavaScript JIT compiler (perhaps even using the same JIT compiler).
Здравствуйте, Serginio1, Вы писали:
S> То есть такого безобразия CEF, ES6, Angular 2, TypeScript использование классов .Net Core. Создание кроссплатформенного GUI для .Net с помощью CEF S>Не получить?
Для того, что бы получить подобное безобразие достаточно пользоваться browser-specific вещами: PPAPI плагины или chrome extensions в связке с каким-нибудь Native Messaging API. Но это всё настолько не переносимо (между браузерами), что может быть легче запилить на основе CEF. А может и нет.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Вот примерно после таких ответов заказчик вежливо отвечает "спасибо, мы вас поняли" и уходит к конкуренту. S>> Его изобретать то особо нечего .Net Core, AppDomain, WCF, RPC маршалинг по Tcp/Ip свой велосипед
S>Включить в инфраструктуру проект с кодом, написанном на непонятном половине разработчиков языке, без коммитов/issues, без community и без шансов на поддержку? S>Спасибо, мы вас поняли
S>То, что может выглядеть интересно с точки зрения программиста (серьёзно, вполне ок ), внезапно перестаёт таким быть как только нужно оценить потенциальные грабли для всего проекта от завязки на стороннюю библиотеку, вот в чём беда.
Кстати песочницу можно делать и на виртуальной машине ибо проблему плагинов (стороннего кода) никто не отнимал
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinix, Вы писали:
Ты бы ответил. Например в качестве песочницы можно ли использовать Docker
Docker легковесен и быстр. Он предоставляет устойчивую, рентабельную альтернативу виртуальным машинам на основе гипервизора. Он особенно полезен в условиях высоких нагрузок, например, при создания собственного облака или платформа-как-сервис (platform-as-service). Но он так же полезен для маленьких и средних приложений, когда вам хочется получать больше из имеющихся ресурсов.
Надо будет поизучать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Sinix, Вы писали: S>Ты бы ответил. Например в качестве песочницы можно ли использовать Docker.
Не-не-не, спасиб, надоело.
Будут реальные вопросы — вэлкам. А так — смысл нудно расписывать матчасть, если в ответ просто копипастится материал первой попавшейся статьи?
И ладно бы оно хоть как-то относилось к обсуждаемой теме, нет. Просто берётся любой баззворд и копируется текст-определение баззворда.
Такое впечатление, что я с гугловским I'm feeling lucky беседую
S>Будут реальные вопросы — вэлкам. А так — смысл нудно расписывать матчасть, если в ответ просто копипастится материал первой попавшейся статьи? S>И ладно бы оно хоть как-то относилось к обсуждаемой теме, нет. Просто берётся любой баззворд и копируется текст-определение баззворда.
S>Такое впечатление, что я с гугловским I'm feeling lucky беседую
Хорошо. Задам вопрос отдельно.
и солнце б утром не вставало, когда бы не было меня
Если раньше модификатор sealed class и sealed override ничего не говорили джиту, то теперь он их принимает в рассчет. Что может джит делать с виртуальными методами, а что нет, можно глянуть вот сюда: Devirtualization tests
Сейчас найти что-то не могу этого сообщения. Кто может знает как посмотреть все сообщения конкретного автора на гитхабе?
), внезапно перестаёт таким быть как только нужно оценить потенциальные грабли для всего проекта от завязки на стороннюю библиотеку, вот в чём беда.
Ещё и в msdn magasine. Самое смешное, что в том же абзаце есть ссылка на интервью
