Как текущая производительность Моно виртуальной машины?

Если Вам интересно в письменной форме компилятор для функционального языка (а не процедурный) Simon Peyton-Jones и David Lester" Реализующие функциональные языки: учебное руководство " является превосходным руководством.

концептуальные основы того, как функциональная оценка работает, ведутся примерами на простом, но мощном функциональном языке под названием "Ядро". Кроме того, каждая часть компилятора Базового языка объяснена с примерами кода в Miranda (чистый функциональный язык, очень похожий на Haskell).

Несколько различных типов компиляторов описаны, но даже если Вы только следуете так называемому шаблонному компилятору для Ядра, у Вас будет превосходное понимание того, что заставляет функциональное программирование отсчитать.

9
задан Fredrik 19 July 2009 в 15:03
поделиться

5 ответов

Для сравнения Java и Mono вы можете взглянуть на The Computer Language Benchmarks Game .

2
ответ дан 4 December 2019 в 13:04
поделиться

Хотя я не использовал Mono, думаю, это зависит от того, что вы с ним делаете. Я не могу дать вам точных цифр, но вот интересный лакомый кусочек о производительности Mono с плавающей запятой:

http://forums.xna.com/forums/p/24249/24249.aspx

Поскольку Mono позволяет использование инструкций SIMD вашего процессора (на данный момент, я полагаю, SSE2 и SSE4) для значительного ускорения вычислений с плавающей запятой, это может сдуть .NET в таких вещах (до 10 раз быстрее), как показано на диаграмме (и надеюсь, Microsoft скоро реализует нечто подобное, .NET 4.5, пожалуйста?). Однако диаграмма также показывает, что .NET все еще значительно быстрее, чем Mono, если не использовать Mono.Simd. И вы могли совершить огромный прыжок веры и экстраполировать эту 20-процентную разницу в производительности с плавающей запятой на другие области, такие как производительность строк.

Тем не менее, это Mono 2.2, и все могло кардинально измениться, поскольку Mono в наши дни развивается довольно быстро, по крайней мере, я так слышал.

1
ответ дан 4 December 2019 в 13:04
поделиться

Измерение производительности - сложный вопрос. В прошлом, когда языки тестировались в одной и той же операционной системе, на одном и том же оборудовании и с очень ограниченным набором библиотек, можно было создавать тесты производительности, которые давали бы линейную метрику, измеряющую систему. Это позволило бы людям оценивать вещи от нуля до десяти, усваивать результат и быстро переходить к следующему предмету.

С современными системами ситуация стала более сложной, поскольку необходимо учитывать множество переменных.

По крайней мере, в случае Mono в игру вступает множество переменных:

  • Код:

    • Качество сгенерированного собственного кода.
    • Скорость, с которой генерируется собственный код. со слишком большим количеством функций для их собственного блага.

    Но языки не рисуют полную картину, API, которые вы будете использовать, операционная система хостинга и другие возможности будут иметь большое влияние на ваши результаты.

    Например, недавно в Mono мы добавили поддержку для замены механизма генерации кода Mono на более продвинутый, высоко оптимизирующий механизм (механизм LLVM). Оказалось, что было невероятно сложно найти тест, в котором накладные расходы на использование LLVM стоили дополнительного использования памяти: настольные и веб-приложения не показали большой разницы. Вероятно, это связано с тем, что это в основном приложения, связанные с вводом-выводом.

    Использование LLVM было полезно для научных и вычислительных приложений, но в реальной жизни это не сильно отличалось от настроек оптимизации Mono по умолчанию.

    Что касается специфики Mono: хотя Mono действительно использует сборщик мусора Boehm, большинство людей не понимают, что Boehm может быть настроен различными способами. Конфигурация непрофессионала по умолчанию действительно не очень эффективна, но она работает для всех, кому нужен быстрый сборщик мусора. Mono не использует Boehm в этом режиме, Mono широко настраивает Boehm для работы в точном режиме, а также с использованием преимуществ локального хранилища потоков, многоядерного GC и режимов освобождения памяти для ОС.

    Mono широко конфигурирует Boehm для работы в точном режиме, а также использует преимущества потокового локального хранилища, многоядерного GC и режимов освобождения памяти для ОС.

    Mono широко конфигурирует Boehm для работы в точном режиме, а также использует преимущества потокового локального хранилища, многоядерного GC и режимов освобождения памяти для ОС.

12
ответ дан 4 December 2019 в 13:04
поделиться

Я знаю, что это старый, но я только что нашел его, и ни один из текущих ответов (даже Мигеля) не затрагивает фундаментальный недостаток вашего вопроса: виртуальную машину.

Вы, кажется, являетесь неверно информирован по этому поводу. .Net не использует виртуальную машину, как и моно. Это правда, что .Net использует библиотеку времени выполнения , и код компилируется в IL для развертывания аналогично байт-коду Java. Однако среда выполнения - это не виртуальная машина. Разница в том, что после развертывания IL перед выполнением полностью компилируется в машинный код. Виртуальная машина не требуется.

0
ответ дан 4 December 2019 в 13:04
поделиться

Я протестировал Mono 2.0 и 2.2 в начале этого года с помощью SciMark2 и обнаружил, что производительность Mono немного увеличилась, но все еще намного медленнее, чем у большинства других ВМ

1
ответ дан 4 December 2019 в 13:04
поделиться
Другие вопросы по тегам:

Похожие вопросы: