The OpenNET Project / Index page

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



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

GCC удалён из основного состава FreeBSD , opennews (??), 03-Мрт-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


1. "GCC удалён из основного состава FreeBSD "  –8 +/
Сообщение от Аноним (1), 03-Мрт-20, 18:42 
Ну это логичный шаг, конечно. Ещё надо из osx все копролиты выкинуть. Кто-нибудь сравнивал, при сборке в гцц-9 попугаев сильно больше?
Ответить | Правка | Наверх | Cообщить модератору

33. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Урри (?), 03-Мрт-20, 19:54 
Для фри не пробовал, для других больших проектов (видеоэнкодер, например) если для дженерика - в границах 5%. Для конкретных процессоров уже несколько больше, но сильно зависит от Венеры и количества осадков.
Ответить | Правка | Наверх | Cообщить модератору

38. "GCC удалён из основного состава FreeBSD "  +2 +/
Сообщение от Аноним (1), 03-Мрт-20, 20:07 
Я тут собрал jq с -O2 -ffast-math -flto и pgo и получил под 40% ускорение на ровном месте. С обычным O3 ускорение не столь значительное и бинарники пухнут, к тому же приходится отключать векторизацию деревьев. В общем, pgo рулит. Так вот, интересно было бы сравнить способности оптимизации.
Ответить | Правка | Наверх | Cообщить модератору

87. "GCC удалён из основного состава FreeBSD "  –5 +/
Сообщение от ALex_hha (ok), 04-Мрт-20, 00:10 
> Я тут собрал jq с -O2 -ffast-math -flto и pgo и получил под 40% ускорение на ровном месте

https://i.imgur.com/N1kPWfi.png

Не ты случаем?

Ответить | Правка | Наверх | Cообщить модератору

89. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (89), 04-Мрт-20, 00:22 
А я изгальнулся собрать фирмвару микроконтроллера с LTO, очень круто вышло, из 6 кило осталось 4. Хоть gcc и багодром в такой конфигурации, конечно.
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

93. "GCC удалён из основного состава FreeBSD "  +1 +/
Сообщение от n80 (?), 04-Мрт-20, 01:09 
Давно и регулярно так делаю, багов пока не видел (кроме тех, которые были вызваны ошибками в коде прошивки, тем же UB, например).
Ответить | Правка | Наверх | Cообщить модератору

96. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (96), 04-Мрт-20, 01:29 
> Давно и регулярно так делаю, багов пока не видел (кроме тех, которые
> были вызваны ошибками в коде прошивки, тем же UB, например).

GCC умеет весьма конкретно прикалываться. Например, втыкая в довольно неожиданных местах вызов memcpy прям в рамках кодогенерации. А у меня его (memcpy) не было - во, блин, фак. Спасибо что compile time error :). И таки это только при определенной оптимизации, с определенным набором команд. И таки известная фигня. Эти разработчики gcc такие затейники...

Алсо, на cortex M почему-то -O3 код от LTO ... распух еще больше. Правда там и от -O3 смысла мизер, пухнет сильно а прибавка маргинальная.

Ответить | Правка | Наверх | Cообщить модератору

138. "GCC удалён из основного состава FreeBSD "  +5 +/
Сообщение от n80 (?), 04-Мрт-20, 14:00 
Вообще-то, это не прикол, это он имеет полное право так делать (например, для инициализации начального значения большой локальной переменной).
См., например, здесь: https://wiki.osdev.org/Meaty_Skeleton

> The GCC documentation explicitly states that libgcc requires the freestanding environment to supply the memcmp, memcpy, memmove, and memset functions, as well as abort on some platforms.

И, конечно же: https://wiki.osdev.org/Libgcc#When_do_I_need_to_link_with_li...
> All code compiled with GCC *must* be linked with libgcc.

Так что тут сугубо документированное поведение.

Далее, от -O3 код конечно-же пухнет, это же оптимизация по скорости, а не по размеру, а многие оптимизации по скорости и по размеру являются взаимоисключающими (особенно сильно это проявляется на том же x86, но и на ARM это видно). Хуже того, -O2 тоже обычно жирнее -Os.

Ответить | Правка | Наверх | Cообщить модератору

