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

Ptirodaktill Точно.
Что касается масштабируемости ядра, то если я прав, конвеер, разделенный на много маленьких ступеней, выигрывает в частоте из-за улучшенной синхронизации сигнала внутри каждой ступени.

Axceil
Ты че-то путаешь - любая команда, пришедшая в проц, вначале декодируется и разбивается на несколько примитивных этапов, "удобоваримых" ступеням конвеера (микрооперации), а затем микрооп. подаются в конвеер на исполнение.

Axceil
Попробуй представить так:
У нес имеется последовательность команд, загружаемых в процессор.
Если действие над следующей коперандой зависит от результата действия над предыдущей, то после каждой обработанной операнды следует переход, и если он угадан неверно, то следует сброс конвеера.

Artiom
Если верить Юрову, то увеличение ступеней конвеера приводит к упрощению элементарных операций обработки команды, что понижает вероятность ошибки.

Artiom, с чего ты взял, что я так не считаю? Я не упоменал про микрооперации, но я имел в виду что на каждую команду приходится несколько блоков конвеера.
Ptirodaktill, а ты что думаешь, что разгрузка более длинного конвеера требует больше тактов, и поэтому потеря производительности?... На самом деле разгрузка происходит за один такт, в независимости от длины конвеера, да ещё и параллельно с выпонением основной микрокоманды.
А про net burst можешь не лечить - как точность предсказаний его алгоритма может быть 95%, когда у Athlon XP этот алгоритм раза в полтара лучше? Слабый алгоритм предсказания переходов у Intel - и есть одна из основных причин проигрыша в производительности против AMD'шных процев на равных частотах

Axceil

Откуда такие данные?
Кроме того, из-за особенностей архитектуры в НЕОПТИМИЗИРОВАННЫХ КОНКРЕТНО ПОД NET BURST приложениях АТЛОН ХР проиграть четвертому пню ОДИНАКОВОЙ с ним тактовой частоты просто не может(под проигрышем подразумевается отрыв более, чем на 3%)! и дело тут не столько блоке предсказывания переходов, сколько в более мощном сопроцессоре атлона.

При чем тут вообще разгрузка? Где я говорил про разгрузку?

И вообще, ты хоть представляешь себе работу конвеера? Судя по постам-нет.


.....
А даже , если у атлона алгоритм угадывает в полтора раза чаще, чем у пня, это не мешает пню иметь точность алгоритма 95%.

Ptirodaktill
А может это ты не понемаешь принцип работы конвеера?


Во-первых, не путай значения слов "операнд" и "команда".
Команда или инструкция - это действие, которое должен выполнить процессор: ADD, MOV, IMUL, CMP и т.д...
А операнд - это то, над чем выполняется действие - переменная памяти, регистр и т.д...

Так вот, из того, что ты сказал, что не следует то, что

На конвеере ЛЮБОЙ длины команда, требующая, например 6 тактов, разбивается на 6 микрокоманд, и выполняется за 6 тактов (я говорю про критический случай, когда был осуществлён переход и конвеер был сброшен).
Или ты так не считаешь?

Ну, а если у Athlon'а вероятность предугадывания 95*1.5=143%, то, наверное поэтому AMD придумала систему перформанс-рейтинга

2All:
Народ, вы тут такие умные вещи пишете... Ответьте мне только на два вопроса:
1) в каком месте на конвейере (неважно, какой длины) расположена точка входа (на какую ступень попадают декодированые команды)?
2) в каком месте на конвейере расположена точка выхода (где получаются результаты выполнения команды)?

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

Axceil

Нда, вообще-то надо считать уменьшение вероятности ошибки, т.е. 5%/1*5= 3,3(3) , т.е. точность составит 98,3(3)% .

AlexVK
Я могу ошибаться, но я думаю, что на конвеере нет фиксированной точки выхода, как и входа:
декодированные команды поступают на первые свободные ступени, а выходят на той из них, где завершила выполнение последняя микрокоманда данной команды.
Ну а насчёт NetBurst - выполняется и то, и то: процессор декодирует команды, которые, по его "мнению" (оно как раз и определяется алгоритмом предугадывания переходов) понадобятся вдальнейшем, ну а потом, попав на конвеер, командам ни чё не остаётся, как выполняться

Ptirodaktill
Если ты не понял, это была шутка
Лучше б ответил на главный вопрос, про конвеер...

Axceil
Итак, я могу ошибаться, но в общем конвеер работает так.(486)
1.Выборка команды
2.Декодирование команды
3.Генерация адреса
4.Выполнение операции
5. запись результата.
Очередная команда, после её выборки попадает в блок декодирования, освобождая таким образом место для следующей команды. Если команда за один такт переходит на одну ступень конвеера, то для выполнения команды, требуется столько тактов, сколько конвеер имеет ступеней(все это конечно сильно упрощено, но реальную ситуацию я расписать затрудняюсь.)
. Теперь смотри последний пост предыдущей стрницы.
Теперь об операндах . Я там кое-чего напутал, сейчас исправлю.

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

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

Axceil

У Интел предсказатель переходов весьма эффективен, во всяком случае эффективней атлоновского однозначно - он даже паттерны отслеживает.

