но при этом очень важный показатель это скорость работы жесткого/ssd диска (лучше конечно ssd)

Если хватает памяти, то tmp монтируется в tmpfs и это решает проблему обращения к диску сводя его только к случаям распаковки и установки.

Исключение для пары пакетов возможно придётся сделать: требующих xattr и слишком больших.

И задался вопросом, если начинка одна и таже, материнки АТХ, micro АТХ или mini ITX будут компилять генту одинаково быстро?

Время компиляции давно уже зависит от частоты и количества ядер в процессоре. Почти не зависит от частоты памяти. Практически не зависит от скорости доступа к внешним носителям tmpfs/SSD/HDD, так как операционная система обеспечивает кэширование рабочих данных в памяти.

От плат зависит теплорассеяние зоны VRM. Оно зависит от количества мосфетов и дросселей, участвующих в преобразовании напряжения питания для процессора — от количества линий, образующих фазы питания для процессора и встроенного в него контроллера памяти (северный мост, SoC) и встроенного графического ядра (если есть). Чем больше элементов и чем большую площадь они занимают, тем легче справляется преобразователь с нагревом, тем выше у него КПД преобразования.

И если возьму mini ITX греться же сильно все не будет, если с водянкой?

Да.

У тебя просто проц слабый. На чуть более шустрых уже заметно.

hdd, на ssd и в tmpfs, разницы заметной не было

Могу сказать, что на чтении ебилдов и исходников есть разница. А дальше, если памяти достаточно, то все закешируется, поэтому разницы почти нет.

В nvme вообще нет особого смысла, если только это не интеловский 3dxpoint

NVMe SSD уменьшает латентность доступа нескольких приложений к различным файлам. Так как очередей доступа больше одной, то всё происходит параллельно и быстро. Грубо говоря, для пользователя десктоп с NVMe SSD, на котором размещены приложения и конфигурационные файлы для них, превращается в нечто подобное смартфону по времени реакции. Для обычного SATA SSD таких ощущений нет — там одна очередь обработки транзакций чтения/записи, доступ осуществляется последовательно, отсюда и задержки.

Цифры, сестра, цифры!

Но это был 8-поточный Core i7 с частотой под 4 ГГц.

минута разницы на фоне 2 часов компиляции.

У меня core i3 2010 года с древним hdd на 40 Гб 2 часа сейчас собирает gcc, а ты мне заявляешь о 2 часах на core i7 4 ghz.

не буду утверждать точно надо перепроверить, но amd 7 2700 на 14 потоках на NVME - делает это примерно за 30 минут

Верю, т.к. на core i7 2014 года это минут 40 занимает с хардом.

Заметную разницу в несколько минут я замечал уже при сборке boost в tmpfs и hdd. Может с ssd вместо hdd это менее заметно, но это уже и не минута на фоне 2 часов.

Ну не компилированием едины.
RGB не нужно - отключается. WIFI - меньше проводов. Z390 - максимальная частота в бусте - не помешает. GAMING - нафиг не нужен.

вообще выбираю между
https://www.idealo.de/preisvergleich/OffersOfProduct/6334726_-rog-maximus-xi-gene-asus.html
и
https://www.idealo.de/preisvergleich/OffersOfProduct/6334096_-rog-strix-z390-i-gaming-asus.html

Hу нужно было написать «причину»…
Hу вот начинку выбрал (выше писал), а какую плату незнаю.

Вот приблизительно такое я и понял с интернетов.
Tо есть miniITX нагрузить по полной не получится, так как перегрев будет приводиться к понижению работы/частот процессора.
Бывает сутки в месяц все ядра загружены на 100%

максимальная частота в бусте - не помешает

Как хочешь, но, вроде, многоядерный буст уныл.

То про Libreoffice было

Mне не нужен многоядерный, достаточно будет сингл.

Bот писал выше:
A еще хочется уменьшить latency для внешней аудио карты. Hо как, даже представления не имею…
Предполагаю что макс. буст в сингле - и претензий к ПК не будет.

Подтверждаю. Важен только проц. Всё остальное <5%

но при этом очень важный показатель это скорость работы жесткого/ssd диска

/var/tmp/portage в tmpfs решает

при сборке boost

А что там собирать? Там просто 15к файлов.

Не знаю как у интела, но у amd разницы между B и X нет.

