khayrov 26 дек 2008 в 20:37

Обзор LLVM

13 мин

85K

Программирование*

+50

Комментарии 25

spanasik 26 дек 2008 в 21:22

Если сравнить с чистым gcc, какой прирост по скорости даёт использование этого бекэнда? Есть какие-то бенчи на эту тему?

khayrov 26 дек 2008 в 21:30

Ну вот например, тесты по недоброй славы shootout: leonardo-m.livejournal.com/73732.html
В среднем одинаково с GCC 4.
В их собственной системе «ночного» тестирования есть тесты из SPEC CPU, но самих результатов SPEC я не видел.

spanasik 26 дек 2008 в 21:37

Спасибо!

То есть, в трёх словах, конечный пользователь имеет возможность код на С/С++ компилить сразу под несколько архитектур с оптимизацией, которая учитывает особенности этих архитектур. Я правильно всё понял?

Сорри, что много вопросов — вещь интересная, копать некогда :-)

khayrov 27 дек 2008 в 01:09

llvm-gcc может порождать файлы с IR, которые можно скомпилировать на целевой платформе при наличии соответствующей инфраструктуры. Но едва ли это основной сценарий использования: всё-таки к программам на C/C++ неприлично тащить многомегабайтный компилятор.
llvm-gcc — это мощнейший стресс-тест для LLVM и способ интеграции существующего кода на C/C++. Просто как компилятор C++ особых преимуществ перед GCC он не имеет.
С помощью LLVM можно оптимизировать программы не только при развёртывании, но и в рантайме — оптимизация «горячих» участков кода. Это особенно актуально для динамических языков.

-1

alex_blank 27 дек 2008 в 00:48

мне вот интересно, почему Mono не на LLVM

или LLVM непригодно для JIT-компилятора?

P.S. а что не в тематическом блоге?

khayrov 27 дек 2008 в 00:59

> мне вот интересно, почему Mono не на LLVM
Судя по всему, когда Mono начинал развиваться, возможности LLVM были неадекватными: комент на LtU разработчика Mono.
Сейчас идёт работа над реализацией CLR и JVM поверх LLVM: VMKit
> или LLVM непригодно для JIT-компилятора?
Ещё как пригодно, возможность заложена изначально.
> а что не в тематическом блоге?
Не придумал в какой.

alex_blank 27 дек 2008 в 01:02

>> Не придумал в какой.

просто топики в личных блогах на главную не попадают

khayrov 27 дек 2008 в 01:15

Ну раз такое дело, двинул пока в ЯП :-)

IPv6 27 дек 2008 в 05:19

Спасибо за статью!!! Очень интересно
от себя могу добавить что именно через LLVM идет компиляция C/C++ в AS3 в адобовской алхимии и там действительно все очень поразительно шоколадно получается.

В общем штука офигительно перспективная. И есть надежда что адобе продвинет ее достаточно далеко. Дажешь ОШЕ любому скриптовому языку за 5 копеек! :)

IPv6 27 дек 2008 в 05:19

Опечатка, ОШЕ — это JIT :)

nuit 27 дек 2008 в 09:20

И майкрософт не отстаёт ;)
connect.microsoft.com/Phoenix

ozonebaby 27 дек 2008 в 11:46

Также энтузиастами ведется портирование фронт-енда языка программирования D (если кто не знает — это современный системный язык программирования, разрабатывается как замена С++) на LLVM, и она близка к завершению(лучше всего поддерживается linux X86, остальные платформы — немного отстают. Проект называется ldc, адрес www.dsource.org/projects/ldc/

lostdj 27 дек 2008 в 12:20

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

Теории по JIT'у навалом, но это либо радостные возгласы, либо констатация фактов: «теперь у нас есть такая крутая штука», более никаких подробностей. Да, есть исходники, но их разбор шибко тяжкий труд.

khayrov 27 дек 2008 в 13:05

LLVM берёт память под JIT не в куче процесса, а запрашивает у ОС страницы (mmap/VirtualAlloc) с правам read, write, execute и управляет этим куском памяти собственным менеджером.
Instruction cache задействуется в любом случае, какие тут нужны дополнительные телодвижения?

lostdj 27 дек 2008 в 13:48

Ясно, спасибо.

>>Instruction cache задействуется в любом случае, какие тут нужны дополнительные телодвижения?
Понятия не имею, поэтому и спросил.

Cha0S 27 дек 2008 в 19:38

Было бы интересно почитать про GC и exception handling… :)

khayrov 28 дек 2008 в 12:21

Едва ли я смогу рассказать про GC в LLVM лучше, чем в документации, потому что сам пока с ним не экспериментировал (но буду :-).
Насчёт исключений: invoke позволяет вызвать функцию, задав две точки продолжения: нормальную и ту, куда попадёт управление, если где-то в цепочке вызовов встретится unwind. Всё остальное — забота рантайма. Помимо документации здесь бывает полезно посмотреть на вывод llvm-g++ --emit-llvm — во что он превращает те или иные конструкции.

middle 28 дек 2008 в 11:57

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

middle 28 дек 2008 в 11:57

Да, а за статью спасибо :)

khayrov 28 дек 2008 в 12:03

Да, вы правы, стоит переформулировать, что LLVM умеет в некоторых случаях преобразовывать рекурсию в хвостовую за счёт ввода переменной-аккумулятора, так же как это делают вручную в ФЯП.

Nashev 8 сен 2012 в 03:04

Не понимаю назначения всё рано… ИМХО, чтобы я и такие как я поняли, нужно обзорно описать полный процесс компиляции, и показать, на каких его этапах найдено место для разрезания и вставки LLVM.