LINUX.ORG.RU

GCC vs Clang.

 , , , ,


1

3

Собираю значит Chromium как обычно с Clang,а он глючит. Пробую собрать с GCC, а ему GCC 16 ГБ становится мало. Делаю сборку в 3 потока, всё равно мало. Пришлось выключить X и собирать в терминале.
К чему это всё? А к тому, что собирая Chromium Clang'ом в 9 потоков на 16 ГБ оперативы, можно запустить браузер и лазить по инету. А при сборке с GCC отрубать всё, что запущено, и собирать только в 3 потока.
З.Ы. Вот тебе и оптимизация под определённый компилятор.

★★★★★

А разве не выпилили в последних версиях хрома возможность сборки GCC? Я помню, у меня бомбило знатно.

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки. И с чего бы сборка в три потока должна кушать меньше памяти чем в один?

eternal_sorrow ★★★★★ ()
Ответ на: комментарий от eternal_sorrow

А разве не выпилили в последних версиях хрома возможность сборки GCC?

в Дженте собирается, и работает.

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки.

Фича в том, что в Clang всегда включён ThinLTO, а с GCC собиралось без LTO.

И с чего бы сборка в три потока должна кушать меньше памяти чем в один?

А разве не должна?.

Lifun ★★★★★ ()
Ответ на: комментарий от DELIRIUM

Пробую собрать с GCC, а ему GCC 16 ГБ становится мало

Ну заведи баг на gcc, или тебе тупо поныть надо?

Помню, был баг про прожорливость на багтрекере. Заведен на какую-то из перых версий 5.х

anonymous ()
Ответ на: комментарий от anonymous

Лто у гцц перманентно жрёт сотни гигабайт на новых версиях, типа более эффективные оптимизации дооптимизировывают до сотен гигов.

Хотя в 8.2 вроде исправили, ну всё как обычно. Или у него 9? Первая версия всегда сырая.

anonymous ()
Ответ на: комментарий от anonymous

LTO там не причем (в баге). И насколько помню даже тип исходника (си или си++) не причем. Просто gcc стал резко прожорлив. Вроде, в 5.x перешли на с++, также добавили всякие разные оптимизаторы на графитах.

anonymous ()
Ответ на: комментарий от anonymous

Насколько я помню, внезапная прожорливость была связана именно с лто и линкером — жирнолис внезапно стал в 4 раза больше потреблять на сборке (при том что лто и так жрал слишком много). Потом это всё исправляли.

Возможно мы про разные версии думаем.

anonymous ()

Пробую собрать с GCC, а ему GCC 16 ГБ становится мало.

Ну это не новость.

Делаю сборку в 3 потока, всё равно мало.

Попробуй без -pipe
А своп религия не позволяет?

madcore ★★★★★ ()
Ответ на: комментарий от EXL

Ага, засвопилось бы 10+ гигов, которое обратно в память вернулось бы и возобновило компиляцию только через полчаса (это если своп на ssd, на hdd - вообще сутки).

anonymous ()
Ответ на: комментарий от Lifun

либо в мало потоков, либо отключать jumbo-build.

Ну так пропатчи ninja, чтоб следила за /proc/meminfo:MemAvailable и не запускала задачу, если мало. Заодно make. И будет тебе мало потоков, когда нужно.

anonymous ()

ты раз в полгода создаёшь подобный тред, и каждый раз тебе говорят нафига его собирать и раз в полгода ты отвечаешь — потому что я компилю все подряд. /thread

я понимаю фф компилить из-за фичастых custom-optimization, а смысл юзать хромимум если все равно заходишь под акком гугла, который сливает все и вся, если боишься зондов фф, если не боишься то хром-bin.

deity ★★★ ()
Ответ на: комментарий от eternal_sorrow

А по поводу памяти, так в GCC опитимизация результата лучше, а все эти плюшки кушают память в процессе сборки

С какого это боку? Тесты разработчиков Хромого и Лисы говорят об обратном.

Lifun ★★★★★ ()
Ответ на: комментарий от Lifun

Предлагаю взять какой-нибудь бенч на CXX и собрать его gcc с -O3, lto и pgo. Ну и его же собрать шлангом с теми же lto и pgo. Проверить командой time на машине без иксов и прочей фоновой хрени.

Вот это будет тест, а этот бложек - сомнительное доказательство превосходства clang.

ArkaDOSik ()
Ответ на: комментарий от Lifun

it seemed a better deal to switch to clang than to try to address those issues.

Как-то вообще печально с этими ребятами. gcc 6 далеко не самый лучший вариант, но свежий gcc они заюзать не могут, так как код кривой. А проще компилятор поменять, чем код починить.

И для юзания lto под шлангом врубили везде pie, который оптимизациям мешает.

Bfgeshka ★★★★★ ()
Ответ на: комментарий от alexferman

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

ArkaDOSik ()
Ответ на: комментарий от eternal_sorrow

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

Lifun ★★★★★ ()
Ответ на: комментарий от Bfgeshka

нет, везде.

2017-11-30-new-17-profiles
  Title                     New 17.0 profiles in the Gentoo repository
  Author                    Andreas K. Hüttel <dilfridge@gentoo.org>
  Posted                    2017-11-30
  Revision                  1

We have just added (for all arches except arm and mips, these follow
later) a new set of profiles with release version 17.0 to the Gentoo 
repository. These bring three changes:
1) The default C++ language version for applications is now C++14.
   This change is mostly relevant to Gentoo developers. It also
   means, however, that compilers earlier than GCC 6 are masked 
   and not supported for use as a system compiler anymore. Feel 
   free to unmask them if you need them for specific applications.
2) Where supported, GCC will now build position-independent
   executables (PIE) by default. This improves the overall
   security fingerprint. The switch from non-PIE to PIE binaries,
   however, requires some steps by users, as detailed below.
3) Up to now, hardened profiles were separate from the default
   profile tree. Now they are moving into the 17.0 profile
   as a feature there, similar to "no-multilib" and "systemd".

Please migrate away from the 13.0 profiles within the six weeks after
GCC 6.4.0 has been stabilized on your architecture. The 13.0 profiles
will be deprecated then and removed in half a year.

If you are not already running a hardened setup with PIE enabled, then
switching the profile involves the following steps: 
If not already done,
* Use gcc-config to select gcc-6.4.0 or later as system compiler
* Re-source /etc/profile:
    . /etc/profile
* Re-emerge libtool
    emerge -1 sys-devel/libtool
Then, 
* Select the new profile with eselect
* Re-emerge, in this sequence, gcc, binutils, and glibc
    emerge -1 sys-devel/gcc:6.4.0
    emerge -1 sys-devel/binutils
    emerge -1 sys-libs/glibc
* Rebuild your entire system
    emerge -e @world

Switching the profile from 13.0 to 17.0 modifies the settings of 
GCC 6 to generate PIE executables by default; thus, you need to do 
the rebuilds even if you have already used GCC 6 beforehand.
If you do not follow these steps you may get spurious build
failures when the linker tries unsuccessfully to combine non-PIE
and PIE code.
[ebuild   R    ] sys-devel/gcc-8.2.0-r5:8.2.0::gentoo  USE="cxx graphite nls nptl openmp pch pgo (pie) (-altivec) -debug -doc (-fixed-point) -fortran -go (-hardened) (-jit) (-libssp) -mpx (-multilib) -objc -objc++ -objc-gc -regression-test -sanitize -ssp -systemtap -vanilla -vtv"

Lifun ★★★★★ ()
Последнее исправление: Lifun (всего исправлений: 2)