Исследователи из Мюнхенского технического университета опубликовали инструментарий TPDE и основанный на нём бэкенд компилятора для LLVM - TPDE-LLVM, обеспечивающий генерацию машинного кода для архитектур x86-64 и AArch64 на основе промежуточного представления кода LLVM-IR. При тестировании TPDE-LLVM оказался быстрее бэкенда LLVM -O0 (генератор кода без оптимизаций) в 10-20 раз при том же уровне производительности результирующего машинного кода и увеличении размера на 10-30%. Наработки проекта опубликованы под лицензией Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63368
Это компиляция быстрее или что даёт?
дает итоговый файл в два раза толще, и работающий медленнее.
> при том же уровне производительности результирующего машинного кода и увеличении размера на 10-30%
> LLVM -O0 (генератор кода без оптимизаций)
Подвох, что при "том же уровне производительности", это же как неоптимизипованный уже самый медленный и сильно раздутый код, но теперь ещё толще.
> дает итоговый файл в два раза толще, и работающий медленнее.Ого, у тебя "-7" оценка твоего коммента, это получается аж 7 человек не прочитали новость, не вникли в суть и жмакнули тебе минус.
Но ведь в новости так и написано: "примерно в 2 раза быстрее и в 2 раза меньше по размеру" - про LLVM, по сравнению с тем, что в новостях TPDE-LLVM.
Получается что TPDE-LLVM работает в 2 раза медленнее и результат кода в 2 раза больше, что анонимус выше и написал, а кто-то не смог осилить это))..вот и приходится работать за "кэпа очевидность".
Так минусы не за то что он соврал, а за то что не сказал правду.
> за то что не сказал правду.То есть соврал.
всегда удивляли люди за место "истины" говорящие "правда" :)//ru.wikipedia.org/wiki/Правда
"""
Пра́вда (от праслав. *pravĭda) — фундаментальное понятие русской культуры, сходное с понятием «истина», но в ряде случаев отличающееся от него и даже противопоставляемое.
"""вот откуда ноги растут.
Плохо вы умеете читать. Зачем вы сравниваете черное с кислым? Сравнение идет между TPDE и LLVM в режиме без оптимизаций. И там не в два раза толще а на 20-30% и совсем не медленнее
ну типо в активной фазе разработки и отладки сорость сборки полезна.. итоговый продукт потом собирают с оптимизациями.
Ну то есть по простому, делают быстро, но итоговая программа работает в 2 раза медленней. И занимает в 2 раза больше места.
Вдруг кому то нужно именно такое.
Для быстрой разработки.
Проблема в том, что код без оптимизации будет работать примерно всегда. А вот с оптимизацией не всегда. И опять же левый компилятор это не тот компилятор, который нужен разработчику.
идея чтобы при разработке не ждать по часу каждый билд (а только 30 минут)
когда основная часть написана - можно уже прогнать с оптимизациями и проверить релизный билд
И это ВНЕЗАПНО!(С) - 2 разных компайлера. Всё что ты до этого прогнал на тестовом - выкидываем и начинаем отлаживать на боевом.
Смысл?!?!Впрочем в ойте нынче смысла искать не принято...
> Смысл?!?!Смысл в том, что оно на обоих должно работать корректно.
А шанс что будут различия не такой большой, чтобы ждать столько времени.
Ну как бы есть стандарт. Не можешь писать по стандарту - вон из профессии. К сожалению многие игроделы в нулевых писали не по стандарту. Когда впоследствии исходник с лопаты открыли ради пиара ... внезапно если собрать шлангом, то исчезают ветви, исчезают проверки, причём через несколько уровней вложенности, ибо инлайнинг, в результате use after free и sigsegvы.
Стандарт стандарту рознь. Вон пишешь c89, а потом оказывается, что оптимизатор тебе код интересно соптимизирует и ничего из перечисленного в K&R не работает. Про плюсы лучше не вспоминать.
> Ну как бы есть стандарт. Не можешь писать по стандартуВы походу проектов сложнее хеллоуврота не писали, раз мелите такой бред. В Си со стандартами беда, а про С++ даже говорить не буду, насколько это печаль, особенно если это проект написанный кем-то до тебя.
> вон из профессии
Нейросеть итак скоро заменит всех работников "интеллектуального" труда. Благо это проще и эффективнее. А вот заменить тех, кто работает руками, типа сантехников, автомехаников или сварщиков - в обозримом будущем точно нет.
> Нейросеть итак скоро заменит всех работников "интеллектуального" труда."Вы походу проектов сложнее хеллоуврота не писали..."
> А вот заменить тех, кто работает руками, типа сантехников, автомехаников или сварщиков - в обозримом будущем точно нет.
А их заменят те кого заменила нейросеть.
>а про С++ даже говорить не буду, насколько это печаль, особенно если это проект написанный кем-то до тебя.Особенно если этого "кого-то" (с фамилией, именем, отчеством, адресом проживания и местом работы, а также известной мордой, которая прямо так и просится, чтобы в неё с ноги) вон из профессии надо гнать поганой метлой.
>Нейросеть итак скоро заменит всех работников "интеллектуального" труда
А кто саму нейросеть будет программириовать? Сама нейросеть? Да, она уже. Но саму нейросеть, программирующую нейросеть, которая программирует нейросети тоже кто-то должен программировать. Переходим на более высокий уровень. Я вообще почти не кодю теперь. Вместо этого сижу и объясняю нейросети как создавать промпты, инструктириующие нейросеть кодить то, что мне нужно.
> А кто саму нейросеть будет программириовать?Уж во всяком случае не Вася вaйтишник после курсов на ютyбе.
У Си и С++ стандарт по крайней мере есть.
в играх писать по стандарту было нельзя. там каждый хак со смещением бита на вес золота. эт сейчас оптимизуй не потимизуй всёравно либо продашь либо нет, а как оно играться будет дело уже десятое.
> И это ВНЕЗАПНО!(С) - 2 разных компайлера.местные специалисты вообще не понимают в чем подвох.
Впрочем, сейчас смысл может быть в том чтобы сэкономить на итерациях - скармливать выхлоп ИИ и тыкать пальцем в "некомпилицца ваще" или "тест 2+2=4 failed" по двести раз. К моменту когда оно хотя бы как-то заработает - уже можно брать настоящий компилятор и разбираться что оно там нагуанокодило и как с этим жить.
> сэкономить на итерациях - скармливать выхлоп ИИ и тыкать пальцем в "некомпилицца ваще"ИИ сам это не может сделать? Накой тогда на него мегаватты тратяться?
Интересный подход: пишем на UB-based языках код, который работает не всегда, (т.е. содержит UB), и компилируем без оптимизации.В чем был смысол выбора Си/плюсов? Быстро не будет, оптимизацию же выключили. Почему не выбрать другой язык?
Это будет все равно быстрее питона и джаваскрипта, так что смысл есть.
что насчет linking??
Возможно, этот инструментарий имеет смысл, если нужно запускать недолго живущие маленькие приложения, распространяемые в форме LLVM-IR. Но вообще штука сильно нишевая.
Это ответ на какой вопрос? Кто спрашивает? Затравка для спора? Неоптимизированный код нужен для надёжности приложений, потому что оптимизации могут баги добавлять.
Это для отладки разработки и прочего, не для релиза
Ничего не понятно. Для понимания нужно ядро Linux собрать разными компияторами и с разными оптимизациями. Без GCC никуда.
Без оптимизации нахрен не нужно. Экономия на копейку - упущенных ускорений - на рубль. Всегда собираю с максимальными оптимизациями. Поэтому у меня горячие циклы всего лишь несколько инструкций. Я бы до такого не додумался - а LLVM z3 юзает и находит то, что человек никогда не найдёт. Да, это вычислитеильно дорого. Но не оптимизировать - ещё дороже.
> юзает и находит то, что человек никогда не найдётВы таки не уточнили, что речь идёт о человеке после курсов от ютубных гуру, без профильного computer science образования (ну или просто хотя бы технического).
Вы не осознаете, что у LLVM много применений помимо один раз скомпилировал - запустил много раз.Например RPCS3 (эмулятор PS3) с помощью LLVM прекомпилирует шейдеры, и сейчас это занимает минуты на 8 ядрах. Если это будет занимать секунды, это будет совсем другой экспириенс.
Еще пример - LLVM JIT в PostgreSQL. Пока его применение для планировщика ограниченно именно задержками компиляции. С LLVM быстрее, но плата за его использование велика. Если будет невелика - использовать можно будет куда чаще.
В общем это офигенный проект для тех случаев, когд LLVM используется как динамический рекомпилятор.
В нём зачем-то добавили сборку clang, теперь фпс ниже, бинари больше, а лаги сильнее. Pcsx2 теперь вообще только clang собирается по-моему и собрать отдельный квест как оказалось. Собирается только с кучей неочевидных флагов.
>Например RPCS3 (эмулятор PS3) с помощью LLVM прекомпилирует шейдеры, и сейчас это занимает минуты на 8 ядрах. Если это будет занимать секунды, это будет совсем другой экспириенс.Шейдеры вам нужны постоянно. Уж лучше минуты предкомпиляции и нормальный FPS, чем говняное качество но быстро скомпилировано. Но вы правы в определённом смысле: если бы -O0 от -O3 отличался на 3 десятичных порядка, то имело бы смысл сначала компилить с -O0, а в фоне запускать компиляцию на -O3, и когда готово - заменять. Но только в одном случае - в случае простоя CPU при работе. А это в случаях, когда нужно высокопроизводительное, обычно не так. Поэтому в большинстве случаев имеет смысл сразу компилить на максимуме, а юзер подождёт, потому что во многих случаях важна не столько изначальная задержка, сколько throughput, а задержку при повторном исипользовании можно новелировать, закешириовав результат. Если иархитектура заранее известна - код можно собрать тоже заранее, напр. в OpenCL есть механизм для использования предсобранных ядер.
Запустите gcc первых серсий на своих i9 и вы офигеете от скорости. Будет в миллион раз быстрее. И я даже не говорю о всяких borland turbo c++, которые будут работать со скоростью близкой к скорости света.
ну так ты и запусти. какую версию гцц с какой нужно сравнить конкретно? мне тоже интересно. бенчмарков в сети можно найти много и разных
> Запустите gcc первых серсий на своих i9 и вы офигеете от скорости. Будет в миллион раз
> быстрее.потому что оптимизировать оно умело - примерно - никак. Нет ножек, нет варенья, вроде все логично?
Ну и к тому же непонятно зачем тебе офигенно-быстрый хеловрот, а собрать им скажем линуксное ведро (где скорость уже может иметь значение) у тебя не получится в принципе.
А что за DirectEmit на первой картинке? Т.е. уже было что-то, что работает ± так же и не нужно было ничего изобретать?..
Если попростому, то примерно так:Раньше был только DirectEmit.
Это кастомный бекенд, который по-сути делает тоже что описано в новости.Недостатки DirectEmit:
- в сложности (запутанности и объеме) кода
- в существенном дублировании кода для x86_64 и AARCH64
- но с "множеством мелких ручных правок"Теперь сделали TPDE, который выдаёт столько-же попугаев, но в три раза меньше по объему кода. При этом архитектурно-зависимого кода тоже сильно меньше (почти вдвое).
Но на деле TPDE еще круче именно по простоте/объему кода, так как на самом деле в его коде (который и так в три раза меньше DirectEmit) где-то от 1/2 до 2/3 приходиться на poilerate-подобный код приходиться на интерпретацию/семантику входящего IR-представления получаемого от LLVM.
Как-то так.
Erthink, вы зачем никнейм сменили?
это просто кто-то его адрес написал в email, а сам erthink надулся на какую-то модерацию.
Это все конечно круто.Но решили бы они сначала проблемы количества циклов перезаписи.
"при том же уровне производительности результирующего машинного кода и увеличении размера на 10-30%."640 PB хватит всем. Особенно видеокартам.
Кого колышет производительность бакенда когда код быстрее не становится?
Разработчиков.
Хосподя, насколько упал уровень анонимусов на Оупеннете, что единицы только могут понять для чего это.Это для того чтобы компирировать в цикле разработки. Некоторые очень большие продукты могут компилироваться по часу и более. Я с такими не сталкивался лично, но у нас есть которые компилируются десяток минут.
Сейчас на С/С++ пишут, то что должно работать быстро или очень быстро, а для остального есть более безопасные и удобные языки.
Часто результат при компиляцим без оптимизации бесполезен.
Мда, эх zig мой zig так несмог
— Какая у вас скорость печати?
— 1000 знаков в минуту!
— Так много.
— Правда такая ерунда получается.