AdoredTV on spekuloinut Zen3-suorituskyvyllä (kohdasta 12:50 alkaen).
"Hyvin luotetun lähteen" mukaan peräti +20% yhden säikeen kokonaislukusuorituskykyyn, mutta kaikki ytimet täysillä paahtaessa ero pienenee tasolle +10-15%.
AdoredTV nyt höpisee aina mitä sattuu.
~20% nopeutus saadaan ehkä muutamalla sellaisella softalla, joiden aktiivinen datasetti osuu juuri 16 megan ja 32 megan välille siten että ne hyötyvät maksimaalisesti yhden ytimen käytössä olevan L3-välimuistin koon kasvattamisesta. Keskimääräinen nopeutus onkin sitten selvästi alempana.
Spekuloidaan nyt sillä, että sisäpiirin lähteet olisivat tällä kerralla oikeassa.
Ei oikein mitään muuta keinoa jää jäljelle toteuttaa noin isoa hyppäystä kuin alentaa usein käytettyjen käskyjen latensseja.
Ei. Se on nimenomaan keino, jolla sellaista ei saada aikaan, koska varaa tähän ei yksinkertaisesti ole (absoluuttisessa ajassa mitattuna).
Tämähän on jo kerran toteutettu Pentium 4:ssä tuplanopeus-ALUjen muodossa. Siitä on sopivasti 20 vuotta, eli patentit ovat umpeutuneet tai umpeutumassa. Tuolloin niiden suorituskykyetu jäi muiden hyvin kyseenalaisten arkkitehtuuriratkaisujen varjoon.
EI niitä ALUja voi vaan kellottaa nopeammiksi kuin mihin niiden viivet antaa myöten.
Willamette- ja Northwood-P4sten tuplanopeus-ALUt perustuivat ratkaisuun, jossa ylimmät bitit laskettiin puoli kellojaksoa myöhemmin kuin alimmat bitit, ja flagit vielä kokonaisen kellojakson myöhemmin kuin alimmat bitit. Mutta sitten kun pitäisikin tehdä vaikka shiftaus alaspäin, ei tämä toimi, kun alempien bittien laskemiseen tarvitaan ylempiä bittejä. Tämän takia Pentium 4ssa mm. shiftausta ei ollut toteutettu nopeissa ALUIssa vaan hitaissa ALUIssa, ja datansiirto hitaiden ja nopeiden ALUjen välillä maksoi pari kellojaksoa ylimääräistä (eli oli siis todella hidasta)
P4n nopeiden ALUjen tarkoitus oli lähinnä että data kiertää nopeasti esim. välillä:
1) meillä on pointteri
2) pointteriin lasketaan yhteen offsetti ja tämän tuloksen perusteella tehdään muistihaku.
3) ladattua arvoa voidaan käyttää uudestaan pointterina ja palata kohtaan 1.
Muistihaussa P4n hyvin yksinkertaisella L1D-välimuistilla alimmat bitit riittivät siihen, että tiedetään mistä kohtaa L1D-kakkua pitää indeksoida, joten nopeat ALUt sopivat tähän.
Mutta tosiaan, kun Willamettellä/Northwoodilla teki mitä tahansa muuta kuin ajoi koodia, joka pyöri pelkästään nopeilla ALUIlla, se kävi hyvin hitaaksi.
Intel luopui nopeista ALUista jo viimeisessä P4-versiossa Prescottissa, koska niistä oli enemmän haittaa kuin hyötyä, ja lisäksi ilmeisesti niiden totetuttaminen 64-bittisenä olisi syönyt kellotaajuutta.
Mutta jos mietitään miten nykyisistä prossuista voisi viiveitä järkesti pienentää,. niin:
Yhteenlasku, shiftaukset ja loogiset operaatiot suoritetaan yhdessä kellojaksossa, niissä ei ole järkevää parannettavaa( P4-tyyppiset nopeast ALUta vaan ei ole järkevä vaihtoehto)
L1-välimuistin viive on 4-5 kellojaksoa ja sen saaminen nopeammaksi (jos osumatarkkuus pysyisi samana) auttaisi kyllä saamana paremman IPCn, mutta sen nopeuttamiseen ei ole järkeviä edellytyksiä ilman että siitä samalla tehtäsiiin osumatarkkuudeltaan paljon huonompi.
Kokonaislukukertolaskulla on sitten n. 3 kellojakson viive ja jakolaskulla vielä paljon pidempi, mutta jakolaksu on hyvin harvinainen operaatio ja 64-bittistä kertolaskua on vaikea saada alle 3 kellojaksoon nykyisillä kellotaajuuksilla.
Suuria keskimääräisiä IPC-parannuksia ei enää saada
millään yksittäisellä asialla vaan sillä, että tehdään
suuri määrä erillisiä 0.5-2 % parannuksia.
Keksitään uusi haarautumisenennustusalgoritmi. Viilataan jotain ennen pullonkaulana ollutta puskuria n. 10% suuremmaksi. Mahdollistetaan jonkun ennen vain yhdessä ALUssa suoritetun käskun suorittaminen kahdessa eri ALUss . Mahdollistetaan useamman käskyn hakeminen yhtä aikaa micro-op-välimuistista ja useamman käskyn yhtäaikainen rekisterien uudelleennimeäminen. Kasvatetaan TLBtä sen osumatarkkuuden parantamiseksi. Lisätään uloimman tason välimuistin kokoa. Tehdään kunnollinen nopea rautaimplementaatio jostain harvoin käytetystä käskystä, joka aiemmin suoritettiin mikrokoodilla, tai korjataan joku rautabugi jonka mikrokoodilla toteutettu kierto hidasti jotain käskyä/joitain käskyjä. Viilataan muistin prefetcheriä. Optimoidaan välimuistien välisiä dataväyliä ja onnistutaan tällä tällä saamaan L2-välimuistin viiveestä kellojakso pois.
Toisaalta, voidaan myös pienentää jotain puskuria jos sen koko ei käytännössä koskaan ole pullonkaula ja tämän puskurin pienentäminen auttaa joko suurentamaan jotain muuta tai saavuttamaan 1% suuremman kellotaajuuden.
Jos yritetään tehdä mitä tahansa "yksittäistä suurta parannusta", sillä on aina tradeoffinsa; Laskentayksiköiden lisäämisestä hyödytään melko vähän koska softissa ei vaan riitä rinnakkaisuutta, mutta leveämpi ydin on haastavampi saada kellottumaan yhtä korkealle. Se, että yritetään pudottaa viiveitä sattuu vielä helpommin kellotaajuuteen. Välimuistin kasvattaminen taas helposti hidastaa sitä, jolloin pitää lisätä viiveitä tai hyväksyä alempi kellotaajuus.
Transistorien suuri virrankulutus oli silloin ongelma ja niin epäilemättä nytkin. Intel ei nykyään ole tuota ottanut käyttöön, koska mobiili- ja serveripuolen on oltava energiatehokkaita. AMD:llä on kuitenkin erittäin hyvä dynaaminen tehonhallinta, joten se voisi ehkä tuosta jonkinlaisen rajatun toteutuksen ottaa käyttöön?
Ei. P4n huono energiatehokkuus johtui pääasiassa muista asioista kuin nopeista ALUista; Se johtui mm. seuraavista asioista
1) sen liukuhihna oli niin pitkä, että sen käskyskedulerikin piti liukuhihnoittaa siten että se skeduloi käskyjä tietämättä, saako niitä vielä skeduloida, ja mikäli ei saanut (esim. koska käsky tarvi dataa joka tuli lataukselta jolla tulikin välimuistihuti), käsky suoritettiin sitten myöhemmin uudestaan => samojen käskyjen suorittaminen moneen kertaan haaskasi paljon sähköä
2a) sen L1D-kakku oli write-through-tyyppiä eli heti kun sinne kirjoitettiin mitä tahansa, se flushasi ne L2-kakkuun
2b) sen L1D-kakku oli muutenkin niin pieni, että dataa piti jatkuvasti hakea L2-kakusta asti
2=2a+2b) paljon lisää liikennettä välimuistien välillä, ja datansiirrot tuhlaa aina sähköä
3) P4ssa oli melko agressiivinen prefetcheri joka haki dataa L2-välimuistiin melko aggressiivisesti. Prefeetcheirn tekemät musitihaut kuluttivat huomattavasti virtaa.