Можете ли вы использовать Mono/LLVM для генерации более быстрых приложений .NET, чем с компилятором Microsoft С#?

Проект Mono with LLVM может использовать компилятор LLVM, который имеет довольно мощную оптимизацию для компиляции С#.NET. проект, который заставляет его работать на 20% быстрее в приложениях с интенсивным вычислением.

Моно теперь может использовать LLVM в качестве основы для генерации кода в дополнение к встроенному компилятору JIT Mono. Это позволяет Mono извлекать выгоду из всех оптимизаций компилятора, выполненных в LLVM. Например, оценка SciMark идет от 482 до 610.

Итак, можно ли настроить целевой проект С#.NET на использование Mono/LLVM, чтобы получить более быстрые приложения для Windows или Unix? Это просто так просто или вам придется реорганизовать/изменить код приложения? Будет ли это работать даже в рамках обычной .NET Framework или это специально для проекта Mono Framework? Учитывая это, было указано:

Эта дополнительная производительность стоит дорого: она потребляет больше времени и больше памяти для компиляции JIT с использованием LLVM.

Ответ 1

Бэкэнд LLVM подключается к компилятору Mono JIT (то, что преобразует сборку IL в сборку при запуске приложения), поэтому вам нужно запустить приложение с помощью Mono.

Ответ 2

Первое, что вам нужно сделать, это запустить вашу программу под профилировщиком, а затем посмотреть результаты, чтобы найти горячие точки или методы, которые вызываются слишком часто,

Для обычного рабочего стола для настольных компьютеров вы не сможете добиться значительной производительности благодаря использованию низкоуровневых оптимизаций в .NET/Mono. Это не C/С++.

Ответ 3

Мои тесты показывают, что Mono часто занимает около 2x столько же времени, чтобы выполнять те же задачи, что и MS.NET. Поэтому сделать Mono на 20% быстрее с LLVM недостаточно, чтобы догнать Microsoft. Кроме того, по какой-то причине, когда я использовал флаг --llvm в Windows, практически не было никакой разницы; возможно, LLVM был даже отключен в Windows по какой-либо причине (или был еще в 2011 году, когда я сделал тесты).

Ответ 4

В то время как профилировщик CPU или времени поможет вам сравнить показатели по сравнению с эталоном в этом случае, горячие точки hotpath или метода не будут меняться при смене компиляторов, но через другой путь выполнения вашего теста.

Горячие пути, методы с высокими исключительными байтами являются артефактом вашего кода приложения, а не тем, как этот код транслируется и оптимизируется на собственном ЦП. Сказав, что такие инструменты, как perfview с использованием Event Tracing for Windows (ETW), предоставляют статистику JIT, а для микробизнеса можно использовать множество пробоотборников или временных профилей, но это может быть проблематичным для правильного выбора.