VM vs native, какие плюсы и минусы?

Question

[Наглая Морда]

Какие плюсы и минусы трансляции в байт-код ВМ по сравнению с компиляцией в нативный код? В каких ситуациях байт-код показывает себя лучше нативного, а в каких - хуже?

Comments

[Максим Гришин]

Как я понимаю, плюс байт-кода в ВМ - кроссплатформенность (достаточно портировать ВМ на архитектуру, а не всё приложение), минус - скорость из-за оверхэда от ВМ, который зависит от того, насколько нативно собрана сама ВМ (вдруг вы, скажем, её оттранслировали в API слишком высокого уровня вместо более низкого, которого бы хватило).

Answer 1

[Василий Банников]

Плюсы натива - не нужно тащить в рантайм какой-то интерпретатор или jit-компилятор, по тому часто само приложение получается компактнее, жрёт меньше ОЗУ, и быстрее запускается.
А также AOT-компилятор может делать больше сложных оптимизаций, тк у него нет ограничений в ресурсах и времени.
Нативное приложение обычно сложно декомпилировать

Плюсы вм - для портирования приложений нужно портировать только вм.
Если вм уже установлена на целевую машину, то байткод будет занимать меньше места, чем нативный код.
В теории может быть быстрее чем нативное приложение, тк у JITа имеется больше информации, чем у AOT-компилятора даже с профилем.
Компиляция в байткод идёт быстрее, чем в нативный, тк не нужно делать много сложных оптимизаций - этим будет заниматься JIT в фоне. И компилировать он будет только то что используется, а что не используется или используется редко - нет (будет без сложных оптимизаций)
Проблемы со скоростью холодного старта решаемы.

Answer 2

[Михаил]

Плюсы VM:

1. Главный плюс - переносимость. У нас есть VM и байт-код, работать это будет на любой платформе для которой есть VM. В частности девиз Java: write once, run anywhere.
   
2. Упрощение взаимодействия между разными языками. В случае native, например, у нас есть библиотека на C++ и код на Go - как их подружить? Это возможно, но это дополнительная сложность и трудоемкость. В случае JVM у нас есть interoperability между Java, Scala, Kotlin, Groovy и т.д. В случае JS - аналогично, между Javascript, Typescript, Kotlin.js, Dart. Конечно там есть свои особенности, например использовать Kotlin coroutines из Java-кода не так просто, но в целом, на базовом уровне все вполне пристойно работает вместе.
   
3. JIT-оптимизация. JIT-компилятор может собирать статистику работы конкретного экземпляра программы, выявлять hot paths и оптимизировать именно их. При компиляции такую оптимизацию сделать невозможно т.к. она зависит от рантайма (в частности от данных с которыми работает программа)
   

Минусы:

1. Зависимость от VM. Коду, очевидно, нужна VM. Во многих продуктах приходится поставлять VM вместе с продуктом, чтобы не зависеть от установленного в системе софта. Это увеличивает объем дистрибутива.
   
2. Поскольку перед стартом программы должна стартовать VM - программа стартует дольше
   
3. Производительность. В общем будет ниже чем у native кода. Хотя в очень многих случаях это не будет критично.
   

Answer 3

[rPman]

Если рассматривать конкретно llvm то эта инфраструктура может дать оптимизацию на основе выполнения, т.е. собирая статистику работы кода на лету может оптимизировать циклы на столько что итоговая скорость выполнения может стать выше аналогичного кода, скомпилированного нативно (например у меня так llvm код соптимизировал 'почти' не используемые блоки).

Да, для компиляторов c++ есть анализаторы, собрающие данные путем прогона алгоритма на специально собранных версиях, но маловато кто этим занимается, уж точно 99.99999% проектов что есть этим не заморачиваются (да и сложно это)

p.s. с другими виртуальными машинами такие тесты сложно провести, а то что я слышал jvm или clr работают медленней нативного, ощутимо

Comments

[Василий Банников]

Стоять. Разве llvm в рантайме существует?
Всегда думал, что это просто компилятор из llvm IR в нормальный нативный код AOT.

Profile Guided Optimization есть и в . NET-е

[rPman]

Василий Банников, я даже затрудняюсь ответить, я думал что внутри exe-шника скомпилированного clang заголовок для запуска виртуальной машины и байткод
p.s. реально читаю и не понимаю почему у меня по разному производительность gcc и clang кода тогда

[Василий Банников]

rPman, ну во первых это всё-таки разные компиляторы)
Во вторых - ты просто мог с разными параметрами компилировать. Например в gcc -O3, а в clang - без оптимизаций.

[rPman]

Василий Банников, конечно с одинаковыми оптимизациями
вариант с gcc выдает стабильные ~400k загруженных строк (ежесекундно пересчитывается скорость) а версия clang начинает с 400k и разгоняется за пару десяток секунд до 600k-800k (там просто чуть ли не весь код вырезается так как исходя из данных не используется, хз как они это делают)
Компиляция clang++ -std=c++17 -O3 ... для gcc подменяю clang++ на g++

что самое странное, на windows последний gcc и mingw llvm дают тот же результат но в 2 раза хуже (т.е. 200к и 400к соответственно), майкрософтовский компилятор выдает меньше 100к

файл большой но тесты проводятся по нескольку раз так что он читается из кеша, код - парсер мелких json (построчно записаны в файл) на основе simdjson с пропущенным кодом собственно обработки данных (наверное именно благодаря этому llvm удается оптимизировать, он видит что данные не используются ни при каких входах и наверное отключает куски кода)

[Василий Банников]

Мб просто в io упирается?

[rPman]

Василий Банников, не понял причем тут io, машина одна и та же, исходный файл один и тот же,данные те же, полностью влезают в оперативную память (первый прогон тестов упирается в скорость чтения с диска но последующие быстрые), кстати чтение файла я делал по разному, например с использованием потоков распаковка из архива gz или же распакованный на диске (несколько гигабайт), пока не упирается в скорость подачи данных - поведение такое как я описал, скорость работы программы зависит от выбора компилятора и ос