Hvad er udelukket udførelse?

Computere er komplekse maskiner med ingen del mere kompleks end CPU'en. På et grundlæggende overbliksniveau ser det ud til, at CPU'en skulle være forholdsvis enkel. Det tager en række kommandoer, behandler dem og udsender derefter dataene. Dette minder dog lidt om den faktiske funktion af moderne CPU'er.

Sub-skalær til super-skalær

Tidlige CPU'er var præcis, som du ville forvente. De tog instruktionerne individuelt i den rækkefølge, de fik dem, behandlede dem til afslutning og gik derefter videre til den næste instruktion. CPU'er af denne type var sub-skalære, i stand til at fuldføre mindre end én instruktion pr. clock-cyklus. CPU-designere identificerede, at der var mange forskellige stadier af fuldførelsen af ​​en instruktion. Hver af disse stadier krævede forskellig hardware. Dette betød, at når man kørte en enkelt instruktion gennem hele sekvensen ad gangen, sad nogle dele af hardwaren inaktiv. I enhver form for processor er inaktiv hardware ubrugelig hardware.

For at bruge denne ledige hardware blev CPU-designs opdateret til at bruge en pipeline-tilgang. Dette adskilte yderligere hardwaren for hvert trin, men tillod dem alle at blive brugt på samme tid af en række instruktioner. Selvom det stadig tog et par cyklusser for hver instruktion at gå gennem pipelinen, var den samlede gennemstrømning én instruktion pr. cyklus. Dette gjorde CPU'er skalære.

For at kunne mere, skulle processorer gøres super-skalære. For at opnå dette blev der implementeret flere parallelle rørledninger.

Holde rørledninger fodret med data

Det største ydelsesproblem med computere er typisk hukommelsesforsinkelse. Mange instruktioner opererer på data, og så data skal være tilgængelige for at instruktionen kan udføres. Spørgsmålet er, hvad du gør, hvis du skal vente på disse data, fordi de ikke er tilgængelige med det samme? Traditionelt var svaret bare at gå i stå og vente på, at det blev tilgængeligt. Dette efterlader hele pipelinen tom, potentielt i hundredvis af CPU-cyklusser. Tingene bliver endnu værre, når to instruktioner i parallelle pipelines skal vente på hukommelse, da den første vil holde selv anmodningen om den andens data op. Selvom CPU-cachehukommelse kan hjælpe med at løse dette problem, kan den stadig ikke løse det. Der skulle et nyt paradigme til for at løse det. Det paradigmeskift var Out Of Order Execution eller OOO.

Den første fase af en pipeline er at afkode instruktionen. Det betyder at finde ud af, hvad der skal gøres, og at verificere, at de nødvendige data til operationen er tilgængelige. I en OOO CPU tilføjes afkodede instruktioner til en kø. De fjernes først fra køen og behandles faktisk, når de data, de har brug for, er tilgængelige. Kritisk set er det ligegyldigt, hvilken rækkefølge instruktionerne blev tilføjet til køen. Hvis en tidlig instruktion venter på data, kan en nyere instruktion springe videre, hvis den er klar til at gå. OOO-processorer kan omarrangere de instruktioner, de skal behandle, baseret på køen af ​​kommende instruktioner, og hvilke af dem der er klar til eksekvering.

Kritiske afhængigheder

Denne proces forudsætter to ting. Først og fremmest, at det er muligt pålideligt at identificere og håndtere ægte afhængigheder. For det andet, at du pålideligt kan håndtere og identificere falske afhængigheder. Hvad er forskellen? Nå, en ægte afhængighed er en afhængighed, der slet ikke kan afbødes i et OOO-system. Det nemmeste eksempel er læse-efter-skrive. Hvis du har en instruktion, der skal skrive nogle data, og en anden, der skal læse disse data, er der ingen måde at omarrangere disse instruktioner. De skal udfyldes i den rækkefølge, de blev præsenteret i, ellers får du nonsens-data.

En falsk afhængighed er en, der kan skjules med et andet smart trick. Lad os tage eksemplet med at skrive-efter-læse. Ved første øjekast tror du måske, at du ikke kan overskrive data, før du har læst dem. Tingene er dog ikke så enkle. Hvad hvis du har et andet sted, du kan skrive de nye data, og så kan du bare bytte de nye og gamle data, når de gamle data er blevet læst? Dette er processen med at omdøbe registeret, og det er afgørende for OOO-behandling.

Typisk definerer et instruktionssæt et sæt antal arkitektoniske registre, der bruges i systemet. Du kan bogstaveligt talt ikke henvende dig til andre. Men hvad hvis du laver overforsyningsregistre? Du kan bare skjule dem for det meste, bruge dem til at gemme data, der ikke skulle have været behandlet endnu, og så bare bytte etiketterne på de skjulte og arkitektoniske registre, når tidslinjen er korrekt igen. Til enhver tid er der den helt rigtige mængde af arkitektoniske registre, de er bare ikke nødvendigvis altid det samme sted. En analogi fra den virkelige verden ville være hot-deking.

Konklusion

Out Of Order eksekvering er et behandlingsparadigme, hvor instruktioner kan omarrangeres dynamisk på udførelsestidspunktet af CPU'en. Dette sker på baggrund af de tidligst udstedte instruktioner, der har data til rådighed. Det betyder, at instruktioner, der indlæses i pipelinen, altid er klar til at blive eksekveret, og der er ingen forsinkelser, mens man venter på data. Selvfølgelig er det nødvendigt at have en lang nok kø til, at den ikke bliver fyldt med instruktioner, der venter på data, men det er en implementeringsudfordring. OOO-udførelse er afhængig af registeromdøbning for at skjule falske afhængigheder. Selvom disse instruktioner rent faktisk udføres i uorden, omdøbes registrene på en sådan måde, at de skjuler dette for resten af ​​computeren.