Hva er utførelse i ute av drift?

Datamaskiner er komplekse maskiner med ingen del mer kompleks enn CPU. På et grunnleggende oversiktsnivå virker det som om CPU-en skal være relativt enkel. Den tar en rekke kommandoer, behandler dem og sender deretter ut dataene. Dette ligner imidlertid lite på den faktiske funksjonen til moderne CPUer.

Sub-skalær til super-skalær

Tidlige CPU-er var akkurat som du forventer. De tok instruksjoner individuelt, i den rekkefølgen de ble gitt dem, behandlet dem til fullføring, og gikk deretter videre til neste instruksjon. CPUer av denne typen var sub-skalære, i stand til å fullføre mindre enn én instruksjon per klokkesyklus. CPU-designere identifiserte at det var mange forskjellige stadier for å fullføre en instruksjon. Hvert av disse stadiene krevde forskjellig maskinvare. Dette betydde at når du kjørte en enkelt instruksjon gjennom hele sekvensen om gangen, var noen deler av maskinvaren uvirksomme. I enhver form for prosessor er inaktiv maskinvare ubrukelig maskinvare.

For å bruke denne ledige maskinvaren ble CPU-design oppdatert for å bruke en pipeline-tilnærming. Dette skilte maskinvaren ytterligere for hvert trinn, men tillot dem alle å bli brukt samtidig av en rekke instruksjoner. Selv om det fortsatt tok noen få sykluser for hver instruksjon å gå gjennom rørledningen, var den totale gjennomstrømningen én instruksjon per syklus. Dette gjorde CPU-ene skalære.

For å kunne gjøre mer, måtte prosessorer gjøres superskalære. For å oppnå dette ble flere parallelle rørledninger implementert.

Holde rørledninger matet med data

Det viktigste ytelsesproblemet med datamaskiner er vanligvis minneforsinkelse. Mange instruksjoner opererer på data, og slik at data må være tilgjengelig for at instruksen skal utføres. Spørsmålet er, hva gjør du hvis du trenger å vente på disse dataene fordi de ikke er umiddelbart tilgjengelige? Tradisjonelt var svaret bare å stoppe og vente på at det ble tilgjengelig. Dette etterlater hele rørledningen tom, potensielt i hundrevis av CPU-sykluser. Ting blir enda verre når to instruksjoner i parallelle rørledninger må vente på minne, da den første vil holde opp selv forespørselen om den andres data. Selv om CPU-bufferminne kan hjelpe med å løse dette problemet, kan det fortsatt ikke fikse det. Et nytt paradigme måtte til for å løse det. Det paradigmeskiftet var Out Of Order Execution eller OOO.

Det første trinnet i en rørledning er å dekode instruksjonen. Dette betyr å finne ut hva som må gjøres, og verifisere at dataene som trengs for operasjonen er tilgjengelige. I en OOO CPU legges dekodede instruksjoner til i en kø. De blir bare fjernet fra køen og faktisk behandlet når dataene de trenger er tilgjengelige. Kritisk sett spiller det ingen rolle hvilken rekkefølge instruksjonene ble lagt til i køen. Hvis en tidlig instruksjon venter på data, kan en nyere instruksjon hoppe over hvis den er klar til å gå. OOO-prosessorer kan omorganisere instruksjonene de skal behandle basert på køen av kommende instruksjoner og hvilke av disse som er klare for utførelse.

Kritiske avhengigheter

Denne prosessen forutsetter to ting. Først av alt, at det er mulig å pålitelig identifisere og håndtere sanne avhengigheter. For det andre at du pålitelig kan håndtere og identifisere falske avhengigheter. Hva er forskjellen? Vel, en ekte avhengighet er en avhengighet som ikke kan reduseres i det hele tatt i et OOO-system. Det enkleste eksemplet er les-etter-skriving. Hvis du har en instruksjon som skal skrive noen data og en annen som skal lese disse dataene, er det ingen måte å kunne omorganisere disse instruksjonene. De må fylles ut i den rekkefølgen de ble presentert i, ellers får du tulldata.

En falsk avhengighet er en som kan skjules med et annet smart triks. La oss ta eksemplet med å skrive-etter-lese. Ved første øyekast tror du kanskje at du ikke kan overskrive data før du har lest den. Ting er imidlertid ikke så enkelt. Hva om du har et annet sted du kan skrive de nye dataene, og så kan du bare bytte de nye og gamle dataene når de gamle dataene er lest? Dette er prosessen med å endre navn på registeret, og det er avgjørende for OOO-behandling.

Vanligvis definerer et instruksjonssett et sett antall arkitektoniske registre som brukes i systemet. Du kan bokstavelig talt ikke henvende deg til noen andre. Men hva om du gjør overprovisjonsregistre? Du kan bare skjule dem for det meste, bruke dem til å lagre data som ikke skulle ha blitt behandlet ennå, og så ganske enkelt bytte etikettene til de skjulte og arkitektoniske registrene når tidslinjen er riktig igjen. Til enhver tid er det nøyaktig riktig mengde arkitektoniske registre, de er bare ikke nødvendigvis alltid på samme sted. En analogi fra den virkelige verden ville være hot-desking.

Konklusjon

Out Of Order-utførelse er et behandlingsparadigme der instruksjoner kan omorganiseres dynamisk ved utførelsestidspunkt av CPU. Dette gjøres på grunnlag av de tidligste utstedte instruksene som har data tilgjengelig. Dette betyr at instruksjoner som lastes inn i rørledningen alltid er klare til å bli utført og det er ingen forsinkelser mens man venter på data. Selvfølgelig er det nødvendig å ha en lang nok kø til at den ikke blir fylt med instruksjoner som venter på data, men det er en implementeringsutfordring. Kjøring av OOO er avhengig av navn på register for å skjule falske avhengigheter. Selv om disse instruksjonene faktisk blir utført i uorden, blir registrene omdøpt på en slik måte at de skjuler dette faktum fra resten av datamaskinen.