Какво е изпълнение извън поръчка?

Компютрите са сложни машини, като няма по-сложна част от процесора. На основно ниво на преглед изглежда, че процесорът трябва да е относително прост. Той взема поредица от команди, обработва ги и след това извежда данните. Това обаче малко прилича на действителната работа на съвременните процесори.

Подскаларен към суперскаларен

Ранните процесори бяха точно такива, каквито бихте очаквали. Те взеха инструкции поотделно, в реда, в който им бяха дадени, обработиха ги докрай, след което преминаха към следващата инструкция. Процесорите от този тип са субскаларни, способни да изпълнят по-малко от една инструкция на тактов цикъл. Дизайнерите на CPU установиха, че има много различни етапи на изпълнение на инструкция. Всеки от тези етапи изискваше различен хардуер. Това означаваше, че когато изпълнявате една инструкция през цялата последователност наведнъж, някои части от хардуера остават неактивни. Във всеки вид процесор неактивният хардуер е безполезен хардуер.

За да се използва този празен хардуер, проектите на процесора бяха актуализирани, за да се използва тръбопроводен подход. Това допълнително раздели хардуера за всеки етап, но позволи всички те да бъдат използвани едновременно чрез поредица от инструкции. Въпреки че все още бяха необходими няколко цикъла, за да премине всяка инструкция през конвейера, общата производителност беше една инструкция на цикъл. Това направи процесорите скаларни.

За да могат да правят повече, процесорите трябваше да бъдат направени суперскаларни. За да се постигне това, бяха внедрени множество паралелни тръбопроводи.

Поддържане на тръбопроводи, захранвани с данни

Основният проблем с производителността на компютрите обикновено е латентността на паметта. Много инструкции работят с данни, така че тези данни трябва да са налични, за да може инструкцията да бъде изпълнена. Въпросът е какво правите, ако трябва да изчакате тези данни, защото не са налични веднага? Традиционно отговорът беше просто да се спре и да се изчака да стане наличен. Това оставя целия тръбопровод празен, потенциално за стотици цикли на процесора. Нещата стават още по-лоши, когато две инструкции в паралелни конвейери трябва да чакат памет, тъй като първата ще задържи дори заявката за данните на втората. Докато кеш паметта на процесора може да помогне за справяне с този проблем, тя все още не може да го поправи. Необходима беше нова парадигма, за да се реши. Тази промяна на парадигмата беше Out Of Order Execution или OOO.

Първият етап от конвейера е декодирането на инструкцията. Това означава да се определи какво трябва да се направи и да се провери дали данните, необходими за операцията, са налични. В OOO CPU декодираните инструкции се добавят към опашка. Те се премахват от опашката и действително се обработват само когато данните, от които се нуждаят, са налични. Критично е, че няма значение в какъв ред са добавени инструкциите към опашката. Ако ранна инструкция чака данни, по-скорошна инструкция може да пропусне напред, ако е готова за работа. OOO процесорите могат да пренаредят инструкциите, които трябва да обработват въз основа на опашката от предстоящи инструкции и кои от тях са готови за изпълнение.

Критични зависимости

Този процес предполага две неща. На първо място, че е възможно надеждно да се идентифицират и да се справят с истинските зависимости. Второ, че можете надеждно да управлявате и идентифицирате фалшиви зависимости. Каква е разликата? Е, истинската зависимост е зависимост, която изобщо не може да бъде смекчена в система OOO. Най-лесният пример е четене след запис. Ако имате една инструкция, която трябва да напише някои данни и друга, която трябва след това да прочете тези данни, няма начин да можете да пренаредите тези инструкции. Те трябва да бъдат попълнени в реда, в който са били представени, или ще получите безсмислени данни.

Фалшивата зависимост е тази, която може да бъде скрита с друг хитър трик. Да вземем примера с запис-след-четене. На пръв поглед може да си помислите, че не можете да презапишете данни, преди да сте ги прочели. Нещата обаче не са толкова прости. Ами ако имате друго място, където можете да запишете новите данни, и след това можете просто да размените новите и старите данни, след като старите данни бъдат прочетени? Това е процесът на преименуване на регистъра и е от решаващо значение за обработката на OOO.

Обикновено наборът от инструкции дефинира определен брой архитектурни регистри, които се използват в системата. Вие буквално не можете да се обърнете към други. Но какво ще стане, ако правите регистри за свръхпредоставяне? Можете просто да ги скриете в по-голямата си част, да ги използвате за съхраняване на данни, които все още не е трябвало да бъдат обработени, и след това просто да размените етикетите на скритите и архитектурните регистри, когато времевата линия отново е правилна. Във всеки един момент има точното количество архитектурни регистри, просто не е задължително винаги да са на едно и също място. Аналогия в реалния свят би била hot-desking.

Заключение

Изпълнението извън ред е парадигма за обработка, при която инструкциите могат да бъдат динамично пренаредени по време на изпълнение от CPU. Това се прави на базата на най-рано издадените инструкции, за които има налични данни. Това означава, че инструкциите, които се зареждат в тръбопровода, са винаги готови за изпълнение и няма забавяния при изчакване на данни. Разбира се, необходимо е да има достатъчно дълга опашка, за да не се запълни с инструкции, чакащи данни, но това е предизвикателство при внедряването. Изпълнението на OOO разчита на преименуване на регистър, за да скрие фалшиви зависимости. Дори ако тези инструкции действително се изпълняват неправилно, регистрите се преименуват по такъв начин, че да скрият този факт от останалата част от компютъра.