https://www.opennet.ru/openforum/vsluhforumID3/126376.html Инго Молнар (Ingo Molnar) представил вторую версию набора патчей, позволяющего значительно сократить время пересборки ядра за счёт реструктуризации иерахии заголовочных файлов и сокращения числа перекрёстных зависимостей. От предложенной несколько дней назад первой версии новый вариант отличается адаптацией для ядра 5.16-rc8, добавлением дополнительных оптимизаций и реализацией поддержки сборки с использованием компилятора Clang. При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77% в показателях расходования ресурсов CPU. При полной пересборке ядра командой "make -j96 vmlinux время сборки сократилось с 337.788 до 179.773 секунд...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=56475<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#61 Tue, 11 Jan 2022 23:31:14 GMT фантастика что новости уже пару дней, а про 96 и 69 еще никто не пошутил :(<br>не играет гормон и это печально, стареете<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#59 Tue, 11 Jan 2022 22:29:43 GMT Да забей. "Свинья везде грязь найдет"<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#58 Tue, 11 Jan 2022 16:52:15 GMT -j96?? ребята на ЭПЫКах сидят, поди...<br><br>PS: почистили ненужное инклюдное Г - молодцы. Я тоже так делал. Кучу лет назад. Вручную. А когда завезли многопоточность, проект стал компилиться за минуту вместо получаса )<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#57 Mon, 10 Jan 2022 20:28:03 GMT &gt; сломанный blame<br><br>Это такая дешёвая придирка, что просто смешно. Случаи, когда git blame за один заход помогает найти оригинального автора настолько редки, что можно смело считать, что такого не происходит никогда. Всегда после запуска git blame нужно проверять патч, чтобы выяснить суть изменений. Иногда это реструктурирование кода, иногда функции приобретают или теряют аргумент. Иногда приличный кусок кода смещается вправо или влево, потому что добавился или исчез "if". Всегда нужно проверять патч.<br><br>В долгоживущих проектах git blame может состоять из более чем десятка шагов. Ещё один шаг погоды не делает.<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#56 Mon, 10 Jan 2022 10:04:53 GMT Посчитайте пропорцию от текущего времени соборки. В абсолютных цифрах на "слабых" процессорах экономия существеннее.<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#55 Mon, 10 Jan 2022 07:43:10 GMT кому ты интересен - когда IBM сказало пилить ?!<br>у них на power тормозит.<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#54 Mon, 10 Jan 2022 07:09:13 GMT Ну, тогда тут немножко шире, чем ломает-не ломает, раз мы в дебри полезли.<br><br>- Собранному софту не поплохеет, userspace API не ломается<br>- В исходниках софта, завязанного на include хедеров ядра, возможно, потребуются правки<br>- В исходниках сторонних модулей ядра, скорее всего, потребуются правки<br>- Собранные сторонние модули ядра традиционно сломаются :), но не из-за конкретных изменений, а просто потому, что их всё равно под каждую конкретную версию ядра собирать надо<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#53 Mon, 10 Jan 2022 02:44:07 GMT j96 круто конечно, а на более доступных Core i5 какое время этот патч сэкономит?<br> https://www.opennet.ru/openforum/vsluhforumID3/126376.html#52 Mon, 10 Jan 2022 01:27:04 GMT &gt; это тот анекдот - "подожди сейчас дискету доформатирую" но для Linux <br><br>Ты можешь анекдот, как угодно перекладывать. Ну а linux можно тюнить под задачи - хочешь что-бы тормозило, как в форточках95 при форматировании дискет, можешь и под это затюнить - никто тебя в этом не ограничивает.<br>