176. "GCC удалён из основного состава FreeBSD "  +1 +/
Сообщение от Аноним (176), 04-Мрт-20, 22:09 
> Вообще-то, это не прикол, это он имеет полное право так делать (например,
> для инициализации начального значения большой локальной переменной).

1) "большой" - аж 16 байтов :)
2) Если static const сказать, это и воркэраундит такую "оптимизацию" и делает код меньше.
3) Я по-моему очень доходчиво -ffreestanding сказал, и дополнительно подкрепил nostdlib, no-builtin, nostartfiles и проч, потому что совершенно не желаю чтобы мне в мою фирмвару пытались поумничать через мою голову на кривой козе.
4) В этом тулчейне ... нет либы с реализацией memcpy :). Не, ну я конечно накодил свой, для сравнения code size такого комбо, любопытно было, но я ж вроде сказал явно - это freestanding. С фуя ли вызовы memcpy?

Да еще в случае вот именно LTO gcc'у башню так круто сносит. Вот так он memcpy видит, а вот так видимо грохает как unused, а потом - бдыщ - undefined reference.

Сорь, но от компилера я в такой ситуации ожидаю все же не такое поведение. И более того - если баги gcc копнуть, ЭТО даже чинили. Однако тот свич который заимплементили таки походу другое комбо оптимизаций :D и на мой сценарий никакого эффекта не оказал. Видимо баг вкрался для еще одного комбо опций и это комбо vs freestanding таки не заметили. А с LTO это умеет коллапсировать в довольно глючную спираль.

> to supply the memcmp, memcpy, memmove, and memset functions,

...и в принципе это катит, но с LTO эта скотина умудряется дополнительно поумничать, а потом таки сказать undefined reference, даже если я его и заимплементил, блин :))). И да, нет там никакого libgcc в baremetal тулчейн. И вообще, последнее что я хочу видеть в микроконтроллере это какой-то левый код впертый мне без спросу на кривой козе.

>> All code compiled with GCC *must* be linked with libgcc.

Пожелаю этим умникам напрогать bare metal фирмрварь для микроконтроля а потом умничать.

> Так что тут сугубо документированное поведение.

Это не делает его менее кривым или сколь-нибудь желательным. Даже сами прогеры gcc таки подтвердили в багтрекере на подобный баг что freestanding - вполне явно декларит реквест об отказе от таких навязчивых услуг. Но вот видимо для одного комбо опций это таки пролезло в каком-то другом куске оптимизатора.

> Далее, от -O3 код конечно-же пухнет, это же оптимизация по скорости, а не по размеру,

Просто код пухнет чуть не в разы а прибавка в скорости буквально единицы процентов, очень неудачный tradeoff на МК. Я надеялся что с LTO будет соотношение поинтереснее. А вместо этого код еще распух. Ну и смысла в таком комбо?! :)

Еще там бывает очень странная реакция если компил и линк разнесены в разные фазы, а тулчейн был кросс. Он как-то лихо так "plugin needed to handle object" - и все, болт. Если одним чихом компилять, нормально срабатывает.

> Хуже того, -O2 тоже обычно жирнее -Os.

Да, конечно, жирнее. Но и заметно шустрее. Вот тут разница уже процентов 30 была (в интенсивном алгоритме).

Ответить | Правка | Наверх | Cообщить модератору

196. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от n80 (?), 05-Мрт-20, 14:13 
> 1) "большой" - аж 16 байтов :)

Достаточно большую, чтобы нельзя было сделать одним-двумя mov (или mov + str).

> 2) Если static const сказать, это и воркэраундит такую "оптимизацию" и делает код меньше.

Так ведь это изменение меняет семантику, а компилятор не может оптимизировать в нарушение стандарта, делает строго по документации. Я же, надеюсь, не надо объяснять в чём разница между static и обычными локальными переменными (и что в C слово const работает не так хорошо, как хотелось бы, «спасибо» любителям использовать UB и требовать обратной совместимости)? Так что если там действительно совсем константа, конечно нужно было сразу указывать static const, всегда так делаю.

> 3) Я по-моему очень доходчиво -ffreestanding сказал, и дополнительно подкрепил nostdlib,
> no-builtin, nostartfiles и проч, потому что совершенно не желаю чтобы мне
> в мою фирмвару пытались поумничать через мою голову на кривой козе.

