The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Представлен бэкенд TPDE-LLVM, работающий в 10-20 раз быстрее LLVM в режиме без оптимизации

06.06.2025 14:16

Исследователи из Мюнхенского технического университета опубликовали инструментарий TPDE и основанный на нём бэкенд компилятора для LLVM - TPDE-LLVM, обеспечивающий генерацию машинного кода для архитектур x86-64 и AArch64 на основе промежуточного представления кода LLVM-IR. При тестировании TPDE-LLVM оказался быстрее бэкенда LLVM -O0 (генератор кода без оптимизаций) в 10-20 раз при том же уровне производительности результирующего машинного кода и увеличении размера на 10-30%. Наработки проекта опубликованы под лицензией Apache 2.0.

TPDE-LLVM изначально нацелен на обеспечение компиляции с минимальными задержками и уровнем качества, соответствующим режиму сборки без оптимизаций ("-O0"). Проектом предоставляется утилита для обособленного запуска tpde-llc, библиотека для интеграции в приложения (например, для реализации функциональности JIT-компилятора) и патчи для интеграции с Clang и Flang.

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

TPDE-LLVM использует для генерации кода три стадии:

  • Чистка и подготовка промежуточного представления LLVM;
  • Анализ информации о циклах и использовании переменных;
  • Формирование машинного кода.

Отмечается, что при участии авторов TPDE в ветки LLVM 19 и 20 уже добавлены оптимизации, позволившие ускорить работу штатного бэкенда LLVM на 18% на платформе x86-64 и на 13% на платформе ARM64. По мнению авторов TPDE, в будущем малой кровью можно будет ускорить бэкенд LLVM ещё возможно на 10-20%, но дальнейшее повышение производительности потребует значительных изменений. При этом даже при значительной переработке маловероятно, что существующий бэкенд LLVM удастся ускорить в 10 раз.

На текущем этапе развития среди целей проекта TPDE заявлено обеспечение поддержки промежуточного представления кода LLVM, полученного фронтэндом Clang в режимах оптимизации "-O0" и "-O1". Обработка промежуточного представления, созданного в режиме "-O2", пока не гарантируется из-за отсутствия поддержки в TPDE векторных операций. Частично поддерживается промежуточный код от Flang и компилятора Rust.