Вот тут материнские платы для AMD https://docs.google.com/spreadsheets/d/1d9_E3h8bLp-TXr-0zTJFqqVxdCR9daIVNyMatydkpFA/htmlview?sle=true#gid=0 mITX и mATX как видно обладают меньшим количеством фаз питания процессора. Но с 3000 евро можно смотреть на тридрипперы вплоть до 3970x. Там ядер и их скорости столько, что Firefox или Libreoffice будут собираться минут за 10. Но лучше уж смотреть в сторону 3950x на AM4. Звуковая карта с внешним блоком Sound Blaster AE-9 обладает превосходными показателями в качестве звука со своими 129дб. И не придется париться по поводу латентности USB. Таким образом оптимальная конфигурация выглядит Gigabyte X570 Aorus Elite (Master) + Ryzen 3950x + Sound Blaster AE-9.

Например, я.

Не рассматриваю Intel.

Cпасибо за рекомендации, но комплектующие выбраны.
Bопрос только остался в формфакторе материнки и ее эфективности.

Звуковую карту точно менять не буду.

У интела B — business, то есть вообще печально. H — как Z, но без разгона. Нормально, если оный не нужен. Z соответственно с разгоном.

Ссылка для оценки качества VRM недорогих мат.плат: https://forums.overclockers.ru/download/file.php?id=167055&mode=view

Вот тут графики можно посмотреть для сравнения 3950x с 9900k(s). https://www.youtube.com/watch?v=stM2CPF9YAY Мозги то на что? Если комп не для игр исключительно, то выбор комплектующих это не последовательный процесс, а комплексный. Потому что в мультипотоке, то есть компиляции 3950x в 2 раза обойдет 9900. Дальше там можно никому не втирать для чего комп, если вопреки здравому смыслу лучшее отметается в пользу того, что уже «выбрано».

Он хорошо нагружает все ядра. По крайней мере это единственный пакет, при сборке которого летом 2010 года (на улице было под 35) боксовый кулер phenom ii 955 x4 не справлялся с охлаждением и температура повышалась до 62.

SUPERO Pro Gaming C9Z390-PGW

👍

Вопрос изначально стоял вo влиянии форм фактора материнки при максимальной нагруженности проца на эффективность системы в общем

Согласен!

Формфактор тут мало влияет, больше зависит от используемых компонентов.

iZEN все по делу написал.
Выбор материнки для генту (комментарий)

Вопрос только в том, на сколько этот перегрев будет влиять на все.
используемые компоненты писал выше.

И сколько по времени у вас занимает сборка boost-libs-1.71.0 на текущей конфигурации?

