|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Вот допустим есть одно физическое ядро и 2 потока. Допустим 1 процесс использует одно ядро на максимум. Следовательно мы видим в общей картине, что нагрузка на процессор составляет 50%. Понятно, что все зависит от природы процесса, но я так понимаю при сложных вычислениях показатель 50% будет обманчивым? Т.е. запускаем мы второй такой же процесс на втором ядре и оказывается, что первый процесс стал работать в два раза медленнее? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.08.2016, 14:33 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
HettВот допустим есть одно физическое ядро и 2 потока. Допустим 1 процесс использует одно ядро на максимум. Следовательно мы видим в общей картине, что нагрузка на процессор составляет 50%. Понятно, что все зависит от природы процесса, но я так понимаю при сложных вычислениях показатель 50% будет обманчивым? Т.е. запускаем мы второй такой же процесс на втором ядре и оказывается, что первый процесс стал работать в два раза медленнее? Это зависит не от сложности вычислений, а от их способности распараллеливаться. В одном ядре 2 вычислителя, ALU (ну, упрощённо говоря). Планировщик выполнения пытается найти в вашем последовательном коде команды, которые могут выполнится одновременно, без ошибки в итоговом результате (то есть команды не зависят друг от друга), и выполняет их одновременно на двух ALU. Это техника в процессоростроении называется "суперскалярность". Если все команды в одном потоке могут выполнится парами, то поток будет выполняться в 2 раза быстрее. Если ни одна команда не может выполняться в паре с другой, то половина ALU будет незадействована. Гипертрединг гарантированно загружает оба ALU. Но тогда, если один из потоков хорошо параллелится "внутри себя", то гипертрединг действительно его замедлит, до двух раз в пределе. В целом почти всегда гипертрединг повышает производительность, исключения редки. Просто проверьте на конкретном ПО. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 10:56 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Спасибо, сколько не наблюдал за работой процессоров с HT, - один процесс однопоточный грузит строго 1 поток. Если запустим 4 таких процесса, то он займет все нечетные потоки (точнее сказать threads), т.е. будет выполняться на 1,3,5,7 "виртуальном" ядре. Вот в таком случае ведь нельзя сказать, что процессор загружен на половину? Хотя загружено только половина его ядер. Получается в данной ситуации явно нельзя определить, загружен на данный момент процессор на 50% или на все 100% ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 13:14 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
куда-то вас понесло... гипертрейдинг - никоим образом не есть эквивалент многоядерности. скорее некий суррогат. а точнее маркетинговый буллшит. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 17:37 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Hett, Всо было савсэм нэ так (с) Гипертридинг (а не трейдинг всё же) непрозрачен для ОС - она не отличает физические ядра от логических. Для того, чтобы он начал всерьез мешать - грубо говоря, нужно загрузить все ядра на большой промежуток времени (расчеты/видеокодирование/да SuperPi банальная). В большинстве остальных ситуаций он помогает - опять-таки грубо говоря, при включенном гипертридинге реакция ПК/сервера на управляющие воздействия от пользователя или операционной системы быстрее. И да, накладные расходы на него - отнюдь не 50%: реальные потери производительности на одно физическое ядро с включенным HT при полной загрузке всех ядер той же SuperPI - 30% и менее. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 18:12 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
a_shatsГипертридинг (а не трейдинг всё же) непрозрачен для ОС - она не отличает физические ядра от логических. Отличает. Мало того, то о чем говорит Hett легко видеть "невооруженным глазом" в Windows в Task Manager. Scheduler балансирует нагрузку по core, а не по cpu / thread. Вывод команды lscpu на одном из компьютеров. Видно, что socket, core, cpu / thread вполне себе отличаются. И о них явно знает scheduler. Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 40 On-line CPU(s) list: 0-39 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 62 Stepping: 4 CPU MHz: 1200.000 BogoMIPS: 5987.46 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 25600K NUMA node0 CPU(s): 0-9,20-29 NUMA node1 CPU(s): 10-19,30-39 ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 20:51 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Мимопроходящий, a_shats вы меня не правильно поняли, вот на картинке на сколько реально загружен CPU? Когда каждое нечетное ядро будет 100% на сколько будет реально загружен процессор физически? Я уже второй раз пытаюсь вопрос с формулировать этот, но в ответ получаю какую-то теорию. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 22:40 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
top показывает нагрузку 25%, но на самом деле нагрузка 25% или 50% ? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 22:42 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
UPD: ну не 25 он показывает, а 20, но не суть, пусть все примерно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.08.2016, 22:42 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Вопрос изначально был сильно теоретический - такие и ответы На деле - пофиг. Полностью загрузить ALU на 100% - это нужно писать __очень оптимальный__ код. Т.ч. ALU обычно загружен не на 100%, вот HyperTrading и позволяет его загрузить использует этот резерв. Теоретически, если Вы сможете написать реальную задачу, загружающую ALU на 100 - то да, Вы правы. Но в реальности, таких задач/кода __очень мало__, здесь HT и позволяет использовать простаивающие мощность ALU / CPU для параллельного выполнения фоновых задач. На практике, или CPU достаточно для решения задач (удовлетворение клиента) или нет. Какие либо проценты, это все фикция. Ну или это я воспринимаю мир исключительно черно-белым ))) IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 02:15 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
HettВот допустим есть одно физическое ядро и 2 потока. Допустим 1 процесс использует одно ядро на максимум. Следовательно мы видим в общей картине, что нагрузка на процессор составляет 50%. Понятно, что все зависит от природы процесса, но я так понимаю при сложных вычислениях показатель 50% будет обманчивым? Т.е. запускаем мы второй такой же процесс на втором ядре и оказывается, что первый процесс стал работать в два раза медленнее? Гипертрейдинг - просто еще один набор регистров в процессоре и еще один контроллер прерываний - всё. Копеечная доработка, а всё остальное - маркетинг :) ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 10:00 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Вася да ГамаГипертрейдинг - просто еще один набор регистров в процессоре и еще один контроллер прерываний - всё. Копеечная доработка, а всё остальное - маркетинг :) Экспертов развелось - плюнуть некуда, всяко в эксперта попадешь. Кухонные инженеры, блин. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 10:22 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Hett, вот неплохое объяснение, с картинками https://www.percona.com/blog/2015/01/15/hyper-threading-double-cpu-throughput/ Чувак взял 12-ядерный проц, т.е. 24 якобы ядер с включенным HT. Так вот, начиная с 8 тредов, грузящих проц, т.е. с 33% виртуальной утилизации проца, время выполнения тредова начинает расти. Вывод такой: если нужна пропускная способность проца, то HT - хорошо. Если же нужно более быстрое "время отклика", то HT надо выключать. HettПолучается в данной ситуации явно нельзя определить, загружен на данный момент процессор на 50% или на все 100% ? ну вот он и пишет, что когда с HT загрузка проца показывается как 33%, она уже реально примерно 60%. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 11:26 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Проблема действительно есть, в том что ОС не разделяет полноценные ядра и дополнительные. Также как в процессорах AMD один блок FPU на два блока ALU. На мой взгляд наилучшим решением была бы возможность управлять тем, как ОС воспринимает каждое из ядер. Например в BIOS должна быть опция не отключать hyperthreading, а как воспринимать ядро с поддержкой hyperthreading как одно или как 2. По умолчанию оставить как одно и этот вариант подойдет подавляющему большинству пользователей, а второй вариант пригодится только тем, кто занимается оптимизацией кода для hyperthreading. То же самое сделать и для AMD. Те кто занимается расчетами ставят одно ядро, те кто работает с базами данных - 2. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 11:32 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
kdv, Вообще-то он (тестирующий) там все перепутал. Конкретно - перепутал время отклика и производительность. То есть на самом деле производительность на ядро с включенным НТ меньше (при полной загрузке всех ядер), а время отклика (т.е. завершения неких малоресурсоемких (под)задач) - наоборот, лучше. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 11:35 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
HettПолучается в данной ситуации явно нельзя определить, загружен на данный момент процессор на 50% или на все 100% ?Так определить нельзя, по графикам в таск-менеджере. Если механизм суперскалярности хорошо использует все ALU, то гипертрейдинг будет даже мешать, из за дополнительных накладных расходов. А если плохо, то помогать. Определить это можно для конкретного приложения, прогнав его как нагрузочный тест с включённым и выключенным гипертрейдингом. И сравнить время. Как правило, гипертрейдинг помогает, потому что суперскалярность работает в принципе неидеально, а спекулятивное выполнение ещё хуже. Гипертрейдинг по определению эффективнее этих техник, потому что все узлы процессора используются для полезных вычислений, а не для попыток что то "выгадать", на всякий случай исполняя "бесполезные" команды. Фактически, можно сказать, что гипертрейдинг может замедлять (но может и не замедлять) работу только в одном случае - когда задача плохо распараллеивается, в остальных случаях он работает в плюс. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 12:17 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
kdvвот неплохое объяснение, с картинками https://www.percona.com/blog/2015/01/15/hyper-threading-double-cpu-throughput/ Чувак взял 12-ядерный проц, т.е. 24 якобы ядер с включенным HT. Так вот, начиная с 8 тредов, грузящих проц, т.е. с 33% виртуальной утилизации проца, время выполнения тредова начинает расти. Вывод такой: если нужна пропускная способность проца, то HT - хорошо. Если же нужно более быстрое "время отклика", то HT надо выключать.Нельзя делать такой общий вывод на основании анализа одного приложения (одного набора команд), или на своих предположениях. Автор, похоже, даже не понимает, что обычное однопоточное приложение выполняется со скоростью более одной команды за такт, и вот это как раз и делает гипертрейдинг в некоторых случаях очень полезным. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 12:23 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Hello, Alexeyvg! You wrote on 31 августа 2016 г. 13:14:13: Alexeyvg> Нельзя делать такой общий вывод на основании анализа одного приложения (одного набора команд), или на своих предположениях. поройся в архивах msdn и найди рекомендацию M$ отключать HT на MSSQL Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 13:15 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Мимопроходящий, это был типа "старый HT". был один HT, потом его убрали, а потом сделали новый. С новым таких (старых) проблем уже нет. Тем не менее, и новая HT может как давать прирост, так и делать хуже. Так что в любом случае надо тестить оба режима. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 13:46 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
всё это попытка достать из одного кармана сразу две фиги. в то время как нормальная многоядерность - каждая фига в своём кармане. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 16:32 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Мимопроходящийвсё это попытка достать из одного кармана сразу две фиги. в то время как нормальная многоядерность - каждая фига в своём кармане. Я так понимаю, что у IBM, Sun архитектур еще круче. Там thread на core до одури. Правда, скорее всего, фиги там другой системы. Но это не отменяет то, что в ряде случаев HT может быть сильно полезен. IMHO & AFAIK ... |
|||
:
Нравится:
Не нравится:
|
|||
31.08.2016, 17:00 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
авторЯ так понимаю, что у IBM, Sun архитектур еще круче. Там thread на core до одури. Правда, скорее всего, фиги там другой системы Вот, вот - смотря для чего.. Для подавляющего большинства контор, у которых приложения на винде, ну или на никсах, но х86, всякие Пауры, Чпуксы не годятся.. Я же как-то писал, что делали тестирование 1С УПП на 600 пользователей, так 2 сервака х86 в скромной набивке+МС СКЛ, вполне спокойно уделали Пауэр с ДБ\2 в 2 раза (по времени выполнения операций) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2016, 08:39 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
Leonid KudryavtsevМимопроходящийвсё это попытка достать из одного кармана сразу две фиги. в то время как нормальная многоядерность - каждая фига в своём кармане. Я так понимаю, что у IBM, Sun архитектур еще круче. Там thread на core до одури. Правда, скорее всего, фиги там другой системы. Но это не отменяет то, что в ряде случаев HT может быть сильно полезен. IMHO & AFAIK Понятно. Весь стэк состояния процессов можно засунуть в силикон. Как минимум время переключения контекстов будет нулевым. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2016, 09:59 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
МимопроходящийHello, Alexeyvg! You wrote on 31 августа 2016 г. 13:14:13: Alexeyvg> Нельзя делать такой общий вывод на основании анализа одного приложения (одного набора команд), или на своих предположениях. поройся в архивах msdn и найди рекомендацию M$ отключать HT на MSSQLПоройся в архивах msdn и найди рекомендацию M$ включать HT на MSSQL для новых процессоров и новых версий сиквела. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2016, 11:43 |
|
Поясните по гипертрейдингу
|
|||
---|---|---|---|
#18+
lockedLeonid KudryavtsevЯ так понимаю, что у IBM, Sun архитектур еще круче. Там thread на core до одури. Правда, скорее всего, фиги там другой системы. Но это не отменяет то, что в ряде случаев HT может быть сильно полезен. IMHO & AFAIK Понятно. Весь стэк состояния процессов можно засунуть в силикон. Как минимум время переключения контекстов будет нулевым.Там нету переключения контекстов. Это всё равно, что утверждать, что на 2х разных физических ядрах 2 потока выполняются быстро, потому что "время переключения контекстов будет нулевым" Как бы формально да, отдельных яизических ядер, или для гипертрединга (в реализациях Intel, IBM или Sun) "время переключения контекстов будет нулевым", к утверждению не придирёшся, но так говорить неправильно. Там просто нету понятия "переключение контекста", поэтому время его переключения действительно нулевое. (Если говорить именно про гипертрейдинг, а не про аппаратную поддержку многопоточности) ... |
|||
:
Нравится:
Не нравится:
|
|||
01.09.2016, 11:50 |
|
|
start [/forum/topic.php?fid=30&msg=39300221&tid=1529170]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
177ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 17ms |
total: | 289ms |
0 / 0 |