| 1.1, Онаним (?), 10:44, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– | |
> Тесты на системе с CPU Intel Core i5-8250U
Это всё, что надо знать про данные исследования. Сферические теоретические кони в вакууме. Зачем оно, вообще, если сборка любого мало-мальски крупного проекта и так отлично распараллеливается тупо запуском множества процессов компиляции.
| | |
| |
| |
| 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 [^] [^^] [^^^] [ответить]
| +/– |
> То есть, никто не понимает, что разрабы пытаются удешевить (по времени, танкисты,
> по времени) управление памятью и ЦП вместо того, чтобы при компиляции
> генерировать кучу ненужных системных вызовов, только отнимающих время, и упираться по
> потолку производительности в шедулер? Пздц вы тупые, откуда вам вообще сюда
> выпустили?
Штопрастите?
| | |
|
|
|
| |
| 3.87, Аноним (87), 07:50, 16/09/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.
| | |
| |
| 4.104, Онаним (?), 11:51, 21/09/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> Компиляция, тем более распараллеленная гораздо лучше пойдет на R9 3950X.
Вот да. И даже никакого дорогостоящего перепахивания компилятора не потребуется :D, а эффект будет куда выше, чем от перепахивания для всяких мобильных i5.
| | |
|
|
| 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 +/– |
Интересно как мы так раньше всю жизнь компилировали что сабж был не нужен.
| | |
| 2.46, Аноним (43), 14:50, 15/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кто о чём а вшивый о бане. Анониму видимо невдамёк, что Hurd забросили сразу после первого выпуска Linux. То, что они делают сейчас -- предсмертные конвульсии. Какие-то жалкие попытки 1.5 анонимов допилить ядро, примерно то же, что происходит с React OS.
| | |
|
| 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 "Закон Амдала"
Да уж наверняка не выгодно, но на настольных компах на это особого внимания не обращают. Быстрее бы работало.
| | |
| |
| 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" не поможет.
| | |
| |
| |
| 3.24, Аноним (24), 13:30, 15/09/2019 [^] [^^] [^^^] [ответить]
| +3 +/– |
Оптан стоит денег, медленнее сам по себе, кэш промахи при -jX стремятся к 100%.
| | |
| |
| |
| 5.55, Аноним (90), 15:39, 15/09/2019 [^] [^^] [^^^] [ответить]
| +/– | |
> По сравнению с терабайтом RAM, это хоть как-то вариант.
И где тот оптан на терабайт?
| | |
| |
| |
| 7.91, Аноним (90), 11:52, 16/09/2019 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Тут?
Ага, спасибо. Тогда у меня следующий вопрос: сколько ангелов уместится на булавочной головке?
| | |
|
|
|
|
|
| 2.9, vitalif (ok), 11:34, 15/09/2019 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Ога. Но при этом один уберфайл скомпилится гораздо быстрее, чем куча мелких ))) потому что как раз заголовки, шаблоны и т.п. только 1 раз обрабатываются.
Это очень забавно, я всё думаю, почему до сих пор не сделали компилятор, который всё лепил бы в один файл, а потом бы его собирал.
| | |
| |
| 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.47, Аноним (43), 14:52, 15/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> С помощью его шаблончиков можно сваять сравнительно небольшой исходник, который будет компилироваться несколько минут и отхватит несколько гигов памяти.
Пример шаблона ф студию. У меня всего 4Gb, компилирую проекты на 20Gb спокойно.
| | |
|
| 1.5, Аноним (6), 11:24, 15/09/2019 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Надеюсь, это не включат по умолчанию. Бывают проекты на нескольких языках, мне нафиг не упёрлось собирать их в 146 потоков.
| | |
| |
| 2.11, Анонимный селебрити (?), 11:48, 15/09/2019 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Если ко времени выпуска впрод этот gcc м симтемой сборки будет крутится на односокетном 128-ми ядерном epyc 7003, то why not?
| | |
|
| 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.
| | |
| |
| 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 вообще. Уж что-что, а компиляция в разных процессах работает отлично, и при этом хорошо контролируется при нужде - хоть по нагрузке, хоть по памяти, хоть как.
| | |
|
| |
| 2.19, Llvm (?), 12:58, 15/09/2019 [^] [^^] [^^^] [ответить]
| +2 +/– |
Ничего против clang не имею.
Но вот его баг в актуальной версии 8.0 с двойным вызовом деструктивных при исключении в лямбде реально достаёт. Баг есть, а фиксить не спешат.
| | |
| 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.
| | |
|
| 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, гайдов куча. Может поможет кто-нибудь?
| | |
|
| 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 +/– | |
Т.е., забив четыре потока, компиляция ускорится всего в полтора раза?
Почему не приведено сравнение с вариантом, когда в четыре потока запускаются разные процессы, и какой выигрыш/проигрыш в этом случае по сравнению с новыми разработками.
| | |
| |
| |
| 3.70, Аноним (70), 19:34, 15/09/2019 [^] [^^] [^^^] [ответить]
| +/– |
надеюсь не на hdd? а то сложно предстаить какой там треск стоял:)
| | |
| |
| 4.83, Аноним (83), 01:53, 16/09/2019 [^] [^^] [^^^] [ответить]
| +1 +/– |
На HDD. Никакой не стоял. Средний объём исходника и какой это объём данных и IOPS в 30 потоков посчитать несложно, чтобы чуши больше не писать.
| | |
|
|
|
| 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.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) при неполной загрузке дисковой подсистемы.
| | |
|
|
