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

Собрал Лису-64 Clang+ThinLTO+PGO. Заняло 57 минут.

эти чудаки на букву «м» задолбали уже. в 64 лисе сделали зависимость от nodejs неопциональной. в 63 ещё можно было указать --disable-nodejs и нормально собиралось, а в 64 ругается «включите ноду».

до этого в quantum'е clang сделали обязательной зависимостью даже если ты собираешь с gcc. теперь чтобы собрать firefox, нужно поставить целых три тяжёлых пакета - nodejs, clang и rust. эти пакеты мне больше низачем не нужны, но приходится их держать. если rust ещё можно понять, то clang и node мне как пятая нога

бомбануло, да

Честно говоря, у меня тоже бомбануло, когда я ещё всё GCC собирал. Нафиг мне Clang только для одного какого-то файла в Firefox. Я долго офигевал с этого. Пробовал тогда собирать Firefox Clang'ом, не получалось. Потом расслабился, и перестал переживать.

Ещё бы Chromium собрать Clang+ThinLTO+PGO и можно Gentoo сносить. :)

А на сегфолты во фронте тоже тебе писать?) Шланг _иногда_ не оч работает с гццшной либстдцпп

Что за сегфолты? Нужны подробности. Может и мне.

если rust ещё можно понять, то clang и node мне как пятая нога

И clang и rust тянут libllvm.

А вот с nodejs досадно: он зависит от (часто встроенной Гугл v8), хотя у Мозиллы есть своя (встроенная в Огнелис) libmozjs.

Фронтэнд. Не может распарсить исходники, да так что падает. Рагьше хватало

#include <notexists>
#include <future> // gcc

Но это зафиксили, найду ещё – отпишусь

Где бенчмарки. С чего я вообще должен верить каким-то ламеркам из интернета? Где пруфы этим потугам?

К тому же, это ламерки:

You might wonder if we tried LTO with GCC, or tried upgrading to GCC 8.x. As a matter of fact, I did. Enabling LTO turned up linker errors, and upgrading to GCC 7.x turned up breaking binary compatibility with older systems, and if I remember correctly had some problems with our test suite. GCC 8.1 was barely out when I was looking into this, and we all know to stay away from any new major GCC version until one or two minor updates. Considering the expected future advantages from using clang (cross-language inlining with Rust, consistency between platforms), it seemed a better deal to switch to clang than to try to address those issues.

Ламерки не понимают, что thinlto - это не лто, а дерьмо. И никаким образом с настоящим lto не сравним. А настоящий lto требует доступа ко всем частям линковки. На чём ламерки и прогорели.

К тому же, тут явно виден базворд «недоязычок», а значит это ангажированное дерьмо. Ламерки могут специально гадить gcc, чтобы их дерьмо собиралось только на llvm-инфраструктуре, чтобы потом соревноваться только с llvm.

Мне некогда тебе объяснять очевидные вещи, но тебя поимели.

А можно по подробнее про патч на ninja?

Где например его достать? На github мельком пробежал, нечего не нашел по этому поводу.

Потому что я использую свои патчи и лежат они у меня. По идее лучше написать враппер над компилятором (gcc, clang, $CC и тп), который ждет освобождения нужных ресурсов и запускает компилятор. Но с врапперами свои проблемы.

В генту в 9 версии флаг lto убрали, но в каком состоянии он в toolchain при этом остался не знаю.

Для затравки, самая интересная часть патча для ninja-1.8.2:

