Ждём Ваших отзывов о материале.
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!

***


Бред уже постаревшей и сивой кобылы...поучите матчасть немного
..тот Hyper-Threading который реализуется в Нехалем ...маленько имеет другую структуру...
никто и ничего конфликтовать там не будет...будет кое что другое...тема по этим вопросам есть
и даже на этом форуме..где я соизволил излагать ...уча неучей что к чему....
...да на чём мы остановились..так вот при той технологии которая реализуется в Нехалем...
...будет существенная прибавка в производительности...то что считают Гипер-Трейдиногом...
в том понимании как его понимают..это не со всем верно...
........Хотя и Гипер-Трейдинг реализованный в старом Нет Бурсте..лично у меня и большинства
програмистов не вызывал нареканий...и был популярен у програмистов...и даже многими из них любим...


***

Признаюсь такой фитчи нет (и не предвидется) у АМД, потому-что здоровому костили не нужны, они только мешают (C2D также) . Отличить просто, если фитча помогает или хотя бы не мешает всем, то она "костылём" не является (интегрированный контроллер памяти никому не мешает и многим помогает).

Технические обоснования :
1) K8 (C2D также) являются суперскалярными и конвейерными, то есть параллельно обрабатывают несколько команд с переопределением порядка их следования в целях оптимальной загрузки вычислительных ресурсов.
2) Процессор K8 очень быстро очищает и перезагружает конвейер
3) У C2D выборка команд идет четырьмя одновременно.
4) У C2D имеется сложный блок предсказания ветвлений, который использует самые передовые алгоритмы, сводящие к минимуму вероятность неправильного предсказания и следующей за ним перезагрузки конвейера.
Ну а как костыли (НТ) мешает Вы уже знаете.

Согласен! Никогда не видел минусов в Hiper-Threading'е.
Например в WinRAR'е мне он увеличил скорость упаковки с 450Кбайт/с до 650Кбайт/с, в Xilisoft Video Converter заметно уменьшил время кодирования, что можно объяснить заточенностью кодеков под многоядерность!

А Вы учитесь читать: Я не знаю сколько процентов HT даст Нехалему, по этому буду судить по Р4 и Pentium D.


И где их берут итих любителей програмистов Гипер-Трейдинга

Добавлено спустя 8 минут, 52 секунды

Ну может плохо смотрели . А от куда берётся прирост производительности на P4 я писал.

Фанатство в конференции не приветствуется, а я свои слова могу подтвердить скриншотами, а вы кроме пустого ляля ничего больше и не способны сделать!

Нет,есть приложения,которые он тормозит(сам правда таких не видел),но в абсолютном большинстве(приложения,не заточенные под многопоточность) результат с гипертрейдингом больше результата без него на доли процента.Есть больше,есть меньше,но САМОЕ ГЛАВНОЕ:ЕГО ИСПОЛЬЗОВАТЬ НИКТО НЕ ЗАСТАВЛЯЕТ-не хочет,можешь выключить

Ну и причём тут фанатство? Я вам верю, Hyper-Threading дествительно на архитектуре NetBurst помогает, просто не всегда. Свои скриншоты я предаставить в потверждения я немогу (нет у меня NetBurst), а в инете если надо найду.
А это "а вы кроме пустого ляля ничего больше и не способны сделать!" - в конференции тоже не приветствуется. И что я могу зделать на форуме кроме "ляля"( прошу заметить не пустого)? И кричать не надо, будьте спокойней, все хорошо

linuxdrom

Ошибка. Для интегрированного контроллера тоже можно найти ситуации, когда его наличие будет "просаживать" производительность. Например, для многопроцессорных систем на базе АМД необходимо программировать с оглядкой на NUMA. Иначе на неоптимизированных задачах можно получить реальное "проседание" относительно однопроцессорной и с меньшей частотой. Смотрим тесты:
http://www.fcenter.ru/online.shtml?arti ... ards/19826
В этом смысле, мультитрединг ничем не отличается от ИКП - так же требуется явная оптимизация. Так что по вашим критериям - ИКП костыль для архитектуры К8.