Эх, человек. Со своим инструментом надо если не дружить, то хотя бы сотрудничать на взаимовыгодных условиях. А не сражаться. Не надо так.
То что операции + и * компилятор всё равно реализует — не смущает? Так и нечего тогда переизобретать велосипед. Если всё написано правильно, никакое из этих (документированных!) явлений код раздувать не будет. И сам не будешь тратить время и усилия на велосипедостроение там, где достаточно было почитать документацию. А то сначала думают что умнее, а потом оказывается что в одном месте оптимизировали, а в другом потеряли куда больше из-за того что некогда было подумать над выбором типов, добавлением static и const в нужных местах, алгоритмическими оптимизациями и т.д.

>> to supply the memcmp, memcpy, memmove, and memset functions,
> ...и в принципе это катит, но с LTO эта скотина умудряется дополнительно
> поумничать, а потом таки сказать undefined reference, даже если я его
> и заимплементил, блин :))). И да, нет там никакого libgcc в
> baremetal тулчейн. И вообще, последнее что я хочу видеть в микроконтроллере
> это какой-то левый код впертый мне без спросу на кривой козе.

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

Со всякими mem* функциями вообще весело, где-то их выгоднее вызовом сделать, а где-то даже не заинлайнить, а заменить специфичными именно для этого места инструкциями. Но, насколько понимаю, когда отключаются builtins, такая оптимизация уже не будет работать, конечно.

В общем, сражаться с инструментом — заведомо плохая идея и если есть ощущение что сражаешься, надо читать доку, обычно окажется что решение куда проще, чем казалось, да ещё и тому есть неиллюзорные причины.

Ответить | Правка | Наверх | Cообщить модератору

216. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (-), 07-Мрт-20, 08:05 
> Достаточно большую, чтобы нельзя было сделать одним-двумя mov (или mov + str).

Ну да. Однако memcpy прямо в кодогенерации - достаточно неожиданно, а в микроконтроллере еще и очень так себе сюрприз. А с LTO и вовсе вспрыг на грабли.

> Так ведь это изменение меняет семантику,

Однако если уж он так хотел адски поумничать, мог бы, чтоли, заметить что это переменная с локальной видимостью в функции, используемая только readonly, которую никто нигде никак больше не использует и сам задемотить ее до static const, чтоли...

> а компилятор не может оптимизировать в нарушение стандарта,

Ну вообще-то если хочется чтобы совсем вот так, полагается "volatile" сказать. Некоторые вещи компилер имеет право не заметить. Ну например он не знает что обработчик IRQ или хардварного exception кто-то (железо) ВНЕЗАПНО вызывает.

> делает строго по документации.

Если уж мы об этом, запрос freestanding клещится с идеей влупить memcpy. И прямо на уровне стандарта C99 вроде даже, там удосужились сие явно регламентировать.

> «спасибо» любителям использовать UB и требовать обратной совместимости)?

Не очень понимаю этот реверанс. Воткнуть memcpy в freestanding окружении - и правда UB, потому что его там быть не обязано. Проблема в том что это сделал не я а компилер...

> Так что если там действительно совсем константа, конечно нужно было сразу
> указывать static const, всегда так делаю.

Что однако не извиняет ВНЕЗАПНЫЙ memcpy в freestanding окружении. Но это было бы полбеды, еще половина - в том как это с LTO умеет взаимодействовать :)

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

Да на самом деле я с ним и дружу. В МК с ним приходится оооочень плотно знакомиться, там начальная раскрутка окружения (да, я написал себе "стартап", прямо на си) и чудеса линкерным скриптом, и даже Очень Странные Макросы. Но когда меня дернул черт LTO попробовать - я таки отхватил вот приключений, явно больше чем ожидал :)

> То что операции + и * компилятор всё равно реализует — не смущает?

Он это реализует только очень местами - в лучшем случае это как раз таки лобовые ассемблерные команды, что-нибудь типа ADD и MUL.

> никакое из этих (документированных!) явлений код раздувать не будет.

Код распух когда -O3 пущен с LTO. Обычно LTO убавляет размер, но в случае -O3 вышло наоборот. Почитав как это работает - там у LTO какое-то довольно сложное взаимодействие, так что в каких-то отдельных случаях он так и правда может. И даже есть какие-то более fine-graned опции тюнинга оптимизаций, подозреваю что ими можно попробовать повертеть. Но меня устроило -O2+LTO если мне "быстро" и -Os+LTO если "место жмет".