--- a/src/build.cc
+++ b/src/build.cc
@@ -513,9 +513,19 @@ void RealCommandRunner::Abort() {
 bool RealCommandRunner::CanRunMore() {
   size_t subproc_number =
       subprocs_.running_.size() + subprocs_.finished_.size();
-  return (int)subproc_number < config_.parallelism
-    && ((subprocs_.running_.empty() || config_.max_load_average <= 0.0f)
-        || GetLoadAverage() < config_.max_load_average);
+  if ((int)subproc_number >= config_.parallelism)
+    return false;
+  if (subprocs_.running_.empty())
+    return true;
+  if ((config_.max_load_average > 0.0f)
+      && GetLoadAverage() >= config_.max_load_average)
+    return false;
+  if (config_.mem_available > 0) {
+    long kb = get_mem_available_kb();
+    if ((kb >= 0) && ((long long)1024*kb < config_.mem_available))
+      return false;
+  }
+  return true;
 }

 bool RealCommandRunner::StartCommand(Edge* edge) {

Чем не устраивает memory cgroup? Чё тут у вас происходит?

Чем не устраивает memory cgroup?

И как поможет memory cgroup при параллельной компиляции тяжелых исходников? Ошибками сборки из-за невозможности выделить память?

Там ограничение rss а не vsz или swap(но swap можно тоже отдельно ограничить).

Вот тебе и оптимизация под определённый компилятор.

Так gcc в принципе больше памяти потребляет на компиляцию

Мне лично похер сколько там оно собирается

А тем, кто разрабывает большие проекты - совсем нет)

И что это даст? При компиляции активно используется практически вся выделенная память. Загонишь задачу в перманентный свопинг.

Это какая-то лайт-версия https://github.com/ninja-build/ninja/pull/1354

Конечно это лайт версия. Потому что у меня на уровне ядра отключен cgroups, и нет этой лапша-логики на булевых операциях. Я вообще не понимаю, что за ктулху он там вызывает. Я даже оргинальную writeonly булеву логику переделал на достаточно легко модифицируемые if'ы.
Хотя увидел идею насчет добавления задержки/delay запуска задач. А то ninja любит запускать задачи пачками.

Давно наблюдаю: при включенном SMT процесс сборки Chromium под FreeBSD вываливается с ошибкой о нехватке памяти — пришлось делать 16Gb SWAP и отказаться от RAM-диска для компиляции. Но без SMT процесс сборки не прерывается, память не жрётся — можно спокойно обойтись небольшим SWAP. Правда, без SMT компиляция медленна на 30%.

при включенном SMT процесс сборки Chromium под FreeBSD вываливается с ошибкой о нехватке памяти

При включенном jumbo-build, каждая задача может сожрать 4 гига и выше. Если 8 параллельных задач, то легко можно вылезти за 30 гигов, как повезет. Без jumbo-build - 2.5 гига на задачу, но ждать придется раза 4 дольше. Как понимаю jumbo-build это костыльная имитация precompiled-headers, не смогли или не захотели в pch.

Конечно это лайт версия.

Не хочешь выложить её целиком?

А то ninja любит запускать задачи пачками.

Философия нинзи: как можно быстрее :)

не смогли или не захотели в pch.

Надо zapcc попробовать. Хотя он и нацелен в первую очередь для повторной сборки.

Не хочешь выложить её целиком?

Зачем? Это узко специальная версия только меня. Основную логику показал (над которой пришлось пошевелить мозгами, чтобы распарсить оригинальную лапша-логику). Осталась только техническая часть: реализовать получение доступной памяти и аргумент командной строки для необходимой памяти.

Также этот патч с некоторыми изменениями синхронизирован с патчем для gnu-make, который написан на чистом си, не си++, чтобы не писать одно и тоже два раза. Поэтому остальная часть будет выглядеть слишком чужеродно для си++.

И вообще, я хочу переделать на врапперах, и не патчить исходные инструменты, но лень.

Собирал в 4 потока с jumbo-build с gcc 9.1 - памяти скушало максимум 4 гига за всю сборку.

Молодец.

Я к тому, что ты какие-то цифры не реальные привёл

jumbo-build это что-то на подобии amalgamation в sqlite, объединение исходников

Кошмар.

Вот до чего докатился C++ с имитацией модульности. Скажите разработчикам, что модульность сложных программных комплексов придумали и внедрили ещё в середине 1980-х в Turbo Pascal 4.0 (1987г.). А то может они до сих пор не в курсе, раз требуют гигабайты оперативной памяти, чтобы разложить по полочкам всю «простыню» кода.

А ты не умеешь читать.

можно вылезти за 30 гигов, как повезет

Тебе сильно везет, или врешь.
и количество слитых файлов можно регулировать jumbo_file_merge_limit=25, но дольше будет собирать. И процесс слияния, как я понимаю, тоже случаен.

GNU софт - сраное legacy. Тоже мне новость

Знаю я, что такое jumbo-build. При слиянии исходников, повторные инклуды будут пропускаться на гвардах, из-за чего не будут повторно компилироваться. Что есть имитация pch.

Проблема не в (отсутствии) модульности. Проблема в шаблонах и оптимизации.

И процесс слияния, как я понимаю, тоже случаен.

Так, тогда нужен аналог PGO для jumbo-build. Если разница между случайными слияниями может быть существенной. Разве что в отличие от PGO в одиночку не выйдет. Надо будет лог+статистику загружать куда-то, где будут сравниваться результаты и потихоньку подбираться оптимальный.

Нужен военно-морской kiss. И оптимизировать надо как минимум размер исходников. А не прятать очередной сканер всех файлов пользователя в миллиардах строк.

Заранее извинияюсь за кодинг на форуме.
Вместо

+  if (config_.mem_available > 0) {
+    long kb = get_mem_available_kb();
+    if ((kb >= 0) && ((long long)1024*kb < config_.mem_available))
+      return false;
+  }

ninja0 -j8 --job-callback "perl /path/to/freemem.pl 4G"

...
  if (config_.job_callback != NULL) {
    if (system_callback(config_.job_callback) != 0)
      return false;
  }
...

int system_callback(const char* cmd) {
  // stdlib.h:  int system(const char *command)
  int ret = system(cmd);
  if (ret == -1)
    return ret;
  if (WIFEXITED(ret))
    return WEXITSTATUS(ret);
  return -1;
}