Pull to refresh

Comments 25

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

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

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

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

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

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

В общем штука офигительно перспективная. И есть надежда что адобе продвинет ее достаточно далеко. Дажешь ОШЕ любому скриптовому языку за 5 копеек! :)
Также энтузиастами ведется портирование фронт-енда языка программирования D (если кто не знает — это современный системный язык программирования, разрабатывается как замена С++) на LLVM, и она близка к завершению(лучше всего поддерживается linux X86, остальные платформы — немного отстают. Проект называется ldc, адрес www.dsource.org/projects/ldc/
Такой вопрос, не касающийся исключительно LLVM (хотя и в большей степени), про JIT: сгенерированные нативные машинные инструкции отправляются в хип процесса, управление процессором передаётся по адресу этих инструкций, но что об этом знает сам процессор? ОС?
Взять тот же кэш процессора — он как-то задействуется?

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

>>Instruction cache задействуется в любом случае, какие тут нужны дополнительные телодвижения?
Понятия не имею, поэтому и спросил.
Было бы интересно почитать про GC и exception handling… :)
Едва ли я смогу рассказать про GC в LLVM лучше, чем в документации, потому что сам пока с ним не экспериментировал (но буду :-).
Насчёт исключений: invoke позволяет вызвать функцию, задав две точки продолжения: нормальную и ту, куда попадёт управление, если где-то в цепочке вызовов встретится unwind. Всё остальное — забота рантайма. Помимо документации здесь бывает полезно посмотреть на вывод llvm-g++ --emit-llvm — во что он превращает те или иные конструкции.
В функции factorial, приведённой в качестве примера хвостовой рекурсии, рекурсия вовсе не хвостовая. Конечно, хорошо, что LLVM умеет преобразовывать такую рекурсию в цикл (если это действительно так), но получается, что LLVM может оптимизировать не только хвостовую рекурсию, но и другие частные случаи общей рекурсии.
Да, а за статью спасибо :)
Да, вы правы, стоит переформулировать, что LLVM умеет в некоторых случаях преобразовывать рекурсию в хвостовую за счёт ввода переменной-аккумулятора, так же как это делают вручную в ФЯП.
Не понимаю назначения всё рано… ИМХО, чтобы я и такие как я поняли, нужно обзорно описать полный процесс компиляции, и показать, на каких его этапах найдено место для разрезания и вставки LLVM.
Спасибо, это прям то, что доктор прописал!
Было бы классно, если поправили блоки кода. Совершенно невозможно читать =(
Присоединяюсь к оратору выше. Судя по поиску, эта статья одна из немногих обзорных по LLVM и код нечитаем.
Only those users with full accounts are able to leave comments. Log in, please.