> было почитать документацию.

Документация на LTO, кстати, довольно средненькая и лаконичная. Хоят общее понимание процесса дает, но в целом LTO в GCC та еще камасутра, имхо.

> больше из-за того что некогда было подумать над выбором типов, добавлением
> static и const в нужных местах, алгоритмическими оптимизациями и т.д.

Так компилер и не умничал, до тех пор пока я не попробовал посмотреть а какой вообще минимально можно код. Я сменил набор команд и врубил LTO. А он и взбрыкни с undefined reference, и даже если memcpy дать.

> Так ведь такое дело, что это код не более левый, чем весь
> остальной сгенерированный компилятором.

Как бы это сказать? Ну если вы господа умники уж втыкаете референс на memcpy - тогда, хотя-бы, врубите мозг и не optimize out его реализацию, не?! А то как я его provide'ить должен? :)

> можно было сделать красивее, но знали б где упадут — соломки подстелили.

Можно было уважить стандарт и не фигарить в freestanding окружение такие клюки. А если уж так сильно хочется - ну, ладно, а зачем тогда мой memcpy выпиливать и потом жаловаться? Я еще должен явно хинтить что он used, при том что компилер сам его used? В общем он сам себя надул :)

> инструкциями. Но, насколько понимаю, когда отключаются builtins, такая оптимизация уже
> не будет работать, конечно.

И более того - в МК работа с памятью довольно деликатная штука и такие выходки могут отобрать у меня контроль над происходящим до того как все инициализировано. Обгадив весь компот. Я чо, на асме стартап должен писать? Да ну в пень?! Половина фич Cortex M в том что его можно с места в карьер сями пнуть, без асма.

> В общем, сражаться с инструментом — заведомо плохая идея и если есть
> ощущение что сражаешься, надо читать доку, обычно окажется что решение куда
> проще, чем казалось, да ещё и тому есть неиллюзорные причины.

Я примерно так и сделал, и все же имею заметить что LTO может подкинуть сюрпризов в упомянутом случае.

p.s. да вы не бойтесь, на шланге я вообще не возьмусь такие пируэты откалывать и там наверняка не меньше приколов зарыто... :)

Ответить | Правка | Наверх | Cообщить модератору

190. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (190), 05-Мрт-20, 08:58 
> All code compiled with GCC *must* be linked with libgcc

Хм... При любых флагах и опциях евойной командной строки?

Ответить | Правка | К родителю #138 | Наверх | Cообщить модератору

195. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от n80 (?), 05-Мрт-20, 13:48 
Да, при любых. В некоторых случаях она не используется, но тогда от линковки с ней ничего в коде и не прирастёт (в общем-то, почти всегда так и есть).

Откуда уши растут: иногда возникает необходимость добавить в код целые функции, например, для деления на архитектурах, где для нет такой инструкции (или для работы с long long на 32-битных архитектурах). Авторы GCC могли добавить особые случаи на уровне кодогенератора и линковщика чтобы реализация этих функций подставлялась молча и без указания флагов, но не захотели плодить костыли и делать протекающие абстракции, потому и просто воспользовались штатной функциональностью линковщика, вынеся такие функции в отдельную статическую либу.

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

Ответить | Правка | Наверх | Cообщить модератору

211. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (211), 06-Мрт-20, 03:15 
> Хм... При любых флагах и опциях евойной командной строки?

Теоретически, он не должен так делать при freestanding. Практически - возможны варианты, так что memcpy/memset/memmove он может все же возжелать при определенных уровнях оптимизации.

Ответить | Правка | К родителю #190 | Наверх | Cообщить модератору

156. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от кто пчелок уважает (?), 04-Мрт-20, 17:05 
а что не так с ftree-vectorize?
Ответить | Правка | К родителю #38 | Наверх | Cообщить модератору

185. "GCC удалён из основного состава FreeBSD "  +/
Сообщение от Аноним (1), 05-Мрт-20, 02:00 
Компилятор может быть быть неожиданно тупым и генерировать совсем не то и не там, в результате всё очень плохо. Я всё мечтаю заценить векторизацию в ICC (интеловский компилятор и либы), говорят, что ему лучше всего она удаётся (когда удаётся).
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




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

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