О!. Спасибо. Не знаю зачем вы это написали, но именно этот аргумент я и хотел привести в качестве показателя нужности мултитрединга.
А именно - Athlon64 может обрабатывать одновременно 3 инструкции за такт (IPC=3) Core может обрабатывать 4 инструкции за такт (или 5 с MacroOP fusion) (IPC=4(5)). В тоже время, для большинства програм average IPC < 2. Замеры можете найти в сети. Недавно видел замеры на linux kernel - для Athlon64 результаты были в районе 1.6-1.8. То есть, по сути дела, до 30-40% ресурсов процессора практически всегда простаивают - всё из-за сильно ограниченной возможности распараллеливания х86 кода. Так почему бы не занять простаивающие ресурсы другим тредом?

Так и знал, что будете "давить" на длинноконвейерность Р4. Распространнёная ошибка - считать мультитрединг костылём для длиноконвейерных архитектур. Итаниум и Power5 это очень хорошо доказали.
Добавлено спустя 1 час, 16 минут, 21 секунду
linuxdrom

Надо написать очень специфический код, чтобы задействовать 100% ресурсов процессора. (видимо что-то типа интеловского "термометра" для Коры).

Насколько я помню, по цепочке конвейера, общими являются все ресурсы до register file. В общей слозности НТ добавляет 5% к площади процессора.

Не понятно, что имеется в виду.

Ну и что. Стадию декодирования обычно не является критичной в Р4, так как L1 trace cache хранит уже декодированные инструкции.

Для таких потоков и ввели инструкции MONITOR/MWAIT .

Откровенно говоря, в К8 дисбаланс ещё больше. При 6 портах запуска (vs. 4 в Р4) K8 может обрабатывать только 3 инструкции одновременно. При этом даже темп в 3 инструкции никогда не достигается.

Согласен, в ряде случаев для предыдущей версии НТ нужна была оптимизация. С этим не спорил. Как будет в будущей версии - посмотрим.

Ключевое слово многопроцессорные, мы же расматривали "костыли" в рамках однопроцессорных систем. Но ведь без NUMA и интегрированного контроллера, было б ещё хуже, чем в тех случаёв когда мы получаем "проседание".

Ну почему, у Р4 при простраивающих 65%, прирост производительности даже по вашим словам всего 10-30% (на самом деле намного меньше), ведь должно быть ~185%. Я выше написал почему (даже боле-менее с технического обоснованиями). Если не понятно - другим тредом занять "простаивающие" ресурсы не всегда возможно. И самое главное - другим тредам далеко не всегда нужны именно "простаивающие" ресурсы.
На счёт linux kernel - дайте пожалуста ссылочку. А пока ссылки нет, рискну предположить что там ядро было i386 или i586. Так вот посравнению i386 ядро скомпилированое с максимальными оптимизациями для K8 быстреё yf ~50%. То есть IPC уже 2.7, что не так и плохо. А вобше плохо оптимизированый код и есть одной из главных проблем (хорошо хоть в Linux это можно иправлять).
Кроме того кто сказал что у К8 идеальный конвеер-декодер? Был бы идеальный было б IPC=3.

Дело в том, что на длиноконвейерной архитектуре и дает наибольшую пользу Hyper-Threading, но даже на ней толку мало. Про Итаниум и Power5 к сожалению не знаю, просветите пожалуста.
Упс! Пока писал столько нового появилось
Добавлено спустя 41 минуту, 35 секунд

Или очень оптимизированый, к чему и надо стремиться.

Имелось в виду, к примеру если запустить поток комманд, связанных с вычислениями с плавающей точкой и большими блоками данных то производительность ухудшится.


Я говорил что К8 хороший?

По чему "даже"? Ведь 3 инструкции это в теоретический идеал (я ошибаюсь?)


Спорить не спорил, но заявлял про 10-30%

Ну будем надеяться на лучшее.

Насколько я думаю, в основном прирост быстродействия в архитектуре P4 при использовании ГТ, был за счет исполнения второго конвеера, когда первый простаивал, загружая 31 стадию.
Так как в Нахале конвейер будет приблизительно раза в два короче, то и польза от ГТ снизится приблизительно раза в 2, т.е. по моим прикидкам, от введения ГТ в Нахала будет прирост 5-15%, что по себе совсем неплохо.
К примеру, если он будет набирать в СПУмарк06 ~ 20К попугаев без ГТ, то с ним будет набирать ~ 21К-23К попужуев , хотя фих знает канешна.....

Вы оперируете 10-30% как и TyyOx91, что неверно. Откуда вы их берёте?
http://www.fcenter.ru/img/article/CPU/I ... /88070.png

