Комментарии 49
мы помним
про hyper-threading нужно в основном помнить, что эффект от него очень специфичен для конкретных задач и их комбинации; и бывает, что он ускоряет даже больше, чем на 20–30 %. Поэтому рекомендация обычно крайне простая: не хочется сюрпризов, отключать его. Хочется, но приятных — тестировать.
Что касается «честного деления», то многое будет зависеть от планировщика. Поэтому запускать «паразитную» нагрузку в том же движке RDBMS, это основной подозрительный момент. Понятно, что так имеет смысл проверять тоже, но прежде, чем говорить за весь hyper-threading, было бы неплохо запустить её «снаружи». И сравнить.
Попробую попозже, отпишусь
Добрый день. Для понимания механики работы процессора, очень рекомендую ознакомиться с сановской документацией на процессоры т1 или т2. Очень хорошая документация, так же содержит микро код процессора. Так же у сановцев, можно почитать доку о работе ядра Unix. Но это будет интереснее тем, кто сидит на никсах. Не так давно на глаза попадался пакет документации на амдшные камни, к сожалению на интел документацию не находил. Несколько лет назад, попадался на глаза профилировщик цпу.
Например у вас 2 задачи , первая, некая запись на диск, а вторая икримент в бесконечном цикле. Если все измерять в процессорных тактах, то инкримент будет дешевле, то и получать ресурсы ядра он будет чаще. Плюс потери при переключении контекста, это очень дорого. НТ это не в в чистом виде 50/50 или как то ещё. Микро код, должен проводить анализ инструкций и в оптимальном варианте должен распределить инструкции так по потокам, что бы не было большого простоя на ядре. Но к сожалению и планировщик может ошибаться. А могут быть на ядре и равновесные инструкции или данные еще не подготовлены или ещё, что либо. Вот и получается, что теоретически вроде бы два потока оптимизированы относительно друг друга, а по факту получается барак. В трех словах, как то так.
см update в конце статьи
Если я правильно прочёл, то там нет теста «H/T включен && паразитная_снаружи» — ?…
И опять же, если правильно понимаю, вопросики больше к RDBMS, нежели к H/T.
Реквестирую следующую часть - "я выдал виртуалкам меньше ядер, и стало не медленнее, а быстрее", в главной роли vsphere cpu scheduler.
Я знаю этот эффект, работал на VMware. Но я не хозяин Яндекс клауда, они темнилы и я не знаю, с каким недовесом они продают ядра
Интересно а если в главной роли KVM (в Proxmox'е) и медленно становится периодически если софт в VM реально начинает например компилировать код или транскодить - производительность более менее растет соответственно количеству ядер VM а вот до этого - несколько вкладок хабра в Chrome или там файлов в IDEA/Android Studio и загрузка в десятки процентов а навигация в той AS - тормозит. Причем иногда все же работает нормально (HyperThreading в данном случае - не причем, он отключен, Proxmox считает что ресурсы есть).
Звучит похоже на вопросы к управлению частотой на хост-системе. Планировщик считает систему недогруженной и сбрасывает частоты?
на хост-системе 2xXeon(R) CPU E5-2680, загрузка cpu - 40-70%(там и кроме Windows есть виртуалки, ядро Linux 6.8.12-2-pve (2024-09-05T10:03Z)
На выделенных SQL я тоже как-то пришёл к выводу, что HT надо отключать. Но немного с другой логикой - пытая МС насчёт лицензирования (там тоже толком не могли нормально ответить, а гайд написан в максимально далёких от самой системы терминах наподобие Virtual processors - Virtual cores что похоже одно и то же) и распределения нагрузки под 70%+, выяснилось что получаем систему которая начинает подтормаживать, но платим мы как за честные ядра.
Для чистоты эксперимента не хватает такого же запуска на своем компе с выключенным HT
Вот если он не покажет такое замедление, то будет удивительно. А если и он замедлит - то просто очередной "HT бесполезен" (но не вреден!!)
Это давно известный факт. Особенно для процессоров intel. Проблема вызывается делением, т.к. блоков целочисленного деления в них мало. Если хотите ускорить вычисления уберите деление из вычислительных потоков которые исполняются на одном ядре или разнесите их на разные ядра, комбинируя с потоками которые не используют целочисленное деление.
SQL Server: "Погоди ты со своими вставками, мне тут надо простоту проверить, я быстро" :)
Только мое мнение.
Например, AMD 7 9700x имеет:
Cache L1:80 KB (per core)
Cache L2:1 MB (per core)
Cache L3:32 MB (shared)
то есть при отключении половины тредов другая половина имеет в два раза больше кэш памяти. То есть оставшиеся половинки более производительные. Конечно, если программа не адаптирована на многопоточность. А такое бывает.
Это правильно, если делать при этом перф-тесты характеризующие целевые шаблоны нагрузок, что мягко говоря огромная работа. Долбать софт крэшполом парой запросов - это совсем не вся картина.
Но у вас как это то однобоко.
Но, нет программ "адаптированных на многопоточность" (они есть но они адаптированы под топологии, а не конкретно SMT) - если программа перемалывает 50GiB/секунду данных значит и IO и контроллер(ы) памяти должны это обеспечить. Если программа хочет 200GiB+/секунду - то... В любом случае никакого кэша не хватит. Понятно, что увеличение кэша даст что-то, но на большем масштабе он не играет ключевую роль, и увеличение его размера имеет как это по русски - убывающую отдачу, всегда есть точка оптимального размера. Это подобно как выровненный доступ к памяти предпочтительнее других, но как только граф объектов становится слишком большим - уменьшение его размера за счет сжатых указателей, не выровненного доступа и любых других трюков - дают суммарный линейный выигрыш, просто потому что на единицу времени получается протащить больше логических единиц.
CPU Load, % - плохая метрика, она называется по "нормальному" non-idle time. Однако когда процессор non-idle - это еще не значит, что он что-нибудь делает. Он может просто ждать, например памяти. И таким образом эта нехитрая метрика сама по себе мало что объясняет. Кроме того она обычно усредненная, благодаря чему можно неразглядеть пики.
Таким нехитрым образом при вопросе что же делает процессор - нужна как минимум метрика IPC (instructions per cycle), stalls, ну и много прочих.
Похоже мы приходим к тому моменту когда понимание того, как оно работает, не важно, важно брать готовое и использовать. Нет ну правда, последне время завал статей на тему, что гейткиперы ничего не понимают и современному разработчику не надо ничего знать о том как все оно на самом деле работает.
Если взять и посмотреть внимательно, что же это такое HT, то можно грубо написать, что планировщики разные, а исполнение одно, и если тупо забить исполнение ненужной работой, то естественно для рабочей нагрузки просто не будет исполнителей.
Для чистоты эксперемента, отключите HT и сделайте 4 полезных потока и 4 забивающих исполнительные устройства, может тогда вы поймете, что все работает немного не так, как вы представляли.
На самом деле вы как то слабо зашли, надо было уже в асемблер, и нагрузить в цикле вычисления одновременно на пяток интов, 3-4 из них на простое +-, 1-3 на /*, к ним привязать FP на деление, штуки 2-3, все это отполировать avx тоже на 2-3 вычисления. А главное развязать все это дело по регистрам с которыми оно работает. И тогда бы вы познали дзен, когда все стоит колом, хотя вроде оно должно 20-30 процентов в плюс и вообще работать без тормозов.
Банальный тест на математику: Linpack/LinX не показывает прироста от SMT. Но это же не значит, что для повседневной разнотипной(!) многозадачности лучше отключить SMT, "потому что толку нет".
Для меня в свое время именно это было озарением, сведя это к вами написанному, стал иначе смотреть на внутренности описываемых микроархитектур у процессоров в железных статьях.
взять игры допустим, придётся разбираться
если анриал то с интерфейсом - придётся разбираться в любом случае в таких азах какие структуры, какие алгоритмы
если библиотека придётся всё равно разбираться
интерес и любопытство даёт возможность научиться еще плюс ко всему
попробуйте например взять высоту террейна - загруженного от карты высот и просто считайте текущую высоту от половины нормали террейна допустим, это иллюстрация простого експеримента которая может упростить решение коллизии например
Проблема в том, что разбираться как раз и нет желания.
Вот есть аксиома, что HT дает 20-30% к производительности и этого достаточно.
А если чуть копнуть и понять как оно работает реально, то многое станет на свои места.
Если брать именно HT то первый раз я поспорил на эту тему году по моему в 2005, и с тех пор, изменилось мало чего, все время от технологии ждут неведомых чудес.
Иногда нужно просто решать задачу :). А потом всплывает что-то неучтенное.
И внезапно всплывает что как работает HT (или как бывает устроена память в серверах с кучей ядер, особенно если сокетов - хотя бы два и почему NUMA это важно) - стоит все же знать. И хорошо если хотя бы понимаешь что проблема может быть и адекватные источники что почитать.
В идеале конечно ОС (ну или гипервизор если у нас ОС не на голом железе) должна такие вещи учитывать...и делать хорошо :(
А еще в современных процессорах бывают энергоэффективные ядра. И при высокой нагрузке на процессор может оказаться, что нагружены только производительные, а энергоэффективные простаивают. Выглядеть это может так, что программа не успевает делать свою работу, а процессор нагружен на 50%.
при высокой нагрузке на процессор может оказаться, что нагружены только производительные, а энергоэффективные простаивают
Это как раз нормально. А вот плохо будет - когда часть нагрузки раскидывается на эти ядра, а для решения некоторой задачи нужно провести несколько последовательных расчётов. Тогда P-ядра быстро решат свою часть задачи и будут простаивать в ожидании расчёта на E-ядрах. Я с этим в ANSYS влип.
Причём по умолчанию распределение ядер непрозрачное: запускаешь расчёт на 12 ядрах - он берет не 12 P-ядер, а цепляет E-ядро, и всё.
Хотя бы Е ядра можно вырубить вообще
Это реальная проблема программ, умеющих SMP и не знающих про ASMP.
У Apple поначалу такое было в OpenMP на силиконе (из-за чего собственно Apple официально не поддерживала OpenMP и продвигала свой фреймворк), из-за чего приходилось руками ограничивать степень параллелизма. Но потом они научились автоматически как-то разруливать.
Нафига в десктопных и уж тем более в серверных процессорах энергоэффективные ядра, знает только маркетолог Интела.
Вообще, если нужна энергоэффективность, надо переходить на ARM-процессоры.
Хотелось бы уточнить у Автора, Какая модель процессора использовалась в домашнем сервере.
Есть различие в реализации SMT (от AMD) и HT (от Intel) и когда-то у SMT была более производительной чем HT.
Есть пара мыслишек.
1. Если отключать SMT/HT то потоки, которые исполнялись на одном физическом ядре могут начать обмениваться информацией между собой медленее. У AMD например есть проблема межъядерного взаимодействия между разными CCD. И если потоки "любят" обмениваться информацией между собой, не приведёт ли отключение SMT к ухудшению попадания потоков на один CCD? Понимаю вопрос специфический и вряд ли относится к СУБД.
2. Если отключать SMT насколько будет влиять "увеличение" кэшей для потока.
И ещё, насколько я помню у IBM в их процессорах реализована вообще 4х или даже 8ми поточная виртуализация ядер. Или я путаю с Sun Microsystems. Там тоже 8ми поточная была реализована?
Кроме того, наблюдая как AMD развивает микроархитектуру в Zen 5, складывается ощущение, что они таки хотят увеличить до 4-х многопоточность ядер. Ну и в перспективе конечно увеличить количество физических ядер на один CCD до 16, как это уже реализовано в свежих Zen 5c в процессорах Epic со 192 ядрами.
Intel(R) Core(TM) i7-2700K CPU @ 3.50GHz 3.50 GHz
2012 год (рука лицо)
Но я не играю в игры, я админ, а для Remote Desktop это хватает за глаза
Наличие Hyper-Threading в процессоре Intel предполагает, что один из потоков вычислений, обрабатываемых его ядром, является основным. Второй поток выполняется только в те периоды времени, когда ресурсы ядра по каким-то причинам не полностью заняты или временно не заняты основным потоком (оста́точный принцип). В некоторых случаях, на второй поток может приходиться до 50% ресурсов ядра. Но такое бывает не часто. В приложениях, в которых основной поток эффективно использует ядро, пользы от Hyper-Threading будет значительно меньше. В среднем, этот показатель составляет около 20-30%. В процессоре без Hyper-Threading эти ресурсы попросту не используются.
Результаты тестов дают основания считать, что алгоритм работы Simultaneous MultiThreading, используемый в процессорах AMD, отличается от Hyper-Threading в сторону большего равноправия обоих потоков. В одних приложениях это себя оправдывает (рендеринг), в других - приводит к снижению производительности (видеоигры).
https://overclockers.ru/blog/Vital-uK/show/21103/sravnenie_effektivnosti_hyperthreading_i_smt
https://www.phoronix.com/review/amd-ryzen-zen5-smt/2
Какой же треш. Зачем-то приплетённая в задачу СУБД, винда, какие-то хранимые процедуры, яндекс-облако, непойми какой проц, отсутствие замеров с собсна отключенным HT, гадание о причинах без каких-либо подтверждений гипотезы...
Чтобы эксперимент считался корректным, Вы должны были повторить его с отключенным HT. Если просадки не будет, то Вы правы. А пока лишь вывод «не запускайте числодробилку в сервере БД».
Часть про тестирование на облаке можно без зазрения совести выкидывать, никто не знает какая там реально виртуальная кухня.
Часть на физической машине интересная, но неполная без контрольного эксперимента, о чем тут уже многократно написали (ну и не стоит при этом забывать мониторить влияющие параметры, температуру проца, например).
Ну и хотелось бы потом увидеть тесты с реальной нагрузкой.
После прочтения статьи, для эксперимента, попробовал снизить количество потоков, используемых при одном тяжелом расчете на nodejs с 31 до 16. По количеству ядер на Ryzen 9 3950X, на котором вычисления производятся. Затраты времени увеличились с 265 сек. до 282 сек. HT потоки вообще практически ничего не давали. 32 потока я не использовал давно, так как использование 32 потоков давало очень сильную просадку по скорости. Скорее всего оркестрирующий процесс не успевал обрабатывать сбор финальных данных.
Катастрофическое падение производительности из-за hyperthreading