А в чем, собственно, проблема и что тут невозможного?
Для генты где-то были ебидлы лисы с PDO даже

Каждую неделю пересобираю мир, там и лиса и хромиум и много всякого толстого, 32 гигов оперативки хватает с головой, из них 16 гиг выделено под tmpfs - хромиум влезает ;)

За полярным кругом живешь?

Быстро-браузер

clang

И сходу фэйл.

Знаю. И для Gentoo тоже.

Проблема в том, что не хватает памяти для LTO+PGO - вместе. Отдельно, они красивые и быстрые - но требуют памяти неимоверно.

У меня, пока 8GB. И этого оказывается - недостаточно.

Что происходит при этом. При линковке Firefox xul.so - ld.gold занимает весь доступный RAM. iotop - показывает, что процесс ld усердно срёт в SSD со скоростью ~200-1500KB/s. Нагрузка CPU ~10% и load average ~1.5

Раз уж шланг, то почему не lld?

This! 16GB /tmpfs

Для сборки Firefox mobile - 6ГБ /tmpfs - суть абсолютный минимум.

Вопрос опять: Где найти провайдера с RAM 32GB?

У меня пока не установился lld. Например, потому что линкер lld не уживается с llvm в cmake test

У тебя получилось собрать lld без ашибок? Научай, пожалуйста!

У меня, пока 8GB. И этого оказывается - недостаточно.

tmpfs на 32+ и соразмерный своп.

Сделаю старание сделать получить плоды фрукта как вы. Благодарю вас!

Где вы нашли /tmpfs 32 GB - признавайтесь и не томите публику, пожалуйста!

Тест на ошибки lld не проходит. «Грязь» в записи композиции, скажут аудио-инженеры и будут таки правы.

youtube.com/watch?v=CWw3dVNloVI

Конечно, хочу собрать Firefox с lld. И собрать правильно - тест компилятора и линкера должен пройти без ошибок.

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

http://www.downloadmoreram.com/

Не использовать tmpfs.

Тебе шашечки или ехать? Свап делай и не ной.

Почему твоя решила что моя не подключала swapfile 16GB?

Узбагойся. Не время язвить сейчас, особенно нашинским.

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

Леди ManDala - продвигает позитивные идеи. И хочет помочь, всеми своими силами.

Это даже неожиданно на ЛОР. Могу спросить - «Вы, то есть Ты, когда пойдём в театр?»

Из не очень большого опыта с тормозами компиляции, правда на винде - «продать ssd, купить память».

Если активно используемые данные не влезают в память - ssd почти не поможет. А скорость чтения/записи того, что используется не более одного раза - почти не играет роли (раза в 2 из того единственного эксперимента hdd vs ssd для компиляции, который я проводил).

Вот теперь снизошло озарение речей вачинских в очи мои.

32GB RAM готов принять. Вы же мне обещали их в своём посту?

Ясно и верно. Памяти не хватает, 8GB.

Имеем наблюдать, swapping ~100kb/s и полное отсутвие жизнедеятельности CPU.

ЦПУ нечем занятся, как данные туда-сюда перечитывать/переписывать.

Баръер наступает, когда размер .so превышает ~200MB. Компиляция LTO+PGO вместе - и xul.so будет линковаться. сутками.

Одно из них, LTO или PGO - раздельно - линкуется быстро. И памяти 8GB - достаточно.

Ещё, если данные диска, к которым происходит обращение являются хорошо сжимаемыми, можно попробовать zswap (доступен в ядрах уже несколько лет, но требуется ручная настройка)

Его идея в том, что пожать+распаковать данные простым алгоритмом будет быстрее чем писать на диск. А сжатых данных в память помещается больше. Приличная скорость только у довольно слабо сжимающих алгоритмов, поэтому сжатия больше чем на 30-40 процентов ожидать не стоит, но если повезёт - этого может хватить

Верный подход, если zswap будет использован так, для чего swapping и нужен. Для хранения данных, которые можно сохранить, для дальнейшей работы и забыть о них пока.

При линковке LTO+PGO - линкер ld.gold - требует для своей работы всю имеющуюся память и больше.

Теперь, нашёл на Usenet/google groups - упоминание о 200GB RAM, для линковки Chrome под странную ОС шин.