На той, на которой sys-devel/gcc-9.2.0 собирался 2 часа (USE=«cxx fortran multilib nls nptl openmp pch pie sanitize ssp vtv»), пакет dev-libs/boost-1.71.0 (USE=«bzip2 icu nls python threads zlib» ABI_X86=«32 64» PYTHON_TARGETS="python2_7 python3_6) собирался 28 минут. Но здесь следует учесть, что он при этом собирался 2 раза: для x86_32 и x86_64.

Налей масла в аквариум и опусти туда мать. Вот тебе и охолаждение. Пассивное. И всё. Вода, не вода. Теплоноситель.

Перегрев в маленьком корпусе будет влиять сильно потому что водянка с процессором жрущим 250вт справится, а вот vrm будут наверное жариться при температуре 100+ градусов, если не взять шестифазное качественное питание с удвоителями. Так что если мозг включится поглядеть на цифры и сравнить что больше жрет при длительной максимальной нагрузке и на каких частотах работает 9900 или 3950x. Названия плат на x570 и z390 должны совпадать и иметь почти одинаковое питание процессора. Впрочем, если нравится рисковать, то можно хоть в самую дешевую материнку воткнуть топово потребляющий процессор. Там в табличке про амперы показано какой процессор должна выдержать материнская плата, если ее не насиловать максимальными нагрузками продолжите время в лице компиляции. То есть в игры, нагружающие процессор наполовину поиграть можно.

> pkg info boost-libs
boost-libs-1.71.0_2
Name           : boost-libs
Version        : 1.71.0_2
Installed on   : Sat Dec  7 21:21:52 2019 MSK
Origin         : devel/boost-libs
Architecture   : FreeBSD:12:amd64
Prefix         : /usr/local
Categories     : devel
Licenses       : 
Maintainer     : office@FreeBSD.org
WWW            : https://www.boost.org/
Comment        : Free portable C++ libraries (without Boost.Python)
Options        :
	DEBUG          : off
	ICONV          : on
	ICU            : on
	OPTIMIZED_CFLAGS: off
Shared Libs required:
	libicui18n.so.65
	libicudata.so.65
	libicuuc.so.65
Shared Libs provided:
	libboost_stacktrace_noop.so.1.71.0
	libboost_random.so.1.71.0
	libboost_prg_exec_monitor.so.1.71.0
	libboost_math_tr1f.so.1.71.0
	libboost_unit_test_framework.so.1.71.0
	libboost_thread.so.1.71.0
	libboost_math_c99.so.1.71.0
	libboost_fiber.so.1.71.0
	libboost_serialization.so.1.71.0
	libboost_math_tr1l.so.1.71.0
	libboost_context.so.1.71.0
	libboost_contract.so.1.71.0
	libboost_stacktrace_addr2line.so.1.71.0
	libboost_wserialization.so.1.71.0
	libboost_locale.so.1.71.0
	libboost_date_time.so.1.71.0
	libboost_container.so.1.71.0
	libboost_log_setup.so.1.71.0
	libboost_log.so.1.71.0
	libboost_timer.so.1.71.0
	libboost_type_erasure.so.1.71.0
	libboost_regex.so.1.71.0
	libboost_chrono.so.1.71.0
	libboost_iostreams.so.1.71.0
	libboost_stacktrace_basic.so.1.71.0
	libboost_graph.so.1.71.0
	libboost_filesystem.so.1.71.0
	libboost_system.so.1.71.0
	libboost_atomic.so.1.71.0
	libboost_coroutine.so.1.71.0
	libboost_math_c99f.so.1.71.0
	libboost_wave.so.1.71.0
	libboost_math_tr1.so.1.71.0
	libboost_math_c99l.so.1.71.0
	libboost_program_options.so.1.71.0
Annotations    :
	FreeBSD_version: 1201503
Flat size      : 166MiB
Description    :
Boost provides free peer-reviewed portable C++ source libraries.

The emphasis is on libraries that work well with the C++ Standard
Library. Boost libraries are intended to be widely useful, and usable
across a broad spectrum of applications. The Boost license encourages
both commercial and non-commercial use.

The goal is to establish "existing practice" and provide reference
implementations so that Boost libraries are suitable for eventual
standardization. Ten Boost libraries are already included in the C++
Standards Committee's Library Technical Report (TR1) and will be in
the new C++0x Standard now being finalized. C++0x will also include
several more Boost libraries in addition to those from TR1. More Boost
libraries are proposed for TR2.

NOTE: This package does not contain Boost.Python, it's in
devel/boost-python-libs.

WWW: https://www.boost.org/

Время компиляции на Ryzen 7 1800X с выключенным SMT и задушенным энергопотреблением — 3мин10с и 35с на инсталляцию и упаковку пакета.

А пофигу. Я давно не компилировал ядра и пакеты. А зачем? Этим занимаются производители нормальных дистрибутивов и программ. То есть, пригодных для работы (а работа пользователей не включает в себя компиляцию ядра и редко включает компиляцию пакетов).

Другое дело пользователи Gentoo. Им дистрибутив нужен не для работы, а чтобы компилировать ядро или ещё что-нибудь, неважно, что, и обмениваться между собой очень важной информацией, сколько мин и с получилось.

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

Ну так, 8 ядер и сборка только под x86_64. Я пока комп обновлять не планирую, этого ещё на пару лет хватит. Если сломается, то заберу у родителей phenom ii 955 - он чуть помощнее моего и там 8 Гб, они всё равно им не пользуются.

Тестирование пакетов некоторое время разве что занимает при опакечивании, поэтому на фоне что-нибудь ещё делаю.

материнки АТХ, micro АТХ или mini ITX будут компилять генту одинаково быстро?

Я на днях пытался компилять на материнке, но почему-то не взлетело - требовала какой-то процессор. Пытался гуглить. Понял что компилять нужно на процессоре... В общем продал материнку и сейчас буду процессор покупать. Так что советую тебе не повторять моих ошибок. Бери процессор! Материнка она по ходу не нужна, т.к. в компилянии не участвует.

Oстался открытым вопрос куда это все всунуть

Я видел много лайфхаков на пронхабе бро...

Посмотрите для начала в конфигурации ядра, исходниках, документации.

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

Вообще сценариев может быть множество зачем нужно компилировать. Например убрать все лишнее чтобы быстрее работал IME при переключении раскладок если убрать графический настройщик. Нравится ждать пока включится - на здоровье. Хочется libressl - опять же мало дистрибутивов из числа нормальных будут с ним работать. Разве что Void с этим справится, а если очень нужен openrc при этом? Gentoo это для тех, кому по накатанным рельсам неудобно ездить и вообще им нужно в другую сторону, которую они сами хотят выбрать. Плата тут важна только потому, что современные процессоры могут превысить пределы нормальной работы VRM питания процессора особенно в ручном разгоне. И конечно мало смысла заниматься компиляцией тяжелых пакетов таких как Firefox, Libreoffice, Plasma, GCC, clang, rust на далеко не самых производительных процессорах. Если учесть то, что повторное опакечивание может исправлять разные мелкие огрехи пересобирать их придется чаще чем один раз при выходе новой версии. Отсюда становится понятно, что подождать 10 минут на мощном процессоре или подождать 2 часа на далеко не новом это большая разница. Но если используются только нужные пакеты время потраченное на сборку окупается стабильностью и скоростью работы, потому что оптимизации могут привести в том числе к росту производительности кроме уменьшения латентности. Весь смысл открытых исходников как раз и состоит в том, что можно сделать с ними все что угодно и получить при этом результат лучше. Нравится платить за +10% производительности двойную цену на железо - пожалуйста. Но думаю оно того не стоит, чтобы платить за кремний цену в виде аналогичного по весу слитка золота, получая результат хуже, чем от программных оптимизаций.

Нравится платить за +10% производительности двойную цену на железо - пожалуйста. Но думаю оно того не стоит, чтобы платить за кремний цену в виде аналогичного по весу слитка золота, получая результат хуже, чем от программных оптимизаций.

Смешно слышать о программных оптимизациях, когда ты компилишь кусок неоптимизированного говнокода, потому что современные программисты о его оптимизации давно не думают — аппаратные ресурсы-то не те, что в 80-90е. От того, что ты у себя в Gentoo оптимизируешь, сам по себе говнокод говнокодом быть не перестает.

Хочешь реальной программной оптимизации? Переписывай сам код, все проблемные в этом отношении его места. Сперва их найдя.

Оно зависит от количества

Нет, оно зависит от качества фаз и количества их в контроллере vrm. А для лохов вроде тебя любят лепить удвоенное количество дросселей, а удвоенное количество транзисторов это вообще считай стандарт.

На некотором коде -march=native -O3/-Ofast даёт ускорение в несколько раз, относительно дефолтных -march=x86-64 -O2.

читаю я все эти новости, обзоры…

Новости и обзоры пишут про вчерашний день и не факт, что без пиара в пользу той или иной модели.
Если же смотреть актуальные темы на форуме то даже частое упоминание проблем с относительно новыми АМД не может отпугнуть от них потребителей и привести к формированию группы обиженных ругателей, видимо действительно процессоры АМД действительно нравятся людям.

На некотором коде -march=native -O3/-Ofast даёт ускорение в несколько раз, относительно дефолтных -march=x86-64 -O2. В каких, например, программах?

Говоря в общем, я в не считаю овчинку стоящей выделки: пока на Gentoo всё только соберешь, даже не начав работать, в другой системе несколько раз успеешь использовать программу по прямому назначению, пусть и медленнее. Частный случай: пока в одной системе ты уже загрузишь готовый ролик на Youtube, в Gentoo ты только установишь видеоредактор, еще даже не начав, непосредственно, работать с видео. Это ли быстрее?

В тех, которые gcc осиливает векторизовать через avx2, но они не векторизованы разработчиками изкоробки, например.

Частный случай: пока в одной системе ты уже загрузишь готовый ролик на Youtube, в Gentoo ты только установишь видеоредактор Это если проц меделнный. У меня на старом вайн компилился двадцать минут, а на новом проце три(3) минуты. Разницы с бинарным пакетом считай нет. Какой-нибудь llvm конечно будет всё равно небыстро компилять, наверное.