linuxdrom, а при чем здесь ссылка на ту давнюю статью (обзор только вышедшего C2D) с Ф-Центра ? Нас ведь интересуют Nehalem и NetBurst. Давайте начнем с того, что никто из нас не может прикидывать ничего в процентах. Мы можем спекулировать только на тему "а нужно ли?". Но поскольку никаких особо ясных спеков о Nehalem'е нет, то о каких-либо числах говорить преждевременно.

Что это значит?:spy:

Ссылка к тому, что по статье видно, что прироста в 10-30% производительности от НТ (не понятным образом появшихся у TyyOx91) нету.

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

linuxdrom
Т.е. Вы сравнивали XE965 c D945?... Так там прирост если и будет, то от наращивания частоты, а не от ГТ. Надо найти сравнение одноядерных Пней: одного с ГТ, другого без.
Nikols999
Извольте-с.
Добавлено спустя 5 минут, 18 секунд
;) поиск

Нет я сравнивал удельную производительность на мегагерц. У XE965 она больше на ~5% по сравнению с D945, правда заслуга в этом шины на 1066МГц (у D945 800МГц). Причём производительность на гигагерц в некоторых задачах у XE965 меньше на 10% чем у D945 и вина в этом НТ (от увеличения шины производительность не уменшается).

Лучше двухядерных, ведь Nehalem будет многоядерным. Мне икать лень , а та давняя статья с Ф-Центра попалась первой

linuxdrom
Ок.

Хамство удалено.

Hil.
Отредактировано модератором: Hil. Дата: 02.04.2007 22:29

linuxdrom

Вообще-то мы рассматривали общий случай - что можно назвать костылями, а что нет. И на сколько я понял, по вашему костыль - это фитча которая даёт прибавку в производительности в одной области, за счёт уменьшения производительности в другой. Никакой привязки к "частным" случаям не было. Поэтому пример с двухпроцессорной системой - кошерный.

Я не знаю как вы насчитали 185%. Прирост производительности не может быть больше, чем процент "простаивающих" ресурсов. При этом максимальный выигрышь может быть только если второй тред использует простаивающие вычислительные блоки.

Не думаю, что кто-то надеялся на КПД в 100%. Если второй тред сможет использовать хоть часть простаивающих исполнительных блоков в определённые отрезки времени на некоторых задачах - это уже может оправдать добавление такой логики. Тем более, что это не сильно сказывается на увеличении кристала (на Р4 - 5%). Количество вычислительных ресурсов в процессоре всё время растёт. При этом возможность параллелезации х86 кода не улучшилась (так как это больше зависит от конкретных алгоритмов, чем от конкретного кода). Было бы глупо не попытаться использовать простаивающие ресурсы. Даже на не самой удачной реализации НТ в Р4 на многих задачах был заметен значительный выигрыш - до 30%. Кроме того, на сколько я вас понял - больше всего вас заботит падение производительности на некоторых задачах - ну что же, это challenge для разработчиков Интел. Но как вам уже сказали - не обязательно новая реализация НТ будет в точности повторять предыдущую. Поэтому странно, что вы так упорно пытаетесь доказать "ненужность" НТ даже не дождавшись хоть какой нибудь более менее вразумительной информации.

Нет. Тестировали на последних версиях ядер. Ссылка была где-то на xtremesystems.org. К сожалению сейчас уже не нахожу. Но вот вам другая интересная ссылка:
http://cadal.cse.nsysu.edu.tw/publicati ... essors.pdf
Иследование максимального ILP для х86 кода на типтчных приложениях без привязки к конкретной архитектуре. Получилось в среднем 2.2 инструкции за такт. Это максимум. На реальных архитектурах гораздо меньше - 0.8-1.0 для типтчных десктопных программ по оценкам anandtech.com:
http://www.anandtech.com/cpuchipsets/sh ... spx?i=2657

http://www.princeton.edu/~jdonald/resea ... tecito.pdf
http://www-941.ibm.com/collaboration/wi ... chitecture

10-30% на оптимизированном коде? С чем вы не согласны?
http://www.hardwareanalysis.com/action/ ... icle/1557/

давайте вспомним базовые понятия. Костыль - это такая подпорка, которая помогает хромому ходить. И даже бегать.
Я называю ГТ костылем НБ, т.к. считаю, что архитектура НБ для десктопов неудачна, и ей потребовались костыли, чтобы соперничать с конкурентами. Главный костыль - частота. Еще один - ГТ. На костыле ГТ Пи4 бегает быстрее до 30%!
А он этого не утверждал. Вы бы внимательнее читали