Как стать автором
Обновить

Комментарии 49

мы помним

про hyper-threading нужно в основном помнить, что эффект от него очень специфичен для конкретных задач и их комбинации; и бывает, что он ускоряет даже больше, чем на 20–30 %. Поэтому рекомендация обычно крайне простая: не хочется сюрпризов, отключать его. Хочется, но приятных — тестировать.

Что касается «честного деления», то многое будет зависеть от планировщика. Поэтому запускать «паразитную» нагрузку в том же движке RDBMS, это основной подозрительный момент. Понятно, что так имеет смысл проверять тоже, но прежде, чем говорить за весь hyper-threading, было бы неплохо запустить её «снаружи». И сравнить.

Попробую попозже, отпишусь

Добрый день. Для понимания механики работы процессора, очень рекомендую ознакомиться с сановской документацией на процессоры т1 или т2. Очень хорошая документация, так же содержит микро код процессора. Так же у сановцев, можно почитать доку о работе ядра Unix. Но это будет интереснее тем, кто сидит на никсах. Не так давно на глаза попадался пакет документации на амдшные камни, к сожалению на интел документацию не находил. Несколько лет назад, попадался на глаза профилировщик цпу.

Например у вас 2 задачи , первая, некая запись на диск, а вторая икримент в бесконечном цикле. Если все измерять в процессорных тактах, то инкримент будет дешевле, то и получать ресурсы ядра он будет чаще. Плюс потери при переключении контекста, это очень дорого. НТ это не в в чистом виде 50/50 или как то ещё. Микро код, должен проводить анализ инструкций и в оптимальном варианте должен распределить инструкции так по потокам, что бы не было большого простоя на ядре. Но к сожалению и планировщик может ошибаться. А могут быть на ядре и равновесные инструкции или данные еще не подготовлены или ещё, что либо. Вот и получается, что теоретически вроде бы два потока оптимизированы относительно друг друга, а по факту получается барак. В трех словах, как то так.

см update в конце статьи

Если я правильно прочёл, то там нет теста «H/T включен && паразитная_снаружи» — ?…

И опять же, если правильно понимаю, вопросики больше к RDBMS, нежели к H/T.

Это да, больше к базе вопросов. А HT назад я пока не включал чтобы ещё одну колонку сделать

И опять же, если правильно понимаю, вопросики больше к RDBMS, нежели к H/T.

Угу, выглядит так что mssql ведёт себя крайне странно.

Я знаю этот эффект, работал на 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)

Посмотрите статистику cpufreq-info. Если предположение подтвердится, переключите планировщик на performance и проверьте, сохранится ли такое поведение системы.

На выделенных SQL я тоже как-то пришёл к выводу, что HT надо отключать. Но немного с другой логикой - пытая МС насчёт лицензирования (там тоже толком не могли нормально ответить, а гайд написан в максимально далёких от самой системы терминах наподобие Virtual processors - Virtual cores что похоже одно и то же) и распределения нагрузки под 70%+, выяснилось что получаем систему которая начинает подтормаживать, но платим мы как за честные ядра.

Для чистоты эксперимента не хватает такого же запуска на своем компе с выключенным HT

Вот если он не покажет такое замедление, то будет удивительно. А если и он замедлит - то просто очередной "HT бесполезен" (но не вреден!!)

Да, надо сделать мне

см update в конце статьи

Это давно известный факт. Особенно для процессоров 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 померю. А субд, процедуры и Яндекс облако возникло не просто так, это расследование проблемы

Это MSSQL-фетиш

Да, я везде вижу гвозди)

см update в конце статьи

Из вашего update напрашиваются совсем другие выводы чем вы изначально делаете в статье.

Вероятно

Чтобы эксперимент считался корректным, Вы должны были повторить его с отключенным HT. Если просадки не будет, то Вы правы. А пока лишь вывод «не запускайте числодробилку в сервере БД».

см update в конце статьи

Часть про тестирование на облаке можно без зазрения совести выкидывать, никто не знает какая там реально виртуальная кухня.

Часть на физической машине интересная, но неполная без контрольного эксперимента, о чем тут уже многократно написали (ну и не стоит при этом забывать мониторить влияющие параметры, температуру проца, например).

Ну и хотелось бы потом увидеть тесты с реальной нагрузкой.

см update в конце статьи

После прочтения статьи, для эксперимента, попробовал снизить количество потоков, используемых при одном тяжелом расчете на nodejs с 31 до 16. По количеству ядер на Ryzen 9 3950X, на котором вычисления производятся. Затраты времени увеличились с 265 сек. до 282 сек. HT потоки вообще практически ничего не давали. 32 потока я не использовал давно, так как использование 32 потоков давало очень сильную просадку по скорости. Скорее всего оркестрирующий процесс не успевал обрабатывать сбор финальных данных.

Скорее всего оркестрирующий процесс не успевал обрабатывать сбор финальных данных.

Ну и при чём тут HT...

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории