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) "время переключения контекстов будет нулевым", к утверждению не придирёшся, но так говорить неправильно.
Там просто нету понятия "переключение контекста", поэтому время его переключения действительно нулевое. (Если говорить именно про гипертрейдинг, а не про аппаратную поддержку многопоточности)