После шести месяцев разработки представлен релиз проекта LLVM 12.0 - GCC-совместимого инструментария (компиляторы, оптимизаторы и генераторы кода), компилирующего программы в промежуточный биткод RISC-подобных виртуальных инструкций (низкоуровневая виртуальная машина с многоуровневой системой оптимизаций). Сгенерированный псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54977
Атрибут optimize ещё не прикрутили?
Да вроде давно
В упор не наблюдаю https://clang.llvm.org/docs/AttributeReference.html Где?
А что там нынче с поддержкой плюсовых модулей?
Ещё с 9 есть. Только в CMake их поддержки не завезли, придётся самому валандаться с аттрибутами коммандной строки. А мы ведь системы сборки для того и используем, чтобы с ними за нас валандалась система сборки. Поэтому, пока в системы сборок поддержку модулей не завезут, прок от использования модулей будет отрицательным.
В build2 (https://build2.org/) давно завезли (не путать с бустовым b2).
Это что-то совсем уж маздайное, начиная с способов даунлоада и "секурити" в виде SHA256 (Подписи GPG?! Не, не слышали!) и поддерживает аж полторы конфигурации. Из которых примерно 3/4 - маздайка. Которая мне например как таргет не интересна вообще. Так что убийцы cmake из этой штуки явно не вырисовывается. Маздайный апстрим == trouble on the way.
Разработчики пользуются то ли маком, то ли линуксом (возможно, и тем и другим). Бинарные пакеты build2 есть под большинство дистрибутивов Linux - Ubuntu/Debian, Fedora, RedHat/CentOS, вроде есть под Arch и Gentoo (под винду и мак, кстати, вроде нет). Правда, все они неофициальные, потому что официальный способ - собирать из исходников, но бинарные пакеты стабильно поддерживаются и ссылки есть на официальном сайте. Build2 поддерживает сборку приложений под Linux, Win, Mac, FreeBSD, причем даже в своем CI.Ты, похоже, про какой-то не тот build2 пишешь.
build2 для программ без сторонних библиотек (хеллоу ворлдов), потому как все сторонние библиотеки ориентированы на CMake
> А что там нынче с поддержкой плюсовых модулей?Плохо, пока нет ни одного компилятора, который их поддерживает в полной мере.
> На системах x86 включена поддержка опции "-mtune=<cpu>"Дааа..... Когда же они тогда весь GCC перепишут?!
Что там с модулями? Как их заставить работать с Xcode?
Никак.
А жаль.
> Реализована и включена по умолчанию поддержка предложенных в стандарте C++20 атрибутов "likely" и "unlikely", позволяющих информировать оптимизатор о вероятности срабатывания условной конструкцииА "highly likely" почему не добавили?
Ты хочешь сказать, что русские хакеры могут вмешаться в исход условного оператора if???
С точки зрения ламера есть несколько вариантов (в нотации ASM х86):
- поменять условный переход на безусловный по тому же адресу: JZ => JMP;
- поменять логику перехода сохранив адрес перехода: JZ => JNZ;
- исключить проверку и переход вообще: J(x) => NOP;
- наверняка, существуют и другие способы "вмешательства в исход условного оператора", известные хакерам безотносительно их национальной принадлежности.imho
Лови русского(советского?) хакера!
С гцц оно существует с какого года? С 2000?
Вы путаете аттрибуты стандарта C++ и аттрибуты поддерживаемые компилятором.
А есть разница на результирующий код? Или ты из секты синтаксической соли?
Ну с сишного register есть, причём ради интереса замерял простенький цикл со счётчиком и ускорение было в 10000 раз. По факту приложение в итоге начало отрабатывать в 1000 раз быстрее. А видишь из плюсов выкинули.
Ой, всё...
> Ой, всё...Хорошая новость: пго этот цикл тоже соптимизировал, даже ещё лучше. Плохая: без пго единственная надежда на такие подсказки от кодера.
Что вы там вообще делали? Простой цикл со счетчиком gcc например обычно випилывает до условного return 42, заметив что эффекта от цикла ровно ноль и на этой почве вообще грохнув весь этот код. Так что скорость получается в дофига раз больше - кода вообще нет.Более того - он умеет в сильно более продвинутый анализ. Если есть 10 веток функции для разных значений параметров, сцук замечает что 80% этого unused (если оно так) - и выпиливает к чертям код реализации.
Цикл не был пустым естественно, он был динамическим и зависел от внешних данных (с диска). Просто переменная счётчика не попадала в регистры процессора из-за чего ощутимо падала производительность.
По состоянию на *сейчас* register как правило не дает совсем никакого эффекта. Компилер и так допрет загнать "горячие" вещи в регистры, покуда их хватает. Собственно поэтому его и убрали...Ну или давайте конкретный пример
- Конфигурации. Компилер, ось, проц, опции.
- Кода где от register есть какой-то толк. Я проверю.Интерес потому что я пробовал так и сяк и вообще разницу в кодогенерации (как минимум на ARM) так сразу получить не смог.
Это был gcc7 linux amd64 проц какой-то тех лет от интела, O2 и native. Разница в кодогенерации была, и была разница в производительности. Кода у меня нет, там было что-то банальное типа for(int i;i<100500;++i) компилятор не стал это оптимизировать и счётчик в регистры не назначался.
С++20 все еще не полностью поддерживается
Да и ладно. А что там gcc выступал? Вот на сабжа и заменим.
Сабж не выступал против Столмана потому, что он и так под пятой у проприерастов, а не под руководством FSF.
gcc не выступал и не может так его пилит проект GNU которым столман управляет.
а вот llvm выступить может.
Нет. GCC не выступил потому, что они преданные соратники Столлмана.
> Нет. GCC не выступил потому, что они преданные соратники Столлмана.Кем именно преданные? Столлманом?
> gcc не выступал и не может так его пилит проект GNU которым
> столман управляет.
> а вот llvm выступить может.если кто то сомневаеться: https://ru.wikipedia.org/wiki/GNU_Compiler_Collection
> Разработчик Проект GNUа лидер проекта gnu - столман
поэтому столман не может выступить сам против себя (раздвоения личности у него вроде нету)
Ты GNU c FSF не попутал?
> Ты GNU c FSF не попутал?нет.
fsf тут причем? да, сора из за него, но проектом GNU тоже руководит столман
> С++20 все еще не полностью поддерживаетсяC++ is dead
AVX512 то еще говно по слвоам Линуса. AVX2 уже давно есть. -march=native решает трудности выбора нужных инструкций. Но можно выключить ненужное, для чего и есть уровни 3 и 2.
На локалхосте у себя под одеялом собирать не вопрос конечно. Но распространять такие бинари бессмысленно.
> "likely" и "unlikely"Надо ещё "highly likely" и "highly unlikely", а лучше - всю шкалу от "nearly impossible" до "almost certain".
От "да ни в жисть" до "мамой клянусь".
Ну это вам язык РАПИРА надо. Еще можно б#% буду! добавить. Хотя в принципе одно время такой синтаксис катитл и в MSовском сишном компилере, загуглить про "какой-то козел стал гoвнистость". Но это нестандарт, другие компилеры не жрут.
Есть поддержка D?
D там отдельно, LDC называется.
Тогда нужно
likely, unlikely ...
Глупости все это -- управление предвыборкой. Не все платформы умеют это делать. ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты эффективно обработать.
Самый действенный метод повысить призводительность вычислений -- писать всю математику на фортране или прямо на ассемблере платформы.
А если это не математика, а какой-нибудь обработчик событий в GUI? Тоже на фортране или ассемблере писать?
> обработчик событий в GUIВот уж кому не впёрлись все эти лайки.
Причём тут, блин, математика?Вот есть у меня код разбора протокола http. Если первый символ G, то очень даже likely, что второй E, а третий T.
И причём тут лайки, если ты уже сам составил дерево разбора так, как надо?!
В условии if-else две ветки выполнения. Для компилятора они равновероятны.
Если не повезёт, в коротком цикле окажется сброс конвейера.На пример с GET, возможен сброс после каждого символа.
Тебе не повезло с процом, если он у тебя конвейер сбрасывает. Процы уже давно спекулятивно исполняют обе ветки после ветвления, отбрасывая потом ненужную уже фоном. Это появилось вскоре, как сделали переименовку регистров.
Такой ерундой страдал 4-ый пень, и грелся аж песец.
Новые процы спекулятивно выполняют только одну ветку.
Или ведут статистику переходов, ака динамическое предсказание, или эвристика... типа к младшим адресам значит цикл, к старшим значит переход маловероятен.
В общем пользуй PGO либо ставь атрибуты.
Не умеют и не умеют, в чём проблема-то?
> likely, unlikely ...
> Глупости все это -- управление предвыборкой. Не все платформы умеют это делать.
> ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты
> эффективно обработать.
> Самый действенный метод повысить призводительность вычислений -- писать всю математику
> на фортране или прямо на ассемблере платформы.При чём тут предвыборка вообще?
Например в каком-то маловероятном случае может требоваться крупный массив.
// ...
if(content_coded) [[unlikely]] {
int buffer[16*1024*1024];
/* decode content */
}
return content[0];
// :-)Ну вот. Без unlikely оптимизирующий компилятор может резервировать память под buffer каждый раз при вызове функции (ещё до проверки чего-либо). Также может влиять на inlining...
> На платформе Linux для архитектур AArch64 и PowerPC включён режим
> "-fasynchronous-unwind-tables" для генерации "раскрученных"
> (unwind) таблиц вызовов, как в GCC.Поправьте пожалуйста перевод.
"unwind tables" это таблицы для раскрутки стека, а не "раскрученные" таблицы. Асинхронные таблицы раскрутки стека позволяют раскручивать стек в любой точке (на любой инструкции), а не только в точках вызова функций.
>Релиз набора компиляторов LLVM 12.0Он даже название GCC копируют. Типа: "набора компиляторов".
> поддержкой OpenCL, OpenMP и CUDA. Добавлены опции "-cl-std=CL3.0" и "-cl-std=CL1.0"OpenCL у писателей дров к видяхам на самом последнем месте: https://mesamatrix.net
Хотя бы для видях AMD сделали полную поддержку "-cl-std=CL1.2"
Это такой намёк "берите nvidia и блоб", сама nvidia использует наработки llvm в той же cuda.
На FreeBSD сейчас обязательно присутствует ТРИ версии LLVM: системный, LLVM 10.0 для mesa-dri, LLVM 11.0 для Firefox и Thunderbird. И ещё LLVM 9.0 и GCC 10 для сборки чего-то там используется, но это не считается - их можно удалить по окончании сборки.Вот такой вот "зоопарк" версий, как у MS .Net в своё время.