The OpenNET Project / Index page

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

Проект по добавлению в GCC поддержки распараллеливания процесса компиляции

15.09.2019 10:09

В рамках исследовательского проекта Parallel GCC началась работа по добавлению в GCC возможности, позволяющей разделять процесс компиляции на несколько параллельно выполняемых потоков. В настоящее время для повышения скорости сборки на многоядерных системах на уровне утилиты make применяется запуск отдельных процессов компилятора, каждый из которых выполняет сборку отдельного файла с кодом. Новый проект экспериментирует с обеспечением распараллеливания на уровне компилятора, что потенциально позволит повысить эффективность работы на многоядерных системах.

Для тестирования подготовлена отдельная распараллеливающая ветка GCC, для задания числа потоков в которой предложен новый параметр "--param=num-threads=N". На начальном этапе реализован вынос в отдельные потоки выполнения межпроцедурных оптимизаций, которые циклично вызываются для каждой функции и хорошо поддаются распаралелливанию. В отдельные потоки вынесены операции GIMPLE, отвечающие за независящие от оборудования оптимизации, оценивающие взаимодействие функций между собой.

На следующем этапе в отдельные потоки также планируется вынести межпроцедурные RTL-оптимизации, учитывающие особенности аппаратной платформы. После этого планируется реализовать распараллеливание внутрипроцедурных оптимизаций (IPA), применяемых к коду внутри функции, независимо от особенностей вызова. Ограничивающим звеном пока является сборщик мусора, в который добавлена глобальная блокировка, отключающая операции сборки мусора во время работы в многопоточном режиме (в будущем сборщик мусора будет адаптирован для многопоточного выполнения GCC).

Для оценки изменения производительности подготовлен тестовый набор, осуществляющий сборку файла gimple-match.c, включающего более 100 тысяч строк кода и 1700 функций. Тесты на системе с CPU Intel Core i5-8250U с 4 физическими ядрами и 8 виртуальными (Hyperthreading) показали снижение времени выполнения оптимизаций Intra Procedural GIMPLE с 7 до 4 секунд при запуске 2 потоков и до 3 секунд при запуске 4 потоков, т.е. достигнуто увеличение скорости рассматриваемого этапа сборки в 1.72 и 2.52 раза, соответственно. Тесты также показали, что использование виртуальных ядер при Hyperthreading не приводит к росту производительности.

