Почему llvm считается непригодным для внедрения JIT?

Многие динамические языки реализуют (или хотят реализовать) JIT-компилятор, чтобы ускорить их время выполнения. Неизбежно, кто-то из галереи арахиса спрашивает, почему они не используют LLVM. Ответ часто: "LLVM не подходит для создания JIT". (Например, комментарий Армина Риго здесь.)

Почему LLVM непригоден для создания JIT?

Примечание. Я знаю, что LLVM имеет свой собственный JIT. Если LLVM был непригодным, но теперь подходит, скажите, что изменилось. Я не говорю о запуске LLVM Bytecode в LLVM JIT, я говорю об использовании библиотек LLVM для реализации JIT для динамического языка.

Ответ 1

Есть несколько заметок о LLVM в блоге Post-mortem Unladen Swallow: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospective.html.

К сожалению, LLVM в своем текущем состоянии действительно спроектирован как статический оптимизатор компилятора и задний конец. Генерация и оптимизация кода LLVM хороши, но дороги. Оптимизации предназначены для работы с IR, генерируемыми статическими C-подобными языками. Большинство важных оптимизаций для оптимизации Python требуют высокоуровневых знаний о том, как программа выполнялась при предыдущих итерациях, а LLVM не помогала нам в этом.

Ответ 2

Почему LLVM непригоден для создания JIT?

Я написал HLVM, высокоуровневую виртуальную машину с богатой системой статического типа, включая типы значений, устранение хвостового вызова, общую печать, C FFI и POSIX с поддержкой как статической, так и JIT-компиляции. В частности, HLVM предлагает невероятную производительность для высокоуровневой виртуальной машины. Я даже реализовал ML-подобный интерактивный интерфейс с вариантами типов и сопоставлением шаблонов с использованием JIT-компилятора, как показано в этой демонстрации компьютерной алгебры. Вся моя работа, связанная с HLVM, составляет всего несколько недель (и я не компьютерный ученый, а просто dabbler).

Я думаю, что результаты говорят сами за себя и недвусмысленно демонстрируют, что LLVM отлично подходит для компиляции JIT.

Ответ 3

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

Ответ 4

Обновление: по состоянию на 7/2014 LLVM добавила функцию "Patch Points", которая используется для поддержки Polymorphic Inline Caches в Safari FTL JavaScript JIT. Это касается именно случая использования, жалующегося на комментарий автора в Armin Rigo в исходном вопросе.

Ответ 5

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

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

Для динамических языков LLVM может оказаться не лучшим инструментом, потому что он предназначен для оптимизации языков системного программирования, таких как C и С++, которые сильно/статически типизированы и поддерживают очень низкоуровневые функции. В целом оптимизация, выполняемая на C, на самом деле не делает динамические языки быстрыми, потому что вы просто создаете эффективный способ работы с медленной системой. Современные динамические языки JIT выполняют такие функции, как встроенные функции, известные только во время выполнения, или оптимизация в зависимости от того, какой тип переменной имеет большую часть времени, для которой LLVM не предназначен.

Ответ 6

Подробнее о LLVM IR см. здесь: LLVM IR - это компилятор IR.