|
2.21, Аноним (21), 14:05, 16/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Ещё с 9 есть. Только в CMake их поддержки не завезли, придётся самому валандаться с аттрибутами коммандной строки. А мы ведь системы сборки для того и используем, чтобы с ними за нас валандалась система сборки. Поэтому, пока в системы сборок поддержку модулей не завезут, прок от использования модулей будет отрицательным.
| |
|
|
4.54, Аноним (-), 10:44, 17/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Это что-то совсем уж маздайное, начиная с способов даунлоада и "секурити" в виде SHA256 (Подписи GPG?! Не, не слышали!) и поддерживает аж полторы конфигурации. Из которых примерно 3/4 - маздайка. Которая мне например как таргет не интересна вообще. Так что убийцы cmake из этой штуки явно не вырисовывается. Маздайный апстрим == trouble on the way.
| |
|
5.68, Аноним (68), 23:29, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Разработчики пользуются то ли маком, то ли линуксом (возможно, и тем и другим). Бинарные пакеты build2 есть под большинство дистрибутивов Linux - Ubuntu/Debian, Fedora, RedHat/CentOS, вроде есть под Arch и Gentoo (под винду и мак, кстати, вроде нет). Правда, все они неофициальные, потому что официальный способ - собирать из исходников, но бинарные пакеты стабильно поддерживаются и ссылки есть на официальном сайте. Build2 поддерживает сборку приложений под Linux, Win, Mac, FreeBSD, причем даже в своем CI.
Ты, похоже, про какой-то не тот build2 пишешь.
| |
|
4.69, Аноним (69), 02:40, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
build2 для программ без сторонних библиотек (хеллоу ворлдов), потому как все сторонние библиотеки ориентированы на CMake
| |
|
|
|
1.3, Аноним (3), 12:48, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –5 +/– |
> На системах x86 включена поддержка опции "-mtune=<cpu>"
Дааа..... Когда же они тогда весь GCC перепишут?!
| |
1.10, Анонас (?), 13:00, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +18 +/– |
> Реализована и включена по умолчанию поддержка предложенных в стандарте C++20 атрибутов "likely" и "unlikely", позволяющих информировать оптимизатор о вероятности срабатывания условной конструкции
А "highly likely" почему не добавили?
| |
|
2.12, anonymous (??), 13:15, 16/04/2021 [^] [^^] [^^^] [ответить]
| +5 +/– |
Ты хочешь сказать, что русские хакеры могут вмешаться в исход условного оператора if???
| |
|
3.30, ng (?), 15:21, 16/04/2021 [^] [^^] [^^^] [ответить]
| +4 +/– |
С точки зрения ламера есть несколько вариантов (в нотации ASM х86):
- поменять условный переход на безусловный по тому же адресу: JZ => JMP;
- поменять логику перехода сохранив адрес перехода: JZ => JNZ;
- исключить проверку и переход вообще: J(x) => NOP;
- наверняка, существуют и другие способы "вмешательства в исход условного оператора", известные хакерам безотносительно их национальной принадлежности.
imho
| |
|
|
3.18, жопка3 (?), 13:43, 16/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Вы путаете аттрибуты стандарта C++ и аттрибуты поддерживаемые компилятором.
| |
|
4.24, Аноним (3), 14:20, 16/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
А есть разница на результирующий код? Или ты из секты синтаксической соли?
| |
|
5.26, Аноним (26), 14:47, 16/04/2021 [^] [^^] [^^^] [ответить]
| –2 +/– |
Ну с сишного register есть, причём ради интереса замерял простенький цикл со счётчиком и ускорение было в 10000 раз. По факту приложение в итоге начало отрабатывать в 1000 раз быстрее. А видишь из плюсов выкинули.
| |
|
|
7.32, Аноним (26), 15:42, 16/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Ой, всё...
Хорошая новость: пго этот цикл тоже соптимизировал, даже ещё лучше. Плохая: без пго единственная надежда на такие подсказки от кодера.
| |
|
8.57, Аноним (-), 10:59, 17/04/2021 [^] [^^] [^^^] [ответить] | +/– | Что вы там вообще делали Простой цикл со счетчиком gcc например обычно випилыва... текст свёрнут, показать | |
|
9.65, Аноним (26), 19:28, 17/04/2021 [^] [^^] [^^^] [ответить] | +/– | Цикл не был пустым естественно, он был динамическим и зависел от внешних данных ... текст свёрнут, показать | |
|
|
|
6.55, Аноним (-), 10:49, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
По состоянию на *сейчас* register как правило не дает совсем никакого эффекта. Компилер и так допрет загнать "горячие" вещи в регистры, покуда их хватает. Собственно поэтому его и убрали...
Ну или давайте конкретный пример
- Конфигурации. Компилер, ось, проц, опции.
- Кода где от register есть какой-то толк. Я проверю.
Интерес потому что я пробовал так и сяк и вообще разницу в кодогенерации (как минимум на ARM) так сразу получить не смог.
| |
|
7.64, Аноним (26), 19:26, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Это был gcc7 linux amd64 проц какой-то тех лет от интела, O2 и native. Разница в кодогенерации была, и была разница в производительности. Кода у меня нет, там было что-то банальное типа for(int i;i<100500;++i) компилятор не стал это оптимизировать и счётчик в регистры не назначался.
| |
|
|
|
|
|
|
|
|
3.31, Аноним (31), 15:31, 16/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
Сабж не выступал против Столмана потому, что он и так под пятой у проприерастов, а не под руководством FSF.
| |
3.42, макпыф (ok), 18:05, 16/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
gcc не выступал и не может так его пилит проект GNU которым столман управляет.
а вот llvm выступить может.
| |
|
4.47, Аноним (-), 19:18, 16/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Нет. GCC не выступил потому, что они преданные соратники Столлмана.
| |
|
5.48, Аноним (-), 19:24, 16/04/2021 [^] [^^] [^^^] [ответить]
| –8 +/– |
> Нет. GCC не выступил потому, что они преданные соратники Столлмана.
Кем именно преданные? Столлманом?
| |
|
4.51, макпыф (ok), 22:10, 16/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> gcc не выступал и не может так его пилит проект GNU которым
> столман управляет.
> а вот llvm выступить может.
если кто то сомневаеться: https://ru.wikipedia.org/wiki/GNU_Compiler_Collection
> Разработчик Проект GNU
а лидер проекта gnu - столман
поэтому столман не может выступить сам против себя (раздвоения личности у него вроде нету)
| |
|
|
6.60, макпыф (ok), 16:26, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> Ты GNU c FSF не попутал?
нет.
fsf тут причем? да, сора из за него, но проектом GNU тоже руководит столман
| |
|
|
|
|
|
1.25, Аноним (25), 14:41, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
AVX512 то еще говно по слвоам Линуса. AVX2 уже давно есть. -march=native решает трудности выбора нужных инструкций. Но можно выключить ненужное, для чего и есть уровни 3 и 2.
| |
|
2.61, Аноним (58), 16:28, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
На локалхосте у себя под одеялом собирать не вопрос конечно. Но распространять такие бинари бессмысленно.
| |
|
1.27, YetAnotherOnanym (ok), 15:16, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> "likely" и "unlikely"
Надо ещё "highly likely" и "highly unlikely", а лучше - всю шкалу от "nearly impossible" до "almost certain".
| |
|
|
3.56, Аноним (-), 10:52, 17/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну это вам язык РАПИРА надо. Еще можно б#% буду! добавить. Хотя в принципе одно время такой синтаксис катитл и в MSовском сишном компилере, загуглить про "какой-то козел стал гoвнистость". Но это нестандарт, другие компилеры не жрут.
| |
|
|
1.35, adolfus (ok), 16:05, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
likely, unlikely ...
Глупости все это -- управление предвыборкой. Не все платформы умеют это делать. ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты эффективно обработать.
Самый действенный метод повысить призводительность вычислений -- писать всю математику на фортране или прямо на ассемблере платформы.
| |
|
2.37, Твой батя (?), 16:45, 16/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
А если это не математика, а какой-нибудь обработчик событий в GUI? Тоже на фортране или ассемблере писать?
| |
|
3.44, Аноним (3), 18:10, 16/04/2021 [^] [^^] [^^^] [ответить]
| +1 +/– |
> обработчик событий в GUI
Вот уж кому не впёрлись все эти лайки.
| |
|
2.41, Аноним (41), 18:00, 16/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Причём тут, блин, математика?
Вот есть у меня код разбора протокола http. Если первый символ G, то очень даже likely, что второй E, а третий T.
| |
|
3.45, Аноним (3), 18:12, 16/04/2021 [^] [^^] [^^^] [ответить]
| +2 +/– |
И причём тут лайки, если ты уже сам составил дерево разбора так, как надо?!
| |
|
4.63, Tim (??), 19:01, 17/04/2021 [^] [^^] [^^^] [ответить]
| –1 +/– |
В условии if-else две ветки выполнения. Для компилятора они равновероятны.
Если не повезёт, в коротком цикле окажется сброс конвейера.
На пример с GET, возможен сброс после каждого символа.
| |
|
5.66, Аноним (3), 20:00, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Тебе не повезло с процом, если он у тебя конвейер сбрасывает. Процы уже давно спекулятивно исполняют обе ветки после ветвления, отбрасывая потом ненужную уже фоном. Это появилось вскоре, как сделали переименовку регистров.
| |
|
6.71, Tim (??), 07:47, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Такой ерундой страдал 4-ый пень, и грелся аж песец.
Новые процы спекулятивно выполняют только одну ветку.
Или ведут статистику переходов, ака динамическое предсказание, или эвристика... типа к младшим адресам значит цикл, к старшим значит переход маловероятен.
В общем пользуй PGO либо ставь атрибуты.
| |
|
|
|
|
2.72, Алкоголик Анон (?), 18:02, 18/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
> likely, unlikely ...
> Глупости все это -- управление предвыборкой. Не все платформы умеют это делать.
> ia32 и amd64 в подявляющем большинстве случаев не могут эти хинты
> эффективно обработать.
> Самый действенный метод повысить призводительность вычислений -- писать всю математику
> на фортране или прямо на ассемблере платформы.
При чём тут предвыборка вообще?
Например в каком-то маловероятном случае может требоваться крупный массив.
// ...
if(content_coded) [[unlikely]] {
int buffer[16*1024*1024];
/* decode content */
}
return content[0];
// :-)
Ну вот. Без unlikely оптимизирующий компилятор может резервировать память под buffer каждый раз при вызове функции (ещё до проверки чего-либо). Также может влиять на inlining...
| |
|
1.46, Иван (??), 18:18, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> На платформе Linux для архитектур AArch64 и PowerPC включён режим
> "-fasynchronous-unwind-tables" для генерации "раскрученных"
> (unwind) таблиц вызовов, как в GCC.
Поправьте пожалуйста перевод.
"unwind tables" это таблицы для раскрутки стека, а не "раскрученные" таблицы. Асинхронные таблицы раскрутки стека позволяют раскручивать стек в любой точке (на любой инструкции), а не только в точках вызова функций.
| |
1.49, Аноним (-), 19:39, 16/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Релиз набора компиляторов LLVM 12.0
Он даже название GCC копируют. Типа: "набора компиляторов".
| |
1.53, Аноним (53), 09:52, 17/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
> поддержкой OpenCL, OpenMP и CUDA. Добавлены опции "-cl-std=CL3.0" и "-cl-std=CL1.0"
OpenCL у писателей дров к видяхам на самом последнем месте: https://mesamatrix.net
Хотя бы для видях AMD сделали полную поддержку "-cl-std=CL1.2"
| |
|
2.67, Аноним (26), 20:45, 17/04/2021 [^] [^^] [^^^] [ответить]
| +/– |
Это такой намёк "берите nvidia и блоб", сама nvidia использует наработки llvm в той же cuda.
| |
|
1.73, iZEN (ok), 18:43, 20/04/2021 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
На FreeBSD сейчас обязательно присутствует ТРИ версии LLVM: системный, LLVM 10.0 для mesa-dri, LLVM 11.0 для Firefox и Thunderbird. И ещё LLVM 9.0 и GCC 10 для сборки чего-то там используется, но это не считается - их можно удалить по окончании сборки.
Вот такой вот "зоопарк" версий, как у MS .Net в своё время.
| |
|