Ptirodaktill
Вот теперь я понял твою мысль, и, возможно, ты прав.
Просто наши представления о конвеере различаются одной деталью:
Ты счетаешь, что ЛЮБАЯ команда должна пройти весь конвеер, не зависимо от его длины ит того, сколько тактов требуется для полного выполнения этой команды.
Но ведь ты сам указал, что команда выполняется за 5 стадий: мало того стадия генерации адресов может выполняться более чем за один такт, это зависит от количества операндов (её может и не быть, если операнды - регистры). Так вот, по-твоему получается, что команда выполнится на пятой ступени и будет ждать, пока конвеер выполнит остальные 25 ступений? Возникают 2 вопроса:
1) Что вообще выполняет конвеер эти 25 ступений?
2) Почему бы конвееру не записать результат, и не перейти к следующей команде? А если он так и поступает, значит нет потери производительности 30-ступенчатого конвеера против 20-ступенчатого!

Arie
Ну ладно, значит про NetBurst я был не прав...

Axceil
Я указал процесс выполнения для конвеера 486 процессора. Для net burst процесс выполнения команды разбит на большее число стадий, что именно за это время происходит я не знаю.
Кстати , из твоего вопроса возникает другой:"А все ли команды проходят все стадии конвеера? ", нужно будет осмотреть документы интела.
2. Результат же записывается. или ты про следующие команды?

Axceil
У них у всех свои сильные и слабые стороны.
У интел
+частота
+быстрые кэши
+предсказалка переходов
+НТ
+умный префетч из памяти
- низкий процент попаданий в кэш
- длинный конвеер (выше описано)
- только одна инструкция за такт декодируется
- мало uOP'ов за такт (3 макс)


У АМД:
-частота
-медленный Л2
-предсказалка (в К8 добили размер таблицы до 16к (против 2к у К7 и 4к у Р4), но паттерны afaik по прежнему не умеет и 5 тактов на предсказанный переход имхо медленно, у пня - 0 тактов.
+ 3 инструк/такт декодируются
+ 9 мОПов выполняются (3МОРа)
+ короткий конвеер
+ высокий hit-rate в кэш
+ AMD64 (куча регистров и прочее).

В прескотте относительно норфвуда
+ значительно лучше попадания в кэш (вдвое размер, вдвое ассоциативность)
- еще длинее конвеер
+ управление НТ

К сожалению afaik trace'cache так и не улучшили

Я имел в виду закончить работать с этой командой

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

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

Вот это ты блин даёшь, Arie , где ж ты был раньше!
Так ответь, наконец, на этот вопрос : значит ЛЮБАЯ команда должна пройти весь конвеер, не зависимо от его длины ит того, сколько тактов требуется для полного выполнения этой команды?

Во, нарыл ссылку на превью об архитектуре прескота:
http://chip-architect.com/news/2003_03_ ... mhill.html

Axceil
Вот это ты блин даёшь, Arie , где ж ты был раньше!
спал

Так ответь, наконец, на этот вопрос : значит ЛЮБАЯ команда должна пройти весь конвеер
Нет конечно.
Для начала не все команды грузят что-то из памяти, или пишут что-то. Но естественно есть общая часть (достать из кэша, декодировать, хотя пня это почти не касается, из-за trace cache), и т.д.

Потом есть еще время выполнения инструкции по типам (ее латентность), естественно оно добавляется.
Например в Р4 целочисленное умножение afair выполняется 15 тактов. В Атлоне - 4. Даже без декодирования это весьма тормознуто.

И вообще есть куча нюансов зависящая именно от реализации ядра. Например у пней (Р6+) afair построено по принципу трубы и навешанных на нее портах, через которые инструкции разбираются на выполнение. У того же К7 по другому. В общем деталей там дофигища и все их изучать смысла нет. Общее представление конечно имеет смысл получить если пишете что-нибудь низкоруровневое (компилятор или критичный ко времени код), тогда мануал по оптимизации - ваша Библия, заодно с Кама-Сутрой

не эксперт, но львиная доля падения производительности в зависмости от частоты у П4 от П3 была именно в увеличении конвеера... не помню сколько он был у П3, но имхо меньше 10 или около того, у П4 - 20.... то есть какая-то связь частота-длина_конвеера есть - большой потенциал по увеличению частоты (на момент первых П4) у ядра процессора именно появлялся за счет увеличения длины конвеера... не хочу лезть в старые обзоры, но именно такие объяснения были
посему увеличение длины конвеера в данном случае (ПОКА нет особого потенциала у ядра) ведет к введению новых инструкций (а их Интел продвинет, пример с САЕ и ССЕ2 это доказывает) для какого-то выигрыша...
хотя этот спор субъективный - я поклонник АМД посему мои рассуждения субъективны, но в то же время могу признать, что рейтинг Бартонов - абсолютно дутый, по идее Бартон с частотой 2400 (2000 у ХР 2400+, разница 400/66=6, т.е. 600) должен быть 3000+ - вот тогда спор с Интелом был бы реальным (у меня бартон 2500+ идет без проблем на 2400МГц - уж П4 3000 не уступает ни в чем даже с НТ)
САЕ - понятно, что ССЕ... описка