vs2019 community, пару месяцев назад обновлена.
К слову об классах-обёртках для int: из личных издевательств над математическими библиотеками знаю, что лучше использовать `ref int`, `ref double` чем класс-обёртку. Удаление таковой из Cassovary.Net дало 30% прирост производительности.
Win 7. (Некоторых пакетов просто нет в природе для неё)
.Net Standart 2.0 в списке пакетов есть, но больше похоже на проблему с версией языка. static у лямбд не работает в частности, а так же проверка типов более строгая (требует explicit cast) для == между 'Entity.Number.Integer' и 'int'. Причём это довольно странно, implicit cast объявлены, должно работать (я так делал, но не на этом типе проекта)
Хотелось бы увидеть именно на сложном. Пробовал собрать проект на моём ПК — у меня нет пакетов netstandard2.0, только .Net Framework. Некоторые использованные фичи языка недоступны.
> Оно транслируется в тот же IL, который, в свою очередь, транслируется тем же JIT-ом.
Я примерно то же ожидал от DynamicDelegate, но нет: похоже, там есть накладные расходы на проверки видимости, даже если она отключена: имеет значение, укажите ли вы класс, в который «добавляется» метод (по умолчанию это Object): разница в 2 раза.
Причём в контексте той задачи, что я решал (повторяющийся доступ к приватным свойствам объекта, способный пережить ~1200 вызовов в секунду) в тестах других разработчиков LinqExpressions были не самыми быстрыми.
> Ваша лямбда скомпилится в ту же, что и у меня.
В этом и смысл. Я хочу увидеть честное быстродействие Linq Expressions на честном примере. Я понимаю, что вы хотите показать способность библиотеки вашей библиотеки оптимизировать задачу, но сейчас нет возможности отделить одно от другого (накладные расходы linq/выигрыш от оптимизации).
Да, вижу, видимо пропустил ссылку. Как я уже сказал GIT не может/не имеет права оптимизировать такие вещи, в силу ряда разных причин. Эта обязанность ложится на разработчика.
Попробуйте протестировать вот эту лямбду:
public readonly Func<Complex, Complex, Complex, Complex> NormalComplicatedOptimizedLambda = (a, b, c) => {
var d = Complex.Sin(a + b + Complex.Cos(c));
return d * 6 + Complex.Pow(3, d) + Complex.Tan(d) - Complex.Log(d, 3) + d + d + d + d + d + d + d + d + d + d + d;
};
Кешировании чего именно? (В статье не упоминается, а с этой библиотекой я не знаком)
Промежуточные результаты перевычисляются несколько раз? JIT'у не хватает контекста, чтобы кешировать результаты вызовов функций, он не знает, есть ли у функций сайдэффекты или нет. Это должен сделать сам программист.
Просто с такой цифрой и без кода результаты тестов вызывают сомнения в самих тестах. Я нисколько не приуменьшаю вару работу, но хотелось бы видеть реальные осмысленные тесты.
Решал задачу связанную с генерацией кода (быстрый доступ к приватным полям/методам классов), только использовал DynamicDelegate.CreateDelegate. Для коротких методов (4-6 инструкций) разница со скомпилированным при сборке кодом была значительной — 10 раз. (но всё равно быстрее, чем чистый reflection)
Я так полагаю, под Linux нет возможности подключиться к удалённому реестру? Что скорее проблема отсутствия инструментария, чем проблема PowerShell в частности. В PowerShell вполне возможно добавить кастромный командлет.
Всё таки обсуждение PS vs. BAT более актуально, чем PS vs. C#
C# и PowerShell — взаимодополняющие инструменты для разных задач.
PowerShell и BAT — новый инструмент разработанный на смену старому.
> Есть еще один маленький нюанс. Сейчас все ратуют за продуктивность. Продуктивность CMD была бы меньше, чем PS? Не думаю…
Я всё таки поспорю, что будет: что в bash, что в PS мне не нужно заморачиваться, сколько же '%' всё таки мне нужно поставить, чтобы переменная корректно прочиталась/обновилась.
BAT выглядит как постепенные наслоения… синтаксиса, постепенно эволюционировавшие в течении многих. PS же, помимо всего прочего, взгляд на имеющийся опыт и сглаживание существующих углов.
Так же как и в PS. Назовём это «удалить часть файлов по списку*». Это краткое версия описания задачи. В скрипте нужно было скопировать часть файлов, за исключением некоторого списка. Часть deployment-скрипта, включающего работу с git, реестром и архивирование.
Я конечно могу разобраться и написать всё это для cmd, но даже установка cygwin и использование sh вместо bat — продуктивнее (да, я делал это под Win XP).
Вопрос в сложности и скорости решения.
и Cmd, и PowerShell «заточены» под исполнение внешних приложений. Но когда мне понадобилось обработать группу файлов (удалить часть файлов по списку), разобраться в работе PowerShell было проще, чем вспомнить как использовать цикл в Cmd.
В C# можно решить те же задачи, но при этом вместо однострочного вызова вы получаете блок кода с инициализацией вызова, работой stdin/stdout (если ещё оно будет работать, многие консольные приложения без бубна не пишут вывод в реальном времени).
PowerShell может использовать классы .Net, так что по потенциальным возможностям он не уступает C#. Но в первую очередь это всё же командный процессор, призванный заменить CMD (при этом сохраняя частичную совместимость команд). То есть, программный клей для автоматизации работы других инструментов, как сам сmd или sh.
Можете ли вы на нём написать, например, текстовый редактор? Можете. Но зачем, если это проще и быстрее сделать на том же С#?
С другой стороны, есть возможность поставить время на паузу (приостановить симуляцию для экономии энергии) и отправиться к другой звезде. Причём достаточно всего нескольких индивидуумов так поступивших.
Условия игры таковы, что майнеры скупят *все* доступные карты, зафиксировав цену на уровне, при котором карта едва окупает себя при майнинге. Потому что это буквально печатный станок делающий деньги из ничего.
Минусом к беспроводным ещё идёт DAC установленный в самих наушниках, который может быть довольно сомнительного качества. В случае с проводными DAC в устройстве.
К слову об классах-обёртках для int: из личных издевательств над математическими библиотеками знаю, что лучше использовать `ref int`, `ref double` чем класс-обёртку. Удаление таковой из Cassovary.Net дало 30% прирост производительности.
.Net Standart 2.0 в списке пакетов есть, но больше похоже на проблему с версией языка. static у лямбд не работает в частности, а так же проверка типов более строгая (требует explicit cast) для == между 'Entity.Number.Integer' и 'int'. Причём это довольно странно, implicit cast объявлены, должно работать (я так делал, но не на этом типе проекта)
> Оно транслируется в тот же IL, который, в свою очередь, транслируется тем же JIT-ом.
Я примерно то же ожидал от DynamicDelegate, но нет: похоже, там есть накладные расходы на проверки видимости, даже если она отключена: имеет значение, укажите ли вы класс, в который «добавляется» метод (по умолчанию это Object): разница в 2 раза.
Причём в контексте той задачи, что я решал (повторяющийся доступ к приватным свойствам объекта, способный пережить ~1200 вызовов в секунду) в тестах других разработчиков LinqExpressions были не самыми быстрыми.
В этом и смысл. Я хочу увидеть честное быстродействие Linq Expressions на честном примере. Я понимаю, что вы хотите показать способность библиотеки вашей библиотеки оптимизировать задачу, но сейчас нет возможности отделить одно от другого (накладные расходы linq/выигрыш от оптимизации).
Попробуйте протестировать вот эту лямбду:
Промежуточные результаты перевычисляются несколько раз? JIT'у не хватает контекста, чтобы кешировать результаты вызовов функций, он не знает, есть ли у функций сайдэффекты или нет. Это должен сделать сам программист.
Просто с такой цифрой и без кода результаты тестов вызывают сомнения в самих тестах. Я нисколько не приуменьшаю вару работу, но хотелось бы видеть реальные осмысленные тесты.
Решал задачу связанную с генерацией кода (быстрый доступ к приватным полям/методам классов), только использовал DynamicDelegate.CreateDelegate. Для коротких методов (4-6 инструкций) разница со скомпилированным при сборке кодом была значительной — 10 раз. (но всё равно быстрее, чем чистый reflection)
C# и PowerShell — взаимодополняющие инструменты для разных задач.
PowerShell и BAT — новый инструмент разработанный на смену старому.
> Есть еще один маленький нюанс. Сейчас все ратуют за продуктивность. Продуктивность CMD была бы меньше, чем PS? Не думаю…
Я всё таки поспорю, что будет: что в bash, что в PS мне не нужно заморачиваться, сколько же '%' всё таки мне нужно поставить, чтобы переменная корректно прочиталась/обновилась.
BAT выглядит как постепенные наслоения… синтаксиса, постепенно эволюционировавшие в течении многих. PS же, помимо всего прочего, взгляд на имеющийся опыт и сглаживание существующих углов.
Скрипт, который я упоминал (отличный образчик stackoverflow-программирования):
github.com/krypt-lynx/RWLayout/blob/master/Deploy/Deploy.ps1
Я конечно могу разобраться и написать всё это для cmd, но даже установка cygwin и использование sh вместо bat — продуктивнее (да, я делал это под Win XP).
и Cmd, и PowerShell «заточены» под исполнение внешних приложений. Но когда мне понадобилось обработать группу файлов (удалить часть файлов по списку), разобраться в работе PowerShell было проще, чем вспомнить как использовать цикл в Cmd.
В C# можно решить те же задачи, но при этом вместо однострочного вызова вы получаете блок кода с инициализацией вызова, работой stdin/stdout (если ещё оно будет работать, многие консольные приложения без бубна не пишут вывод в реальном времени).
Каждому инструменту своя задача.
Можете ли вы на нём написать, например, текстовый редактор? Можете. Но зачем, если это проще и быстрее сделать на том же С#?
форматирование этой формулы читабельности не помогает. Я в таких случаях стараюсь держать скобки в строке сбалансированными