Не могу дать каких-то определённых советов, так как смотрел только поверхностно по коду.
Классы чисел у вас выступают как константы? Если да, то даже ref не нужен
Всё зависит от ваших задач. Возможно, ничего не стоит менять, так как это наверняка уменьшит читабельность и увеличит количество кода.
В моём случае мне нужно было рассчитать весь layout «пока пользователь не заметил», буквально (это порядка 0.01 секунды)
Собственно, Cassovary.Net — это порт с Java, видимо обёртка нужна для того, чтобы сделать значение мутабельным. На C# в этом не было никакого смысла.
Я так понимаю, что ref double быстрее из-за способа обращения к значению: в случае с обёрткой обращение идёт к значению по указателю в управляемой памяти со сдвигом, ref double просто значение по указателю? Если значение константное (ref не нужен, просто double), то оно будет лежать прямо в стеке
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 в устройстве.
Классы чисел у вас выступают как константы? Если да, то даже ref не нужен
Всё зависит от ваших задач. Возможно, ничего не стоит менять, так как это наверняка уменьшит читабельность и увеличит количество кода.
В моём случае мне нужно было рассчитать весь layout «пока пользователь не заметил», буквально (это порядка 0.01 секунды)
Вот изменение, которое я делал в Cassovary.Net:
github.com/krypt-lynx/Cassowary.net/commit/3fd07e5078f4ff55e06418cb00578be8bbbae6e0
Собственно, Cassovary.Net — это порт с Java, видимо обёртка нужна для того, чтобы сделать значение мутабельным. На C# в этом не было никакого смысла.
Я так понимаю, что ref double быстрее из-за способа обращения к значению: в случае с обёрткой обращение идёт к значению по указателю в управляемой памяти со сдвигом, ref double просто значение по указателю? Если значение константное (ref не нужен, просто double), то оно будет лежать прямо в стеке
К слову об классах-обёртках для 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 (если ещё оно будет работать, многие консольные приложения без бубна не пишут вывод в реальном времени).
Каждому инструменту своя задача.
Можете ли вы на нём написать, например, текстовый редактор? Можете. Но зачем, если это проще и быстрее сделать на том же С#?
форматирование этой формулы читабельности не помогает. Я в таких случаях стараюсь держать скобки в строке сбалансированными