Дополнение: По скорости компиляции и производительности результирующего кода, TPDE не имеет существенных отличий от ранее доступного бэкенда DirectEmit. Однако, TPDE кратно меньше по объёму собственного кода, в том числе архитектурно-зависимых частей. При этом существенная часть кода TPDE приходиться на интерпретацию семантики входящего промежуточного представления кода, получаемого от LLVM.

  1. Главная ссылка к новости (https://discourse.llvm.org/t/t...)
  2. OpenNews: Релиз набора компиляторов LLVM 20
  3. OpenNews: Выпуск Tinygo 0.34, компилятора языка Go на базе LLVM
  4. OpenNews: Опубликованы результаты аудита безопасности кодовой базы LLVM
  5. OpenNews: Проект LLVM меняет схему нумерации версий
  6. OpenNews: Проект Minotaur развивает оптимизатор векторных инструкций для LLVM
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/63368-tpde
Ключевые слова: tpde, llvm, compile
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 15:14, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это компиляция быстрее или что даёт?
     
     
  • 2.3, Аноним (3), 15:15, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • –11 +/
    дает итоговый файл в два раза толще, и работающий медленнее.
     
     
  • 3.6, Аноним (6), 15:41, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > при том же уровне производительности результирующего машинного кода и увеличении размера на 10-30%
     
     
  • 4.8, Аноним (8), 15:46, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > LLVM -O0 (генератор кода без оптимизаций)
     
  • 3.35, EuPhobos (ok), 21:04, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > дает итоговый файл в два раза толще, и работающий медленнее.

    Ого, у тебя "-7" оценка твоего коммента, это получается аж 7 человек не прочитали новость, не вникли в суть и жмакнули тебе минус.
    Но ведь в новости так и написано: "примерно в 2 раза быстрее и в 2 раза меньше по размеру" - про LLVM, по сравнению с тем, что в новостях TPDE-LLVM.
    Получается что TPDE-LLVM работает в 2 раза медленнее и результат кода в 2 раза больше, что анонимус выше и написал, а кто-то не смог осилить это))

    ..вот и приходится работать за "кэпа очевидность".

     
     
  • 4.38, Аноним (38), 21:53, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Так минусы не за то что он соврал, а за то что не сказал правду.
     
     
  • 5.46, Аноним (8), 08:40, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > за то что не сказал правду.

    То есть соврал.

     
  • 5.49, Аноним (49), 11:35, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    всегда удивляли люди за место "истины" говорящие "правда" :)

    //ru.wikipedia.org/wiki/Правда

    """
    Пра́вда (от праслав. *pravĭda) — фундаментальное понятие русской культуры, сходное с понятием «истина», но в ряде случаев отличающееся от него и даже противопоставляемое.
    """

    вот откуда ноги растут.

     

  • 1.2, Аноним (3), 15:14, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ну то есть по простому, делают быстро, но итоговая программа работает в 2 раза медленней. И занимает в 2 раза больше места.
    Вдруг кому то нужно именно такое.
    Для быстрой разработки.
     
     
  • 2.7, Аноним (7), 15:44, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Проблема в том, что код без оптимизации будет работать примерно всегда. А вот с оптимизацией не всегда. И опять же левый компилятор это не тот компилятор, который нужен разработчику.
     
     
  • 3.9, Аноним (9), 15:55, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +8 +/
    идея чтобы при разработке не ждать по часу каждый билд (а только 30 минут)
    когда основная часть написана - можно уже  прогнать с оптимизациями и проверить релизный билд
     
     
  • 4.17, _ (??), 16:52, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • –3 +/
    И это ВНЕЗАПНО!(С) - 2 разных компайлера. Всё что ты до этого прогнал на тестовом - выкидываем и начинаем отлаживать на боевом.
    Смысл?!?!

    Впрочем в ойте нынче смысла искать не принято...

     
     
  • 5.19, Аноним (-), 17:03, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Смысл?!?!

    Смысл в том, что оно на обоих должно работать корректно.
    А шанс что будут различия не такой большой, чтобы ждать столько времени.

     
  • 5.25, Аноним (25), 18:31, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Ну как бы есть стандарт. Не можешь писать по стандарту - вон из профессии. К сожалению многие игроделы в нулевых писали не по стандарту. Когда впоследствии исходник с лопаты открыли ради пиара ... внезапно если собрать шлангом, то исчезают ветви, исчезают проверки, причём через несколько уровней вложенности, ибо инлайнинг, в результате use after free и sigsegvы.
     
     
  • 6.26, Аноним (7), 18:52, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Стандарт стандарту рознь. Вон пишешь c89, а потом оказывается, что оптимизатор тебе код интересно соптимизирует и ничего из перечисленного в K&R не работает. Про плюсы лучше не вспоминать.
     
  • 6.36, Аноним (36), 21:36, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну как бы есть стандарт. Не можешь писать по стандарту

    Вы походу проектов сложнее хеллоуврота не писали, раз мелите такой бред. В Си со стандартами беда, а про С++ даже говорить не буду, насколько это печаль, особенно если это проект написанный кем-то до тебя.

    > вон из профессии

    Нейросеть итак скоро заменит всех работников "интеллектуального" труда. Благо это проще и эффективнее. А вот заменить тех, кто работает руками, типа сантехников, автомехаников или сварщиков - в обозримом будущем точно нет.

     
     
  • 7.39, Аноним (38), 22:00, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Нейросеть итак скоро заменит всех работников "интеллектуального" труда.

    "Вы походу проектов сложнее хеллоуврота не писали..."

    > А вот заменить тех, кто работает руками, типа сантехников, автомехаников или сварщиков - в обозримом будущем точно нет.

    А их заменят те кого заменила нейросеть.

     
  • 7.44, Аноним (44), 02:00, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    >а про С++ даже говорить не буду, насколько это печаль, особенно если это проект написанный кем-то до тебя.

    Особенно если этого "кого-то" (с фамилией, именем, отчеством, адресом проживания и местом работы, а также известной мордой, которая прямо так и просится, чтобы в неё с ноги) вон из профессии надо гнать поганой метлой.

    >Нейросеть итак скоро заменит всех работников "интеллектуального" труда

    А кто саму нейросеть будет программириовать? Сама нейросеть? Да, она уже. Но саму нейросеть, программирующую нейросеть, которая программирует нейросети тоже кто-то должен программировать. Переходим на более высокий уровень. Я вообще почти не кодю теперь. Вместо этого сижу и объясняю нейросети как создавать промпты, инструктириующие нейросеть кодить то, что мне нужно.

     
  • 3.45, Аноним (45), 02:26, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Интересный подход: пишем на UB-based языках код, который работает не всегда, (т.е. содержит UB), и компилируем без оптимизации.

    В чем был смысол выбора Си/плюсов? Быстро не будет, оптимизацию же выключили. Почему не выбрать другой язык?

     
  • 2.29, Bottle (?), 19:35, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это будет все равно быстрее питона и джаваскрипта, так что смысл есть.
     

  • 1.4, Аноним (9), 15:34, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    что насчет linking??
     
  • 1.5, freehck (ok), 15:35, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Возможно, этот инструментарий имеет смысл, если нужно запускать недолго живущие маленькие приложения, распространяемые в форме LLVM-IR. Но вообще штука сильно нишевая.
     
  • 1.18, Аноним (18), 16:54, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Это для отладки разработки и прочего, не для релиза
     
  • 1.21, Аноним (21), 17:45, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Ничего не понятно. Для понимания нужно ядро Linux собрать разными компияторами и с разными оптимизациями. Без GCC никуда.
     
  • 1.24, Аноним (25), 18:26, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Без оптимизации нахрен не нужно. Экономия на копейку - упущенных ускорений - на рубль. Всегда собираю с максимальными оптимизациями. Поэтому у меня горячие циклы всего лишь несколько инструкций. Я бы до такого не додумался - а LLVM z3 юзает и находит то, что человек никогда не найдёт. Да, это вычислитеильно дорого. Но не оптимизировать - ещё дороже.
     
     
  • 2.31, Аноним (31), 20:25, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > юзает и находит то, что человек никогда не найдёт

    Вы таки не уточнили, что речь идёт о человеке после курсов от ютубных гуру, без профильного computer science образования (ну или просто хотя бы технического).

     
  • 2.33, Аноним (33), 20:36, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не осознаете, что у LLVM много применений помимо один раз скомпилировал - запустил много раз.

    Например RPCS3 (эмулятор PS3) с помощью LLVM прекомпилирует шейдеры, и сейчас это занимает минуты на 8 ядрах. Если это будет занимать секунды, это будет совсем другой экспириенс.

    Еще пример - LLVM JIT в PostgreSQL. Пока его применение для планировщика ограниченно именно задержками компиляции. С LLVM быстрее, но плата за его использование велика. Если будет невелика - использовать можно будет куда чаще.

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

     
     
  • 3.37, Аноним (7), 21:36, 06/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    В нём зачем-то добавили сборку clang, теперь фпс ниже, бинари больше, а лаги сильнее. Pcsx2 теперь вообще только clang собирается по-моему и собрать отдельный квест как оказалось. Собирается только с кучей неочевидных флагов.
     
  • 3.43, Аноним (44), 01:49, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Например RPCS3 (эмулятор PS3) с помощью LLVM прекомпилирует шейдеры, и сейчас это занимает минуты на 8 ядрах. Если это будет занимать секунды, это будет совсем другой экспириенс.

    Шейдеры вам нужны постоянно. Уж лучше минуты предкомпиляции и нормальный FPS, чем говняное качество но быстро скомпилировано. Но вы правы в определённом смысле: если бы -O0 от -O3 отличался на 3 десятичных порядка, то имело бы смысл сначала компилить с -O0, а в фоне запускать компиляцию на -O3, и когда готово - заменять. Но только в одном случае - в случае простоя CPU при работе. А это в случаях, когда нужно высокопроизводительное, обычно не так. Поэтому в большинстве случаев имеет смысл сразу компилить на максимуме, а юзер подождёт, потому что во многих случаях важна не столько изначальная задержка, сколько throughput, а задержку при повторном исипользовании можно новелировать, закешириовав результат. Если иархитектура заранее известна - код можно собрать тоже заранее, напр. в OpenCL есть механизм для использования предсобранных ядер.

     

  • 1.30, Аноним (31), 20:24, 06/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Запустите gcc первых серсий на своих i9 и вы офигеете от скорости. Будет в миллион раз быстрее. И я даже не говорю о всяких borland turbo c++, которые будут работать со скоростью близкой к скорости света.
     
     
  • 2.48, Аноним (48), 11:01, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    ну так ты и запусти. какую версию гцц с какой нужно сравнить конкретно? мне тоже интересно. бенчмарков в сети можно найти много и разных
     
  • 2.50, нах. (?), 11:56, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    > Запустите gcc первых серсий на своих i9 и вы офигеете от скорости. Будет в миллион раз
    > быстрее.

    потому что оптимизировать оно умело - примерно - никак. Нет ножек, нет варенья, вроде все логично?

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

     

  • 1.40, Аноним (40), 00:15, 07/06/2025 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что за DirectEmit на первой картинке? Т.е. уже было что-то, что работает ± так же и не нужно было ничего изобретать?..
     
     
  • 2.41, мимо проходил (?), 00:54, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Если попростому, то примерно так:

    Раньше был только DirectEmit.
    Это кастомный бекенд, который по-сути делает тоже что описано в новости.

    Недостатки DirectEmit:
    - в сложности (запутанности и объеме) кода
    - в существенном дублировании кода для x86_64 и AARCH64
    - но с "множеством мелких ручных правок"

    Теперь сделали TPDE, который выдаёт столько-же попугаев, но в три раза меньше по объему кода. При этом архитектурно-зависимого кода тоже сильно меньше (почти вдвое).

    Но на деле TPDE еще круче именно по простоте/объему кода, так как на самом деле в его коде (который и так в три раза меньше DirectEmit) где-то от 1/2 до 2/3 приходиться на poilerate-подобный код приходиться на интерпретацию/семантику входящего IR-представления получаемого от LLVM.

    Как-то так.

     
     
  • 3.42, Аноним (44), 01:40, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Erthink, вы зачем никнейм сменили?
     
  • 2.47, Аноним (47), 09:28, 07/06/2025 [^] [^^] [^^^] [ответить]  
  • +/
    Это все конечно круто.

    Но решили бы они сначала проблемы количества циклов перезаписи.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2025 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру