Какова текущая производительность виртуальной машины Mono? - PullRequest
9 голосов
/ 19 июля 2009

В Интернете полно различных тестов производительности на разных языках, компиляторах и виртуальных машинах. Тем не менее, вряд ли кто-либо из них тестирует производительность с использованием какого-либо реального сценария. Кроме того, поиск в Google таких тестов обычно дает результаты только нескольких лет, поскольку у них было больше всего времени для сбора ссылок на них.

Кто-нибудь из вас имеет реальное представление о текущей производительности различных виртуальных машин? Кроме того, мне особенно хотелось бы узнать, как производительность Mono сравнивается с показателями Microsoft .Net и Sun Java и как в последнее время развивалась производительность различных виртуальных машин.

Ответы [ 5 ]

12 голосов
/ 22 июля 2009

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

Вещи стали более сложными с современными системами, поскольку необходимо учитывать множество переменных.

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

  • Код:

    • Качество сгенерированного собственного кода.
    • Скорость, с которой генерируется собственный код.
    • Память, необходимая для генерации кода и оптимизации кода
    • Является ли генератор кода многопоточным
    • Является ли сгенерированный код потокобезопасным
    • Использует ли он особые функции процессора во время компиляции или во время JIT.
    • Может ли он использовать SIMD-инструкции, если они доступны.
    • Соответствует ли язык сам по себе многоядерным платформам
    • Предоставляет ли язык достаточно параметров для оптимизатора для автоматической настройки вашего кода (как это делает Fortran).
  • Управление памятью:

    • Используемый алгоритм сборки мусора
    • ГХ масштабируется с несколькими ЦП?
    • Является ли ГХ инкрементным или в реальном времени?
    • Поддерживает ли локальное хранилище потоков для повышения производительности?
    • Является ли он точным, компактным, поколенческим, консервативным и что смешивает каждый.
  • Дизайн API:

    • Разработаны ли API для задержки или пропускной способности
    • Поддерживают ли API-интерфейсы автоматическое масштабирование до нескольких процессоров.
    • Можете ли вы перенести тяжелую работу на графический процессор?
    • Поддерживают ли ваши API потоковые интерфейсы

Все эти вещи очень усложняют ситуацию и затрудняют получение простого ответа от 0 до 10.

Если бы вы разделили языки на классы, и вы предполагаете, что вы обладаете компетентностью и эффективностью, я бы поделил мир на эти классы:

  • Уровень 1: Язык ассемблера, настроенный вручную профессионалом
  • Уровень 2: Статически скомпилированные, строго типизированные языки: C / C ++ / Fortran /
  • Уровень 3: управляемые / JIT языки: Java / C # /. NET / Mono / Boo / F #
  • Уровень 4: языки с динамической типизацией и JIT: Google V8, IronPython, IronRuby
  • Уровень 5: чисто интерпретируемые языки: Python, Perl
  • Уровень 6: чисто интерпретируемые языки со слишком большим количеством функций для их собственной пользы.

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

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

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

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

2 голосов
/ 19 июля 2009

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

1 голос
/ 15 октября 2009

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

1 голос
/ 20 июля 2009

Хотя я не использовал 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 движется довольно быстро в наши дни, или, как я слышал.

0 голосов
/ 02 октября 2009

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...