Pentium4 Extreme Edition

30.01.`04

Доставчик: Intel
Автор:GeniusLoci

Дълъг конвейр=висока честота..

Буквално ми е омръзнало да слушам, че Р4 работи с по-висока честота, защото имал по-дълъг от на процесорите на АМД конвейер. Формулировката е неправилна - конвейра е дълъг, защото процесора работи на висока честота, така че да осигурява необходимото количество данни! Причина №2 е възможността за кратко време да се изпълнят последователно въведени инструкции, така че да не се губят т.нар. празни цикли, през които изчислителните блокове изчакват поява на още данни. В това отношение нищо чудно Intel да удължат още този конвейер при по-новите си процесори, за да "смогне" не само на още по-високата честота, но и на постигнатата по-висока степен на паралелелизъм при обработката - НТ технологията позволява да се отстрани поне част от потенциалната заплаха на опразването на целия конвейр, а в случай, че това не се случи - осигурява още по-голяма дължина на потока информация към ядрото, така че ще могат да се използват още по-пълно възможностите на изчислителните блокове. В тази насока въвеждането на още инструкции (SSE3) не е случайно и може да добави още някой процент производителност при наличие на съответните оптимизации. Както вече е ясно, увеличени са и L1 кешовете - пак необходимост, наложена от използването на НТ. За съжаление, когато говорим за температура - възможността да се постигне постоянна (или почти) натовареност на всички блокове ще доближи още повече процесора до теоретичния максимум на консумираната мощност. Съмнително е, че в Intel не са помислили и за подобрение в модулите за предсказване на преходите (branch prediction units), тъй като това е едно от слабите места в архитектурата на Р4 като цяло.

Преди да поговорим за бъдещето, не е лошо да обясня с малко подробности настоящата архитектура на Р4. Предполагам не само сте виждали, но и са ви "набили" всички нейни предимства и недостатъци. Из Мрежата се намира огромно количество информация за устройството на Р4, но реално на много малко места се среща не само подробна, но и разбираема, и най-вече преводима информация по темата.
Р4 разполага с два ALU блока, работещи на удвоена спрямо процесорната честота, т.е. в нашият случай на 6.4 GHz. Вероятно се използва DDR "метод" за предаване на данните, въпреки, че в едно ядро това би довело и до проблеми в определени случаи.В Интел обаче не пасат патки, съответно всички проблеми, идващи от разликите в начина на поемане на данните са изчистени и грешките в някой от блоковете са премахнати. На някои графики може да видите два FPU блока, но реално производителността им в ниакъв случай не е двойна, тъй като един от тях е предназначен изключетелно да изпълнява командите по запазване на обработената информация. Дотук трябва да е ясно защо (не забравяйте високата честота) има нужда от сериозна дължина на конвейра - подобно количество данни се подава трудно и само постоянния приток би довел до необходимото представяне.
От самото начало Интел заложи и агресивно наложи използването на SSE2 инструкции, обединяващи в себе си по няколко последователни операции. Те, също както и ММХ инструкциите са с до 128-битова дължина. Операциите по извличането и декодирането на инструкциите, извършвани в ранните стадии на въвеждане на данните в конвейра се извършват (обикновено) във trace cache - това е пълноскоростен вид кеш, в който се съхраняват до 12000 най-използвани микрооперации. По този начин, дори след привършване на дадена дейност и при нужда от повтарянето й няма нужда от обръщение към Fetch/Decode блока, защото необходимите инструкции вече се наимрат в този кеш и просто се използват отново. Класическият (или по-скоро практическият) тип изсценировка показва, че търсенето на допълнителни данни всъщност е доста рядко. Причина за това е и подобрената логика за предсказване на преходите - тя контактува директно с trace cache-a и едва при липса на тези инструкции. По такъв начин се получава доста по-висока вероятнос данните да се подават далеч по.плътно, без да има недостиг или нужда от обръщения към L2 кеша. Не, че такива няма за постъпващите данни, но операциите, извършвани постоянно се "складират" в trace cache. Ускорение добавят и готовите инструкции ММХ и SSE/SSE2, които обединяват повече от една операция в себе си. Така една единствена инструкция може да ес зареди много по-бързо (един такт), позволявайки да се постигне в пъти по-висока производителност като се пестят всички изчаквания. SSE2 имат "противоречива" слава - често много хора отричат използването им да носи значителен прираст, но дори на практика единици са приложенията, които се възползват от тях и не чувстват сериозно повишение на бързодействието.
Конвейера на Р4 е удължен до цели 20 стъпки (само за примера - 7 при AthlonXP), но въпреки всичко това не води од толкова търсения от феновете на АМД спад в производителността, когато се наложи той да бъде опразнен.

Stage

Work

1

Trace Cache next instruction pointer Trace

2

Trace Cache next instruction pointer Trace

3

Trace Cache fetch

4

Trace Cache fetch

5

Drive

6

Allocation

7

Rename

8

Rename

9

Queue

10

Schedule

11

Schedule

12

Schedule

13

Dispatch

14

Dispatch

15

Register Files

16

Register Files

17

Execute

18

Flags

19

Branch Check

20

Drive

Вижда се, че дори при възможна грешка, опразването на конвейера изобщо не означава, че при въвеждането си следващата инструкция ще трябва да измине 20 стъпки, докато бъде обработена.При грешка ще бъдат опразнени стъпките между 1 и 14, тъй като следващите вече са преминали към изпълнение. Още повече за липсата на такива грешки и по-бързата обработка след като дадена инструкция бъде изпълнена в изчислителните блокове получените резултати също се маркират и има възможност директно да бъдат поставени отново в началото на конвейера. Същевременно с въвеждането на Hyper Threading дори не е нужно да се опразва целия конвейер пир подобни грешки, най-вече защото в него се съдържат инструкции от различни нишки и може просто в последните стъпки преди изпълнението да се изхвърлят ненужните (или грешни). Именно затова и НТ е стъпката в правилна посока, така дори удължаването на конвейера няма да предизвиква намаляване на производителността при грешно предсказан преход в едната нишка, а и отпадат положенията, когато е нужно ад се превключи между две нишки за да се изпълни втората. Така на разположение има още стъпки в конвейера, които може и да носят полезни инстрекции, т.е. такива, които ще се изпълнят, но това зависи и от изпълнявания процес (както отбелязах вече, ако един процес "заграби" всички ресурси, отав наистина се отразява лошо на производителността, а в случай на грешка в предсказването, наистина води до опразване на целия конвейер. За радост, това се случва далеч по-рядко, отколкото при традиционната архитектура с едно логическо процесорно ядро.

<<Назад<< >>Следва>>

Counters
Wal Mart