Общее время сборки сократилось приблизительно на 10%, но по прогнозам распараллеливаие RTL-оптимизаций позволит добиться более ощутимых результатов, так как данная стадия занимает при компиляции существенно больше времени. Ориентировочно после распараллеливания RTL общее время сборки сократится в 1.61 раза. После этого еще на 5-10% можно будет сократить время сборки за счёт распараллеливания оптимизаций IPA.



  1. Главная ссылка к новости (https://news.ycombinator.com/i...)
  2. OpenNews: Реализация оптимизации для GCC, учитывающей связь между файлами сборки
  3. OpenNews: Открыт код C++ компилятора Zapcc
  4. OpenNews: Релиз набора компиляторов LLVM 8.0
  5. OpenNews: Представлен Lucet, компилятор для WebAssembly
  6. OpenNews: Релиз набора компиляторов GCC 9
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/51491-gcc
Ключевые слова: gcc, optimization, parallel, speed
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (100) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Онаним (?), 10:44, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    > Тесты на системе с CPU Intel Core i5-8250U

    Это всё, что надо знать про данные исследования. Сферические теоретические кони в вакууме. Зачем оно, вообще, если сборка любого мало-мальски крупного проекта и так отлично распараллеливается тупо запуском множества процессов компиляции.

     
     
  • 2.7, Аноним (-), 11:30, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +14 +/
    Множество процессов компиляции неэффективно по памяти
     
     
  • 3.94, Аноним (94), 16:30, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Зато более эффективно по процессору, а память можно докупить
     
     
  • 4.101, Аноним (101), 16:37, 18/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    И процессор можно докупить. Видимо только время нельзя докупить ...
     
  • 3.103, Онаним (?), 11:51, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Память ныне стоит сущие копейки. Городить при этом какой-то огород, перепахивая кусками компилятор, в котором и так чёрт ногу сломит... работа ради работы, без цели и смысла.
     
     
  • 4.106, Алексей Михайлович (?), 14:36, 24/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    То есть, никто не понимает, что разрабы пытаются удешевить (по времени, танкисты, по времени) управление памятью и ЦП вместо того, чтобы при компиляции генерировать кучу ненужных системных вызовов, только отнимающих время, и упираться по потолку производительности в шедулер? Пздц вы тупые, откуда вам вообще сюда выпустили?
     
     
  • 5.108, Онаним (?), 20:39, 24/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > То есть, никто не понимает, что разрабы пытаются удешевить (по времени, танкисты,
    > по времени) управление памятью и ЦП вместо того, чтобы при компиляции
    > генерировать кучу ненужных системных вызовов, только отнимающих время, и упираться по
    > потолку производительности в шедулер? Пздц вы тупые, откуда вам вообще сюда
    > выпустили?

    Штопрастите?

     
  • 2.12, Аноним (12), 11:53, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Купи им 9900K
     
     
  • 3.87, Аноним (87), 07:50, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.
     
     
  • 4.104, Онаним (?), 11:51, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.

    Вот да. И даже никакого дорогостоящего перепахивания компилятора не потребуется :D, а эффект будет куда выше, чем от перепахивания для всяких мобильных i5.

     
  • 2.29, Аноним (29), 13:56, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В Сях нужно не парралелить, а кешировать заголовки
     
  • 2.30, Анонец (?), 14:01, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –13 +/
    Студни-хипсторы решили помучить поциента перед его окончательной кончиной.

    Шланг смотрит на всё это со снисходительной улыбкой

     
     
  • 3.43, Аноним (43), 14:48, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Шланг смотреть с улыбкой не может, у него те же болячки. У него так же делается "распаралеливание" как и у GCC (запуск множества процессов шланга).
     
     
  • 4.93, Аноним (93), 13:27, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    а чем это плохо? не модно ?
    Или нужно еще сильнее дергать головки у диска - что бы скорость упала.
     
     
  • 5.107, Алексей Михайлович (?), 14:37, 24/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это плохо лишними сисколлами и отсутствием нормального интерпроцессного взаимодействия. Тредами рулить удобнее и дешевле, чем полноценными инстансами.
     
  • 2.74, Michael Shigorin (ok), 20:24, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Например, для целей CI, когда время сборки оказывается более существенным, чем при единичном запуске...

    Мне другое непонятно -- при всей востребованности распараллеливания сборки _единичной_ цели как они собираются это увязывать с распараллеливанием средствами того же make?  Пока напрашивается разве что массовый переход сборочных систем на использование -l вместо -j как минимум в нормальном make, но при изолированных окружениях это потребует пробрасывания как минимум настоящего /proc/loadavg в чруты.

    Мы обдумывали нечто перекликающееся в плане оптимизации плотности использования сборочных узлов в условиях, когда параллельно запускаемые сборки могут параллелиться, а могут и нет.  Пока применяю gnu parallel для некоторых задач, но в случае "девятого вала" хорошо параллелящихся тяжёлых сборок узлам бывает грустно.

    А сейчас представил себе параллелизацию третьего порядка (пакеты, цели, и затем внутренняя по каждой цели вдобавок) -- для aarch64 это было бы полезно вотпрямщас, на ppc64le с его горой потоков тоже бы уже пригодилось, но как с этим всем управляться -- пока вопрос.

     
     
  • 3.80, Аноним (80), 21:17, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тоже сразу возник вопрос про связь с make -j. Пока кажется, что параллелизация через make будет эффективнее. Сколько раз смотрел на загрузку ядер при сборке make -j по количеству ядер, всегда все ядра на 100% использовались. А тут что-то идеального повышения производительности не видно пока.
     
     
  • 4.82, iZEN (ok), 00:08, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Да нет никакой связи с make -j кроме чистой детерминированности процесса сборки ... большой текст свёрнут, показать
     
     
  • 5.90, Аноним (90), 11:45, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Простите за такую подробность, но процессор это не виртуальная машина Джавы, он ... большой текст свёрнут, показать
     
     
  • 6.97, iZEN (ok), 20:42, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Зато новый планировщик знает об особенностях архитектуры процессора и какую нить... большой текст свёрнут, показать
     
  • 3.85, Ю.Т. (?), 07:02, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Системы с общей памятью (потоки и т.д.) хороши далеко не для всех задач. Задачи трансляции-компоновки хорошо авто-параллелятся далеко не во всех случаях. ))
     
  • 3.105, Онаним (?), 11:54, 21/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А при чём тут CI и цели? Тут речь идёт о внутреннем распараллеливании сборки одного-единственного файла. Зачем это - ума не приложу. Любителей собирать многомегабайтные монолиты вроде не осталось.
     

  • 1.2, Аноним (2), 11:13, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    >Новый проект экспериментирует с обеспечением распараллеливания на уровне компилятора, что потенциально позволит повысить эффективность работы на многоядерных системах.

    Потоки? Многоядерные системы? В 2019? Да не это бред какой-то
    Если бы они сущестовали то наверняка их поддержка появилась бы в GNU HURD

     
     
  • 2.15, Аноним (15), 12:04, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Интересно как мы так раньше всю жизнь компилировали что сабж был не нужен.
     
     
  • 3.66, Илья (??), 18:00, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Медленно
     
  • 2.46, Аноним (43), 14:50, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Кто о чём а вшивый о бане. Анониму видимо невдамёк, что Hurd забросили сразу после первого выпуска Linux. То, что они делают сейчас -- предсмертные конвульсии. Какие-то жалкие попытки 1.5 анонимов допилить ядро, примерно то же, что происходит с React OS.
     
     
  • 3.54, Аноним (54), 15:25, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что там у реакт ОС?
     
     
  • 4.84, Аноним (84), 06:37, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, но пока нет.
     

  • 1.3, Андрей (??), 11:16, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    Интересно, как оно грузит ядра. Ибо если все 4/8 ядра на все 100%, но ускоряет суммарно в 2,5 раза, то получается, наверняка, энергетически невыгодно.
     
     
  • 2.8, Аноним (-), 11:32, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Судя по тексту в статье распараллелили не все этапы компиляции
     
  • 2.14, pda (?), 12:00, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    man "Закон Амдала"

    Да уж наверняка не выгодно, но на настольных компах на это особого внимания не обращают. Быстрее бы работало.

     
  • 2.75, Michael Shigorin (ok), 20:26, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Так это оптимизация не энергозатрат, а времени выполнения.
     
  • 2.88, Аноним (88), 10:08, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Грузить ЦП на 100% всегда выгодно
     
     
  • 3.96, Аноним (96), 19:13, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Вы не правы. По крайней мере на процессорах Intel серии U это не так из-за термального режима, на который они конструктивно рассчитаны, и соответственно thermal throttling'а. Другими словами - ограничив нагрузку до 80-90%, получаем в среднем меньший вольтаж и более быструю результирующую компиляцию из-за меньшего троттлинга (штеуд перестраховывается? может быть). Полагаю, с штатными кулерами AMD, которые идут в комплекте с последними Ryzen - всё так же, но менее выражено в %.
     
     
  • 4.98, Аноним (98), 10:40, 17/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >По крайней мере на процессорах Intel серии U это не так из-за термального режима, на который они конструктивно рассчитаны, и соответственно thermal throttling'а. Другими словами - ограничив нагрузку до 80-90%

    Я говорю про нормальные процессоры, а не обрезки, максимум которых - просмотр ютуба

     
     
  • 5.102, Аноним (101), 16:40, 18/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Какой Ютуб очнитесь это текстовые стратегии и консольный режим для терминалов из 80-х всякие там имаксы и прочая чепушень
     

  • 1.4, Андрей (??), 11:20, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Несмотря на распараллеливание в make&Co я, похоже, знаю, почему им пришлось взяться за компилятор. Это всё C++. С помощью его шаблончиков можно сваять сравнительно небольшой исходник, который будет компилироваться несколько минут и отхватит несколько гигов памяти. Тут никакой "-j4" не поможет.
     
     
  • 2.6, Аноним (6), 11:26, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Свопить на оптан?
     
     
  • 3.24, Аноним (24), 13:30, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Оптан стоит денег, медленнее сам по себе, кэш промахи при -jX стремятся к 100%.
     
     
  • 4.44, Аноним (6), 14:49, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    По сравнению с терабайтом RAM, это хоть как-то вариант.
     
     
  • 5.55, Аноним (90), 15:39, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > По сравнению с терабайтом RAM, это хоть как-то вариант.

    И где тот оптан на терабайт?

     
     
  • 6.71, Stax (ok), 19:58, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Тут? https://www.amazon.com/Intel-Optane-905P-960GB-XPoint/dp/B07CVNS851
    В россии, конечно, подороже https://www.citilink.ru/catalog/computers_and_notebooks/hdd/ssd_in/1059850/

    Но все равно в 8 раз дешевле оперативки.

     
     
  • 7.91, Аноним (90), 11:52, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Тут?

    Ага, спасибо. Тогда у меня следующий вопрос: сколько ангелов уместится на булавочной головке?

     
  • 2.9, vitalif (ok), 11:34, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ога. Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких ))) потому что как раз заголовки, шаблоны и т.п. только 1 раз обрабатываются.

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

     
     
  • 3.13, Аноним (13), 11:54, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как не сделали? Сделали! и без компилятора даже: https://github.com/sakra/cotire
     
  • 3.18, Андрей (??), 12:39, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких )))

    100 КБ файл с шаблончиками -> 1 ГБ ОЗУ
    10 МБ уберфайл -> 100 ГБ ОЗУ
    Не, не выйдет.

    > почему до сих пор не сделали компилятор, который всё лепил бы в один файл

    Тут и специфический компилятор не нужен. При сборке Chromium есть опция JUMBO build. Эффект, вроде, как раз тот.

     
  • 3.63, all_glory_to_the_hypnotoad (ok), 17:16, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не сможешь делать инкрементальную сборку, т.е. даже при незначительном изменении будет нужно пересобирать всё. Есть костыли типа precompiled headers и может быть после появления модулей плюсы научатся делать нормальные промежуточные сборки модулей.
     
  • 2.38, Аноним (38), 14:43, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ничего удивительного, шаблоны могут в рекурсии.
     
  • 2.47, Аноним (43), 14:52, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > С помощью его шаблончиков можно сваять сравнительно небольшой исходник, который будет компилироваться несколько минут и отхватит несколько гигов памяти.

    Пример шаблона ф студию. У меня всего 4Gb, компилирую проекты на 20Gb спокойно.

     
     
  • 3.58, Андрей (??), 16:16, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Например, установите (или скомпилируйте сами) библиотеку https://github.com/ukoethe/vigra и соберите крошечный набор enblend-enfuse https://sourceforge.net/projects/enblend/files/enblend-enfuse/enblend-enfuse-4
    Что при компиляции enblend, что enfuse в составе этого проекта наблюдаются задержки и рост потребления памяти.
     

  • 1.5, Аноним (6), 11:24, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Надеюсь, это не включат по умолчанию. Бывают проекты на нескольких языках, мне нафиг не упёрлось собирать их в 146 потоков.
     
     
  • 2.11, Анонимный селебрити (?), 11:48, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если ко времени выпуска впрод этот gcc м симтемой сборки будет крутится на односокетном 128-ми ядерном epyc 7003, то why not?
     
     
  • 3.61, user (??), 17:04, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    упрётся в память, компиляция плохо кэшируется
     

  • 1.10, InuYasha (?), 11:36, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Главное в этой инициативе - чтобы компилятор был NUMA-aware. Т.е. не начал параллелить одну компиляцию на разные физические процессоры или модули, а только на ядра, имеющие общий блок памяти. Иначе будет замедление.
     
     
  • 2.16, Аноним (15), 12:05, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Главное они из существующего компилятора сделают такое УГ что единственным способом решения его проблем станет переход на раст.
     
     
  • 3.41, Аноним (38), 14:48, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А Rust, кроме своих, ещё начится компилировать исходники C, C++, Go, Fortran.
     
  • 3.76, Michael Shigorin (ok), 20:31, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    ...а ещё лет через сорок до растоманов дойдёт, что их УГ можно было собирать параллельно...
     
     
  • 4.81, Ordu (ok), 23:43, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это ты к чему? Раст собирает параллельно столько, сколько я с ним вожусь, то есть с 2014 года как минимум.
     
  • 4.92, Аноним (90), 11:58, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > ...а ещё лет через сорок до растоманов дойдёт, что их УГ можно
    > было собирать параллельно...

    Он и собирает параллельно. При сборке firefox сначала порождается процессов сколько надо, потом из них 1-2 начинают собирать rust и кол-во потоков утраивается. Как этот новый транслятор выйдет, так С его догонит по кол-ву лишних потоков.

     
  • 2.53, CrazyAlex (?), 15:20, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Главное - чтобы оно выключалось. А лучше - чтобы не попало в gcc вообще. Уж что-что, а компиляция в разных процессах работает отлично, и при этом хорошо контролируется при нужде - хоть по нагрузке, хоть по памяти, хоть как.
     

  • 1.17, Аноним (17), 12:29, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    GCC в прошлом. Модные парни уже давно перешли на MUSL + LLVM + CLANG
     
     
  • 2.19, Llvm (?), 12:58, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ничего против clang не имею.
    Но вот его баг в актуальной версии 8.0 с двойным вызовом деструктивных при исключении в лямбде реально достаёт. Баг есть, а фиксить не спешат.
     
     
  • 3.20, Llvm (?), 13:00, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    s/деструктивных/деструкторов/
     
  • 2.22, Аноним (90), 13:25, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > GCC в прошлом. Модные парни уже давно перешли на MUSL + LLVM
    > + CLANG

    Давно systemd собирается с MUSL?

     
     
  • 3.23, Аноним (17), 13:29, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    не позорься со своим системд. Такие вещи даже страшно вслух произносить.
    нормисы юзают S6/runint
     
     
  • 4.25, Аноним (90), 13:38, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > не позорься со своим системд. Такие вещи даже страшно вслух произносить.

    Экий ты шустрик в переобувке. Я позорюсь с твоим "Модные парни".

    > нормисы юзают S6/runint

     
     
  • 5.27, Аноним (17), 13:52, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Дело не в переобувки. А в сути - почему люди добровольно отказываются от Поеттеринга во всех его проявлениях, будь то pulseaudio, systemd и еще что-нибудь.
     
     
  • 6.37, Аноним (90), 14:39, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Дело не в переобувки. А в сути - почему люди добровольно отказываются
    > от Поеттеринга во всех его проявлениях, будь то pulseaudio, systemd и
    > еще что-нибудь.

    А в чём дело? Теперь ты меня спрашиваешь, почему MUSL не поддерживается в systemd. Мне то откуда знать, почему ты заявил что модный парень Поеттеринг перешёл на MUSL, когда это не так.

     
  • 6.50, Аноним (43), 14:55, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > будь то pulseaudio

    Поттеринг его забросил, и как только это случилось он стал конфеткой. Сейчас он что-то новое там хочет пилить, замена пульсе.

     
  • 5.28, Аноним (17), 13:55, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Конечно если речь не о прод серверах. там до сих пор на убунте 16.04 сидят или кастрированной Centos.
     
     
  • 6.36, Аноним (15), 14:35, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    У кого-то прод серверы на венде и им норм.
     
     
  • 7.68, Аноним (68), 18:32, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Кому и кобыла невеста.
     
  • 4.49, Аноним (43), 14:54, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > не позорься со своим системд.

    Реклама uselessd?

    > Такие вещи даже страшно вслух произносить.

    Действительно. Шёл 2019 год, а ненужнод не может в Musl.

     
     
  • 5.72, Stax (ok), 20:04, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Реклама uselessd?

    Но оно же умерло вскоре после рождения, еще лет 5 назад.

     
  • 2.26, Лох (?), 13:52, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как запилить тулчейн musl+clang и кросскомпилить под i586? Так и не нашел гайдов, под такой же кейс, но с gcc, гайдов куча. Может поможет кто-нибудь?

     
     
  • 3.77, Michael Shigorin (ok), 20:33, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Простой 32-битный чрут не выручит часом?
     
  • 2.45, Аноним (38), 14:49, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >MUSL + LLVM + CLANG

    Модно, стильно, молодёжно!

     

  • 1.21, Аноним (21), 13:13, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А почему нет новостей как Столман отжигает в своем репертуаре?
     
     
  • 2.31, Аноним (15), 14:07, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Потому что ты эту новость не написал.
     
  • 2.32, Аноним (15), 14:08, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Подсказка https://www.opennet.ru/announce_news.shtml
     
  • 2.39, лексус торнварцс (?), 14:43, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Он уже _ИЗВИНИЛСЯ_ перед сжв https://stallman.org/archives/2019-jul-oct.html#14_September_2019_(Sex_between)
     
  • 2.48, Аноним (38), 14:53, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А может быть, Столман это поддержит?
     

  • 1.35, Аноним (-), 14:34, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Дядя типереча тормознутые исходники на C++ будут быстро компилится?
     
  • 1.42, Корец (?), 14:48, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Из серии "Давно пора"
     
  • 1.57, nm0i (ok), 16:00, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В итоге оптимальным вариантом будет что-то вроде сочитания gcc -j N и make -j M -l K, да?..
     
     
  • 2.64, all_glory_to_the_hypnotoad (ok), 17:22, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Идеальным вариантом по-прежнему будет make -j N просто хотя бы из-за большого кол-ва исходников в  проектах. Распараллеливать gcc имеет смысл только если пересобирать небольшую часть проекта во время разработки.
     
     
  • 3.67, Ordu (ok), 18:20, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Распараллеливать gcc имеет смысл только если пересобирать небольшую часть проекта во время разработки.

    То есть в большинстве случаев использования компилятора.

     
  • 3.78, Michael Shigorin (ok), 20:39, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Кстати, а вот make-овый jobserver как раз может скумекать, когда собирает _одну_ цель -- и научиться добавлять компилятору уже _его_ -j или что там... тогда проблему неуправляемого параллелизма в квадрате вроде как получается решить.

    Ну или пущать с -jJ/N, условно говоря, где J -- сколько потоков разрешили самому make, N -- количество собираемых сейчас целей; но тут есть "уязвимость" к случаю, когда цели собираются с сильным разлётом длительности и предположение об N (кроме N == 1) перекашивает на протяжении заметной части общего времени сборки.

     
     
  • 4.79, all_glory_to_the_hypnotoad (ok), 21:05, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    make чаще собирает одну цель когда линкует, а не компилирует. Проблема решается засовыванием всех процессов в cgroup-у. Т.е. make со всеми дочерними процессами должет отжирать примрно одинаковое кол-во CPU независимо от кол-ва процессов. Или можно костылить завышением nice всем процессам сборки. Опция -j N у компилятора может быть полезной, но ставить её лучше в фиксированное небольшое значение типа 2-3.
     
     
  • 5.100, пох. (?), 18:43, 17/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Проблема решается засовыванием всех процессов в cgroup-у.

    "новый стандарт" - ненужен.

     

  • 1.59, Anonimous (?), 16:35, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Т.е., забив четыре потока, компиляция ускорится всего в полтора раза?

    Почему не приведено сравнение с вариантом, когда в четыре потока запускаются разные процессы, и какой выигрыш/проигрыш в этом случае по сравнению с новыми разработками.

     
     
  • 2.60, Аноним (17), 17:03, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    я когда генту впервые пилил ставил -j30 и норм работает
     
     
  • 3.70, Аноним (70), 19:34, 15/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    надеюсь не на hdd? а то сложно предстаить какой там треск стоял:)
     
     
  • 4.83, Аноним (83), 01:53, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    На HDD. Никакой не стоял. Средний объём исходника и какой это объём данных и IOPS в 30 потоков посчитать несложно, чтобы чуши больше не писать.
     

  • 1.62, Аноним (17), 17:08, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    и в мейк файл MAKEOPTS=-j256
     
  • 1.69, Аноним (83), 18:59, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Надеюсь в апстрим не примут. Всё замечательно параллелится мейком, усложнение кода не оправдано.
     
  • 1.86, Griggorii (?), 07:25, 16/09/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Берешь 16 ядерный проц и ssd диск ставишь make -j16 и все быстро , а если у тебя проц 2 ядерный то выставить ты можешь только make -j2 или же хоть make -j32 все равно будет работать как j2 потому что проц двух ядерный , а не ишь че захотел 32 ядерный 32 потока. Но это ладно мне вот интересно что компилятор все время проц требует чем много процессорнее тем лучше , а где хоть один созданный компилятор который будет требовать скорость диска и чем больше скорость ssd тем быстрее было ехало , т.е я примерно докину свою мысль если бы я знал как программить компилятор то я бы драйвер процессорности заменил на драйвер диска.
     
     
  • 2.89, Аноним (89), 10:36, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Рекомендуется -j(n+1)
     
  • 2.95, Аноним (17), 16:53, 16/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так то да. Можно рискуть еще активизировать funroll-loops 03, а лучше выставить все возможные опти флаги
     
  • 2.99, Аноним (99), 13:03, 17/09/2019 [^] [^^] [^^^] [ответить]  
  • +/
    На Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz (4 ядра & даблтред) gcc 9.2 в полном комплекте собирается полчаса в 16 потоков make (make -j 16) при неполной загрузке дисковой подсистемы.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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