HettВот допустим есть одно физическое ядро и 2 потока.
Допустим 1 процесс использует одно ядро на максимум. Следовательно мы видим в общей картине, что нагрузка на процессор составляет 50%. Понятно, что все зависит от природы процесса, но я так понимаю при сложных вычислениях показатель 50% будет обманчивым? Т.е. запускаем мы второй такой же процесс на втором ядре и оказывается, что первый процесс стал работать в два раза медленнее?
Это зависит не от сложности вычислений, а от их способности распараллеливаться.

В одном ядре 2 вычислителя, ALU (ну, упрощённо говоря).

Планировщик выполнения пытается найти в вашем последовательном коде команды, которые могут выполнится одновременно, без ошибки в итоговом результате (то есть команды не зависят друг от друга), и выполняет их одновременно на двух ALU. Это техника в процессоростроении называется "суперскалярность".
Если все команды в одном потоке могут выполнится парами, то поток будет выполняться в 2 раза быстрее. Если ни одна команда не может выполняться в паре с другой, то половина ALU будет незадействована.

Гипертрединг гарантированно загружает оба ALU. Но тогда, если один из потоков хорошо параллелится "внутри себя", то гипертрединг действительно его замедлит, до двух раз в пределе.

В целом почти всегда гипертрединг повышает производительность, исключения редки. Просто проверьте на конкретном ПО.

HettПолучается в данной ситуации явно нельзя определить, загружен на данный момент процессор на 50% или на все 100% ?Так определить нельзя, по графикам в таск-менеджере.

Если механизм суперскалярности хорошо использует все ALU, то гипертрейдинг будет даже мешать, из за дополнительных накладных расходов. А если плохо, то помогать.

Определить это можно для конкретного приложения, прогнав его как нагрузочный тест с включённым и выключенным гипертрейдингом. И сравнить время.
Как правило, гипертрейдинг помогает, потому что суперскалярность работает в принципе неидеально, а спекулятивное выполнение ещё хуже.
Гипертрейдинг по определению эффективнее этих техник, потому что все узлы процессора используются для полезных вычислений, а не для попыток что то "выгадать", на всякий случай исполняя "бесполезные" команды.

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

kdvвот неплохое объяснение, с картинками
https://www.percona.com/blog/2015/01/15/hyper-threading-double-cpu-throughput/
Чувак взял 12-ядерный проц, т.е. 24 якобы ядер с включенным HT.
Так вот, начиная с 8 тредов, грузящих проц, т.е. с 33% виртуальной утилизации проца, время выполнения тредова начинает расти. Вывод такой:
если нужна пропускная способность проца, то HT - хорошо. Если же нужно более быстрое "время отклика", то HT надо выключать.Нельзя делать такой общий вывод на основании анализа одного приложения (одного набора команд), или на своих предположениях.

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

МимопроходящийHello, Alexeyvg!
You wrote on 31 августа 2016 г. 13:14:13:

Alexeyvg> Нельзя делать такой общий вывод на основании анализа одного приложения (одного набора команд), или на своих предположениях.
поройся в архивах msdn и найди рекомендацию M$ отключать HT на MSSQLПоройся в архивах msdn и найди рекомендацию M$ включать HT на MSSQL для новых процессоров и новых версий сиквела.

lockedLeonid KudryavtsevЯ так понимаю, что у IBM, Sun архитектур еще круче. Там thread на core до одури. Правда, скорее всего, фиги там другой системы. Но это не отменяет то, что в ряде случаев HT может быть сильно полезен.

IMHO & AFAIK
Понятно. Весь стэк состояния процессов можно засунуть в силикон. Как минимум время переключения контекстов будет нулевым.Там нету переключения контекстов.
Это всё равно, что утверждать, что на 2х разных физических ядрах 2 потока выполняются быстро, потому что "время переключения контекстов будет нулевым"
Как бы формально да, отдельных яизических ядер, или для гипертрединга (в реализациях Intel, IBM или Sun) "время переключения контекстов будет нулевым", к утверждению не придирёшся, но так говорить неправильно.
Там просто нету понятия "переключение контекста", поэтому время его переключения действительно нулевое. (Если говорить именно про гипертрейдинг, а не про аппаратную поддержку многопоточности)

just_vladimirВ описываемом случае, если оба потока занимаются идентичными операциями, то гипертрединг действительно может оказаться не очень эффективным, т.к. обоим потокам будут требоваться однотипные execution unit'ы, за которые и будут конкурировать потоки, а те которые не востребованы будут простаивать, как при работе одного потока, так и при работе двух потоков. А вот если потоки разнородные, условно (на самом деле это все очень тонкие материи) в одном крутится некий алгоритм работающий с целочисленными вычислениями, а во втором с плавающей точкой, то в теории в этой ситуации должен быть неплохой профит от гипертрединга.
Если обоим потокам будут требоваться однотипные execution unit'ы, но по одной штуке, а однотипных execution unit'ов пара или больше, то гипертрейдинг повысит производительность ровно в два раза.
HettДопустим 1 процесс использует одно ядро на максимум. Следовательно мы видим в общей картине, что нагрузка на процессор составляет 50%.Ещё раз - по процентикам в таск-менеджере вы не увидите, насколько эффективно используются execution unit'ы одним потоком.
Он не показывает, команды в одном потоке выполняются парами за такт, или по одной за такт.
Он показывает, все ли такты процессора были использованы потоком, не было ли перехода процессора в режим ожидания.

just_vladimiralexeyvgЕсли обоим потокам будут требоваться однотипные execution unit'ы, но по одной штуке, а однотипных execution unit'ов пара или больше, то гипертрейдинг повысит производительность ровно в два раза.
Говорю же, здесь тонкие материи и много если, которые знают только инженеры Intel, а остальные только догадываются. Я дак вообще дилетант :-) Но тем не менее мне в целом сложно представить такую ситуацию, что один поток использует всего один execution unit, а остальные простаивают и их конвеер никак не нагружает.Если вы вообще можете представить такую необычную ситуацию, когда "поток использует более одного execution unit", то представить, что поток "не может" это делать, по моему, достаточно просто.
Вы знаете, как вообще это работает, "одновременное использование нескольких execution unit"?

Всё таки использование более одного execution unit - это результат очень сложных техник, особых последовательностей в выполняемом коде, и некоторого везения.

Причём некоторые из этих техник (да, наверное, все) делают это использование заведомо избыточным, уничтожая часть его результатов.
Т.е., скажем, при использовании 3х execution unit, особенно однотипных, 2 из 3х результатов вычислений может быть уничтожено, если процессор поймёт, что результат обработки недостоверен.
Что ещё более повышает эффективность гипертрейдинга, где таких проблем в принципе быть не может.

Scott Tiger https://en.wikipedia.org/wiki/Simultaneous_multithreading - вот здесь в разделе "Modern commercial implementations" вкратце пояснено, чем интеловский гипертрединг отличается от сходно называющихся реализаций Sun/Oracle, IBM и пр.Нет, нету там про "чем интеловский гипертрединг отличается от ...". Там просто упомянуты некоторые особенности конкретных реализаций гипертрединга на разных процессорах, в т.ч. для интеля - на пентиуме 4 (14-летней давности).