"Железный" оффтоп

[TSV NV]

HT не совсем ядро.

Оно на деле то совсем не ядро, но программы с этим не заморачиваются им всё равно ядро это или поток это уже проблемы операционки и самого проца. И тут уже зависит от программы сколько она ядер может задействовать, если только одно, то ни потоки, ни остальные ядра не дадут ничего, если 4, то больше 4х ничего не даст.
Естественно HT даёт свои бонусы, каждое ядро в один момент может обработать только определённое количество команд и при помощи виртуализации число команд увеличивается, время простоя сокращается, в общем палочка выручалочка, но тем не менее не заменит настоящее ядро, при увеличении количества ядер их эффективность падает, при этом эффективность HT падает ещё больше, по этому для обсчёта суровых задач не лепят процы 20 ядер + HT, а делают кластеры, так что для домашнего использования на данный момент хватает просто 4х полноценных ядер, как бюджетное решение можно и 2 ядра + HT.

[TNT]

Все, конечно же, зависит от программы, но дело не просто в том, как много ядер она может задействовать.
Каждое ядро может обработать максимум сколько-то инструкций за цикл (такт). Это зависит от длины конвейера: чем он длиннее, тем больше инструкций он может в себя внести и, как правило, тем короче и проще каждая его составляющая -> выше частота, но тем дольше придется ждать результата после того, как процессор достанет команду из отстойника (в P6 он называется reservation station). Цикл длится сколько-то времени, в зависимости от тактовой частоты. На продвижение команды по конвейеру может потребоваться несколько циклов: может 1, а может и 3 - опять же, зависит от конвейера, какие там стоят АЛУ, и т.д. Иными словами, даже если поток один, на конвейере далеко не одна команда. Первый Pentium умел со своим конвейером в 5 стадий исполнять две команды одновременно. Кстати, и компилятор, и процессор могут выполнять инструкции совершенно не обязательно в том порядке, в котором они написаны в программе. Это называется out-of-order execution и работает тоже очень давно.
Так вот, потоков, в которых в программе что-то ворочается, не 2, не 4, и не даже не 10, и, тем более, не столько, сколько физических процессоров (ядер) - их гораздо больше. Вот тут и появляется разница между процессорами, которые поддерживают SMT и теми, которые его не поддерживают. За каждый такт во фронтэнд процессора может попасть инструкция из любого из потоков. Допустим, максимум за такт он может выбрать 4 инструкции, а всего в процессоре 6 исполняемых блоков (блоки обычно делятся на быстрые для коротких инструкций и медленные для более долгих, но это другая тема). Без SMT процессор за такт может выбрать инструкции только от одного из потоков и их совершенно необязательно будет 4: скорее всего, их будет 2-3. Во фронтэнде останется два пустых места и эти две-три инструкции уедут дальше на конвейер, на котором может быть 6. Уже на втором такте, особенно если предыдущие 2 инструкции короткие и они прошли одну стадию конвейера, будут загружены еще всего 2 инструкции. Т.е. в этом худшем случае конвейер процессора будет обрабатывать 33% от того, что теоретически мог бы, а ОС будет вам говорить, что он пыхтит на 100%, т.к. инструкции на каждом такте, безусловно, для него приготовили. Конечно, могло бы статься и так, что было выбрано 3 долгие инструкции, потом еще 3 такие же, и тогда на этой стадии конвейер будет загружен на 100%, но это вряд-ли...скорее всего, будет что-то между: он будет загружен процентов на 60-70.
Если же у процессора есть SMT, то он сможет на каждом такте загружать из других потоков инструкции во фронтэнд и отдавать на конвейер не по 2-3, а всегда по 4 инструкции.

Почему это не всегда ускоряет все на 30-50%? Ну это зависит от того, какие исполняемые блоки у процессора, сколько потоков долбятся, какой конвейер у процессора и т.д. Если процессор хороший, то он и так будет делать хорошее предсказание ветвлений (т.е. не будет скидывать весь конвейер), у него и так всегда будет в кэше достаточно команд, он будет делать выгодное ему переупорядочивание и т.д. Вполне может быть, что если программа процессору подходит, то он и так будет хорошо загружен. То, что в Арме 4 ядра Фенома медленнее двух i3 говорит просто о том, что программа ему плохо подходит: скорее всего, Феному не загрузить конвейеры полностью и они молотят вхолостую, даром, что их 4. Надо попробовать выключить SMT на i3 и посмотреть, что будет.

P.S. Кстати, все Зеоны с HT. Даже те, что более 20 ядер.

[TSV NV]

Не вижу противоречий.

[TNT]

Сообщение от TSV NV

Не вижу противоречий.

Противоречий нет. Дело все в том, что программа может прекрасно использовать все ядра, а они все равно будут работать плохо.
Кризис 3
Еще неплохой тест.
В Project Cars, например, разница приличная.

[TSV NV]

На сколько видно, обычно с малым количеством ядер HT помогает, с большим количеством ядер чаще мешает.

[TNT]

Да нет же Все завист от приложения и процессора. Разумеется, на Core i3, у которого и кэша меньша, и с памятью он соединен по более медленной шине, HT будет влияние оказывать больше в CPU-intensive приложениях.
Но это еще ничего не значит Вон, в Криздице в Grass Physics i7 на 3.5ГГц с НТ обошел себя же на 4.2ГГц без НТ, а на равных частотах разница была в районе 25-33%.
Дело не в том, сколько потоков - хоть 15 логических ядер делай, он не сможет обработать в два раза больше потоков. Дело в том, что получив поток в другое логическое ядро, если на первом ядре инструкция чего-то ждет, процессор спокой загружает исполнительные блоки инструкциями со второго логического ядра. Не НТ этого сделать не сможет, он будет ждать, пока конвейер начнет двигаться. Он не умеет исполнять на нем одновременно инструкции из разных потоков, а их может на конвейере каждого физического ядра i3 и i7 находиться одинаковое количество, потому что архитектура одна и та же.
Другой момент, что запросто можно нагрести из других потоков тоже инструкций, которые совсем застопорят конвейер. По идее, в рендере это вполне возможно - так лучше, наверное, НТ выключать, даже если он есть.

[TSV NV]

Да понятное дело, что при использовании сферического коня в вакууме всё будет работать как задумывалось с максимальной производительностью, а при большой вариативности программной и железной всё буде далеко не так радужно и даже с отрицательным эффектом. В том кризисе в конкретной локации основную нагрузку даёт трава, куча мелких повторяющихся однотипных объектов, такая хрень явно имеет короткие конвейеры и HT тут будет сильно в масть.

[TNT]

Погоди...какая хрень имеет короткие конвейеры?
НТ там помогает, скорее всего, потому, что приходится подолгу ждать память. Я, кстати, еще не уверен, что винда умеет отличать логические ядра от настоящих. Ей еще запросто может прийти в голову иногда загружать второе логическое ядро при простаивающем (или даже нескольких простаивающих) физическом. При таком раскладе НТ наоборот сильно просадит производительность.

[TSV NV]

Хрень = трава, она мелкая и часто повторяющаяся, по логике и код на неё должен быть мелкий. Её там очень много и проц её постоянно обсчитывает, вот тут то НТ и выходит в короли. В ведьмаке 3м по идее волосня так же должна обсчитываться, но хз как там у нвиды это разрулено, может только видяхой.

[TNT]

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