Собственно, вопрос был о том - можно ли использовать площадку Amazon, с памятью 32GB и Xeon'ами серверными 16 ядер?

openSUSE Build Service - не смог слинковать. По причине вышеизложенной. (Инфраструктура compile farm годная у Suse, ... получил, не спрашивайте как, доступ к ЭВМ с RAM 16GB + 16GB HDD, самому быстрому на ферме) Посмотрел firefox.spec, как они сами собирают firefox. Интересно. И у них оказывается, проблемы с RAM.

В жаббер стукнись, могу помочь, есть сервер с 32 гига. Последний шланг там уже собран из Гита.

Тебе надо собирать или собирать быстро? Если быстро — докупай памяти, если просто хотя бы собрать — делай своп. Где рокетсайенс, товарищ*?

Jabber

Уже интересно.

http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto/

Лучше всего - выбрать время, когда firefox выпустить новый, 53.0 по счёту.

Это будет 18 апреля. Как выпустят новый билд - сделаю компиляцию на своём PC. Проверю, что патчи privacy работают.

Тогда, можно попросить вас:

Залить на сервер 200MB firefox source и 20KB патчей plain text.

Ни разу так и не дособирал Firefox с PGO. Думаю что это на порядок большее время компиляции ради незаметного роста производительности.

А телеметрию можно параметрами about:config отключать.

Отнюдь не так. Инструментирование .so и .dll - при компиляции PGO - займёт лишь +10% по времени.

Дальше, натаскать инструментированный Firefox на тестах js/webgl/webm - да, это долго. Час, не более. Старательно и арийски педантично.

По сопоставительным тестам, с PGO, +20%. Считаю, что игра стоит свеч/овчинка стоит выделки.

А как считаете вы?

Если 20%, то стоит.

В Ebuild-е Firefox сказано, что сборка с PGO требует в 2 раза больше ресурсов.

Из личного опыта.

blitz@inode ~/abs/extra/firefox-50 % ls firefox-*
-rw-r--r-- 1 blitz users      3075 Sep 10  2016 firefox-48.0.2.patch
-rw-r--r-- 1 blitz users 195823768 Dec 13 12:48 firefox-50.1.0.source.tar.xz
-rw-r--r-- 1 blitz users  40967644 Dec 13 15:06 firefox-50.1.0-1-x86_64-clang-O3.pkg.tar.xz
-rw-r--r-- 1 root  root   43167312 Dec 14 17:50 firefox-50.1.0-1-x86_64-clang-O3-lto.pkg.tar.xz
-rw-r--r-- 1 blitz users  43561216 Dec 17 19:59 firefox-50.1.0-1-x86_64-clang-O3-pgo-lto.pkg.tar.xz
-rw-r--r-- 1 blitz users  49636540 Dec 13 17:47 firefox-50.1.0-1-x86_64-gcc4-O3-pgo.pkg.tar.xz
-rw-r--r-- 1 blitz users  43398632 Dec 13 14:58 firefox-50.1.0-1-x86_64-gcc-O3.pkg.tar.xz
-rw-r--r-- 1 blitz users  44032752 Dec 14 02:40 firefox-50.1.0-1-x86_64-gcc-O3-lto.pkg.tar.xz
-rw-r--r-- 1 blitz users  41892632 Dec 13 19:33 firefox-50.1.0-1-x86_64-gcc-O3-pgo.pkg.tar.xz
-rw-r--r-- 1 blitz users     83988 Aug 17  2016 firefox-gtk3-20.patch
-rw-r--r-- 1 blitz users       679 Aug 17  2016 firefox-install-dir.patch
-rw-r--r-- 1 blitz users       312 Aug 17  2016 firefox-pgo-profile-run.patch
-rw-r--r-- 1 blitz users      6935 Aug 17  2016 firefox-symbolic.svg
-rw-r--r-- 1 blitz users      7001 Aug 18  2016 firefox-system-wrappers.patch

Сборка firefox с PGO - требует достаточно ресурсов PC. Пришлось перекомпилировать кернел и сменить p-state с powersave на performance. Иначе, ld.gold при линковке не трудился.

Но это - только при первом проходе PGO, когда размеры .so и исполняемых файлов растут в ~6 раз. При втором проходе PGO, всё легче и проще.

Можешь сравнить, как влияет PGO LTO на размер исполняемых файлов.

Ok