Comments 10
А зачем в $(sysctl -n hw.physicalcpu) + 1 добавляется еденица? Или на маке при одном ЦПУ там ноль?
В команде “make -j”, параметр определяет количество джоб для параллельного вычисления. Верхнее ограничение необязательно определяется количеством доступных ядер или потоков процессора. Максимально допустимое число джоб зависит еще от количества доступной памяти, сколько каждая джоба памяти потребляет, I/O задержки и тд.
Так как сложно выделить метрику, сколько реально джоб оптимальней всего запустить, то обычно привязываются на количество ядер. Но можно поставить количество джоб чуть выше и это может ускорить процесс.
Вот тут об этом детальней обсуждают: https://unix.stackexchange.com/questions/208568/how-to-determine-the-maximum-number-to-pass-to-make-j-option
Так я поэтому и спросил, зачем берется больше на один процесс, который будет бегать по ядрам, трешить кэш и всем мешать?
Я не знаю детально как работают джобы под капотом, поэтому сложно что-то сказать. Но я сделал пару итераций, чтобы сравнить результаты:
time make -j "$(($(sysctl -n hw.physicalcpu)))"
>make -j "$(($(sysctl -n hw.physicalcpu)))" 2066.41s user 136.78s system 739% cpu 4:58.08 total
time make -j "$(($(sysctl -n hw.physicalcpu)))"
>make -j "$(($(sysctl -n hw.physicalcpu)))" 2040.59s user 135.83s system 734% cpu 4:56.25 total
time make -j "$(($(sysctl -n hw.physicalcpu) + 1))"
>make -j "$(($(sysctl -n hw.physicalcpu) + 1))" 1939.44s user 131.89s system 730% cpu 4:43.57 total
time make -j "$(($(sysctl -n hw.physicalcpu) + 1))"
>make -j "$(($(sysctl -n hw.physicalcpu) + 1))" 2026.15s user 138.11s system 716% cpu 5:01.90 totalРазброс получается слишком большой, чтобы можно было дать статистически значимый результат)
Про мак не скажу, не использую, но в линуксе добавление единички поверх количества логических(а nprocесли у тебя HyperThreading возвращает количество ядер умноженное на два) процессоров чаще всего помогает чтобы быстро работало на виртуальных машинах в хостинге.
Собственно у тебя есть два три варианта как распараллелить компиляцию:
1. Минимальное по CPU: количество джоб равно количеству процессоров - меньше делать не стоит по причине того что все что меньше будет работать медленее
2. Максимальное по CPU: количество джоб равно количеству процессоров умноженному на 2 - больше делать не стоит по причине того что ты точно не знаешь какие из задач компилятора требуют максимальной нагрузки на процессор, а какие на подсистему ввода вывода и большее количество джоб уже будет радикально снижать производительность.
3. Оптимальное по памяти: количество джоб равно количество RAM в гигабайтах деленное на 2 или 4 в зависимости от наличия HT.
На своём компьютере ты должен в зависимости от конфигурации самостоятельно подобрать это число (ну если ты используешь линукс постоянно). Оно у тебя будет больше того что в пункте 1, но меньше чем в пункте 2. Если у тебя число 3 меньше чем 1 - то на компьютер нужно добавить памяти.
Вот в советах всегда советуют нижнюю планку + 1 просто потому что с большой долей вероятности это будет оптимальный вариант на незнакомой конфигурации, а также для облака. На своём компе который ты постоянно используешь ты конечно же должен уже знать точное число )
P.S. Судя по всему для мака будет всегда использоваться количество физических процессоров, в то время как для линукса - логических. Это наводит на мысль что люди перепечатывают инструкции не думая )
@zepars, в итоге получается, когда нод full-RBF будет больше половины, то такие транзы будут добавляться в блокчейн?
Да. Причем помимо Bitcoin Core с включенным full-RBF, есть еще неофициальные ноды, которые тоже могут поддерживать эту функцию (например, Bitcoin Knots). На текущий момент подключенных к сети кастомных нод – 7.3%
И в этом случае биткоиноматы станут уязвимыми? Или в них можно будет добавить защиту на проверку этого параметра замены транзакции?
В этом случае (хотя и сейчас для перестраховки надежней так делать) надо дождаться, когда майнер создаст блок и добавит туда транзакцию. Появление нового блока в среднем занимает 10 минут, а может продлиться и вовсе до 40, поэтому некоторые бизнесы не дожидаются этого и сразу засчитывают транзакцию на этапе попадания ее в мемпул.
Относительно или безотносительно описанного функционала, может быть, кто-нибудь может порекомендовать веб-GUI к Bitcoin Core? С QT как-то исторически не сложилось.
Проверяем работает ли full-RBF в Bitcoin