En ole koskaan kuullut kenenkään selittävän miksi liukuhihnan pituudella on korrelaatio kellotaajuuteen. Voin nähdä miksi tilastollisesti latenssin ja throughputin välillä käydään optimointitaistoa, mutta en miten kelloalueisiin tai transistorien kykyyn vaihtaa tilaa mitenkään liittyisi laskentayksiköiden liukuhihnojen pituus.
Luulin, että olet joskus suorittanut TTYn/TTKKn"tietokonetekniikka"-kurssin. Siellä kyllä on asia selitetty.
Käskyn suorittamiseen pitää tehdä monta asiaa, yksinkertaisimmillaan esim.
1) hakea käsky (käskyväli)muistista (aikaa kuluu esim. 0.35 ns)
2) dekoodata, että mistä käskystä on kyse, mitä sen pitäisi tehdä, muodostaa tämän perusteella prosessorin sisäiset kontrollisignallit (aikaa kuluu esim. 0.2 ns)
3) lukea käskyn tarvitsema data rekistereistä (aikaa kuluu esim. 0.2 ns)
4) suorittaa varsinainen laskuoperaatio (aikaa kuluu esim. 0.3ns)
5) kirjoittaa tulos kohderekisteriin (aikaa kuluu esim. 0.15ns)
Mikäli mitään liukuhihnaa ei ole, ja käsky suoritetaan kellojaksossa, sen suorittamiseen menee aikaa kaikkein näiden summa eli tässä esimerkissä 1.2ns. Saavutetaan maksimissaan 833 MHz kellotaajuus.
Jos meillä onkin vaikka 2-vaiheinen liukuhinna, ekassa vaiheessa (ekalla kallojaksolla) haetaan käsky sekä dekoodataan se, toisessa vaiheessa (seuravalla kellojaksolla) luetaan data rekistereistä, suoritetaan laskuoperaatio ja kirjoitetaan tulos, nyt kellojaksossa pitää tehdä vain sen verran, mihin pidempi näistä vie aikaa, eli max(0.35 + 0.2 , 0.2 + 0.3 + 0.15) = max(0.55, 0.65) = 0.65ns, eli kellojakso saa kestää maksimissaan 0.65ns. Eli saavutetaankin 1/0.65 = 1.54 GHz kellotaajuus.
Jos meillä on vaikka 3-vaiheinen liukuhihna, ekassa vaiheessa haku, toisessa dekoodaus ja rekisterinluku, ja kolmannessa suoritus ja tuloksentallennus, pisin vaihe on 0.45ns eli saavutetaan 1/0.45ns = 2.2 GHz kellotaajuus.
Neljällä vaiheella yhdistämällä dekoodaus ja rekisterin luku pisin vaihe on dekoodaus+rekisterinluku eli 0.4 ns, eli saavutetaan 2.5 GHz kellotaajuus.
Viidellä vaiheella pisin vaihe on käskynhaku eli 0.35ns, eli saavutetaan 2.86 GHz kellotaajuus.
Splittaamalla käskyhaku kahteen osaan, kuusivaiheisella liukuhihnalla pisin vaihe olisi suoritus eli 0.3ns, saavutettaisiin 3.33 GHz kellotaajuus.
Käytännössä tosin liukuhinavaiheiden väliin tulee aina liukuhihnarekisteri (viive joitain kymmeniä pikosekunteja) joten kellotaajuus ei todellisuudessa skaaladu ihan näin hyvin, ja lisäksi joitain asioita ei vaan pysty splittaamaan useaan liukuhihnavaiheeseen järkevästi johtuen siitä, mitä se tekee.
Toki sitten prosessorin rakenteen monimutkaistuessa väliin tulee sellaisia liukuhihnavaiheita jotka tekevät asioita, joita yksinkertaisen prosessorin ei tarvitse ollenkaan tehdä. Esim. perinteisillä 1980-luvun RISC-prossuilla on tuossa laskuoperaatio(EXEC)- ja tuloksentallennusvaiheen(WB) välissä muistiaccess-vaihe (MEM) (ja niissä myös dekoodaus ja rekisterinluku oli yhdistetty samaksi vaiheeksi).
Ja siihen, kuinka paljon aikaa tarvitaan suoritukseen vaikuttaa aika paljon se, millaisia käskyjä on. kokonaislukujen kertolasku vaatii n. 2-3x enemmän aikaa kuin yhteen-/vähennyslasku, joten suurimmassa osassa prossuista on sitten rakenne jossa kertolaskulla on pidempi liukuhihna(ja siis enemmän viivettä käskyllä kellojakoissa mitattuna) kuin yhteen- ja vähennyslaskulla.
Rekistereitä uudelleennimeävät ja käskyjä uudelleenjärjestelevät prosessorit taas tarvitsevat vaiheet sille rekisterien uudelleenimeämiselle, käskyjen laittamiselle puskuriin odottamaan suoritusta sekä niiden skedulointiin suoritukseen, sekä vielä tuloksen eläköitymiseen (retire) jolloin käsky virallisesti julistetaan suoritetuksi ja käskyvuo tuodaan takaisin alkuperäiseen järjestykseen. Eli käytännössä monimutkainen ja kehittynyt ydin tarvitsee muutaman vaiheen enemmän päästäkseen samaan kellotaajuuteen.
Kellotaajuuden kannalta ratkaiseva tekijä on siis pisimmän liukuhihnavaiheen pituus, ei suoraan likuhihnan vaiheiden määrä, mutta kun kyse on prosessoreista jotka ovat ominaisuuksiltaan melko samalla tasolla, nämä korreloivat hyvin vahvasti keskenään.