AMD:n yksi ongelma on nimenomaan se, että sen prossut vaativat tuollaisia optimointikikkailuita selkeästi intelin prossuja enemmän.
Eikä vaadi.
Keskimäärin juuri päin vastoin.
Pentiumin suorituskyvyn hyödyntäminen vaati huomattavaa käsin optimointia prosessorin kahdelle erilaiselle epäsymmetriselle liukuhihnalle, K5 ja K6 taas suorittivat huonostikin optimoitua koodia nopeasti, koska ne uudelleenjärjestelivät itse käskynsä.
Pentium Pro:n rekisterien uudelleennimeäminen ei pitänyt koodista, jossa käytettiin sekaisin 16- ja 32-bitisiä rekistereitä ja stallaili niissä, ja vanhat sofat sisälsi paljon tällaista koodia. Softat piti optimoida P6lle että ne pyöri hyvin. K6ssa ei tällaista rajoitetta ollut.
Pentium 3n uusien SIMD-käskyjen hyödyntämiseen(SSE) ei riittänyt että softa tuki niitä vaan käyttiksenkin piti tukea niitä, siinä missä K6-II:n uusien SIMD-käskyjen(3dnow!) hyödyntämiseen riitti että softa tukee niitä.
Pentium 4 ajoi hyvin huonosti aiemmille prosessoreille optimoitua koodia ja sille piti kaikki optimoida aivan eri tavalla kuin aiemmille prosessoreille. Esim. kaikilla muilla prosessoreilla optimaalinen tapa kertoa neljällä oli shiftata lukua kahden bitin verran vasemmalle. P4-ssa shiftaus oli hidas operaatio ja luku kannattikin laskea yhteen itsensä kanssa pari kertaa (ja tämä P4-optimoitu koodi taas sitten on hitaampi kaikilla muilla prosessoreilla, koska siinä tulee kaksi peräkkäistä ksäkyä joiden välillä datariippuvuus eli ei voi laskea niitä rinnakkain)
Intelin 1. sukupolven Atom(Bonnell) oli in-order ja stallaili pahasti koodiin joka oli sille huonosti optimoitu. Kilpaileva AMDn bobcat uudelleenjärjesteli käskynsä ja suoritti mitä tahansa koodia tasaisella (1. sukupolven atomia paremmalla) nopeudella.
Ja Zenille optimointi ei vaadi mitään "kikkailuita", päin vastoin. Esim. Age of Singularityssä oikea optimointi zenille oli se, että
POISTETTIIN KÄYTÖSTÄ kikkailu, josta intelillä ei ollut käytännössä mitään hyötyä, vaan jonka vaikutus intelillä oli neutraali, mutta joka zenillä oli haitallinen kikkailu.
Ainakin ne vertailut, joita olen katsellut, niin se optimoitu versio pelistä on pyörinyt hieman nopeammin myös intelin prossuilla.
Tuo optimointi liirumlaarumi tuli lähinnä vasta, kun AMD:n prossuilla tämä suorituskyky kusi rakenteellisista systä Intelin prossuja enemmän.
Jos AMD olisi onnistunut julkaisemaan "hyvän" tuotteen, se olisi ollut alunperinkin vähintään tasoissa pelisuorituskyvyssäkin intelin kanssa. Nyt vain rahkeet ei ihan riittäneet ja jäätiin välttävälle tasolle, joka tosin ei ole huono suoritus sekään, mutta ei missään nimessä hyväkään. Intel on senverran hitaasti kehittänyt noita prossuja, jotta kertakaikkiselle edelle kurvaamiselle ei olisi pitänyt olla mitään estettä.
Olet kyllä totaalisen pihalla siitä, kuinka vaikea homma nykyaikaisen CPUn kehittäminen on. Se on oikeasti
todella vaikeaa.
Jotkut OoOE-ytimen perustoiminnallisuudet on julkisesti tiedosssa siten että sellaisen perusarkkitehtuurin pystyisin itse inhimillisessä ajassa kehittämään (in-order-arkkitehtuureita olen jo kehittänyt), mutta sitten kun mukaan pitää ottaa muistioperaatioiden uudelleenjärjestely niiden konsistenttius silti säilyttäen, täysi x86-yhteensopivuus duplikoiden jotain 80286n bugeja, joista on tullut osa de facto-x86-standardia, tarkka haarautumisenennustus jossa Intel on paljon yliopistoja edellä ja josta parhaista tekniikoista ei tule edes tieteellisiä papereita koska firmat ei halua paljastaa miten ne sen tekee, selviäminen jostain virtuaalimuistisivuen väliin tulevasta unaligned-muistiaccessista jonka toinen puoli aiheuttaa virtaalimuistin läsnäolopoikkeuksen ja toinen ei jne.
Ja näiden kaikkien tekeminen siten, että se CPU jatkuu porskuttamistaan hyvällä nopeudella vaikka joku todella ikävää tilanne tulee vastaan. Ja sitten kun suunnitellaan uusi ydin jonka rakenne on erilainen, ratkaisuita näihini ei vaan voi kopioida vanhasta ytimestä vaan pitää kehittää näihin uudet sen ytimen rakenteen kanssa yhteensopivat ratkaisut.
Pentium 4 ja Bonnell-Atom olivat juuri parhaita esimerkkejä arkkitehtuureista, joissa kaikki nämä "likaiset asiat" oli toteutettu siten, että ne toimivat, mutta tällaisen "likaisen tapauksen" tuleminen vastaan käytännössä jumitti prosessorin kymmeniksi tai jopa sadoiksi kellojaksoiksi. Valitettavasti vaan näiden "likaisten tapausten" yleisyys ei ole luokkaa yksi miljardissa käskyssä vaan pikemminkin yksi tuhansissa.
Myös bulldozer oli jossain näissä jutuissa hiukan pahempi kuin esim. K7- P6- tai sandy-bridge-johdannaiset, muttei läheskään niin paha kuin P4 tai Bonnell.
Ja tosiaan, ei ole
mitään varmaa keinoa saada yhden säikeen suorituskykyä lisää vaikka käytettävissä olisi loputtomasti transistoreita:
Softissa ei vaan riitä käskytason rinnakkaisuutta hyödyntämään useampaa rinnakkaista laskentayksikköä. Paremmalla haarautumisenennustuksella saadaan sitä käskytason rinnakkaisuutta käyttöön hiukan enemmän, mutta niissä kyse on algoritmikehityksestä.
Jos tehdään prosessori jolle yritetään tehdä enemmän rinnakkaisia laskentayksiköitä, niiden kytkeminen toisiinsa alkaa hidastaa kellotaajuutta ja lisätä sähkönkulutusta, eikä niistä silti saada juurikaan hyötyä, hyöty menee helposti negatiiviseksi.
Liukuhihnaan pidentämällä kellotaajuutta saadaan lisää, mutta tiettyjä vaiheita ei vaan tehokkaasti voi liukuhihnoittaa enempää, tai sitten sen liukuhihnoittamisen mahdollistamiseksi pitää tehdä sellaisia arkkitehtuurillisia ratkaisuja jotka huonontavat kellotaajuuskohtaista suorituskykyä selvästi. (nähty P4ssa ja bulldozerissa; mm. replay-mekanismi ja WT-L1D)
Jos välimuisteja yrittää kasvattaa, ne käy hitaammiksi. Välimuisteissa pitää pitää hierarkia ja niissä voidaan käytännössä kasvataa vain ulointa tasoa ja tuoda lisää tasoja "uloimpaan päähän", mutta sekin sitten lisää muistin viivettä.
Monen x86-käskyn rinnakkainen dekoodaus käy hyvin monimutkaiseksi, hitaaksi ja virtasyöpöksi, eikä kukaan yritä dekoodata enempä kuin neljää (bulldozer ja lake-sarjan prossut ilmeisesti pystyvät looppipuskuristan fetchaamaan yli 4 käskyä, mutta looppipuskurissa käskyjä ei näissä säilytetä alkuperäisessä x86-muodossa vaan helpommassa muodossa).
Uusilla erikoiskäskyillä suorituskykyä voi saada vielä lisää, mutta vasta kun softat hyödyntävät niitä. Zenissä tuleva CLZERO on näppärä käsky käyttöjärjestelmän muistinhallinnalle, Intelin AVX-512 taas mahdollistaa monien sellaisten looppien rinnakkaistamisen, joita ennen ei ole voinut rinnakkaistaa, ja TSX:llä saadaan synkronointia säikeiden välillä tehostettua kivasti.
Käytännössä näiden käyttöönotossa softissa kuintenkin menee vuosia, ja sen parin vuoden ajan kun softat ei näitä osaa käyttää, fanipojat sitten vinkuvat että prossuissa tulee turhia ominaisuuksia joista ei ole mitään hyötyä.
Zen+ tuskin pelastaa tilannetta vielä mihinkään, Zen 2 saattaa pelastaa, toivottavasti.
Ei ole mitään "pelastamisen tarpeessa" olevaa. on vain tarvetta pienille parannuksille, kuten aina.
Zen on oikein hyvä arkkitehtuuri. Se vaan yhden säikeen suorituskyvyssä on hiukan Intelin Lake-sarjan prossuja hitaampi. Ja siinä zen+ tulee auttamaan koska kellotaajuudet (joissa zen on tällä hetkellä huonomman valmistustekniikan takia intelin jäljessä) tulee nousemaan.
Ja se modulirakenne ei ole mikään paha pullonkaula. Se on jonkinlainen pullonkaula, mutta siinä on omat hyvät puolensakin, esimerkiksi sen ansiosta L3-viive siihen modulin omaan 8 megan on pienempi kuin Intelin prossujen L3-viive.
Ja se mahdollistaa kivan modulaarisen rakenteen, joka mahdollistaa monien eri piirien tekemisen pienellä R&D-vaivalla.
Mitä läppäreihin tulee, niin sen sitten näkee. Intelin prossu+GPU kombo on kuitenkin ei pelikäyttöön täysin riittävä ja ilmeisesti AMD:n vaihtoehtoa virtapihimpi.
Virtapihimpi käsittääkseni lähinnä vain videotoistossa, kun AMDllä käytössä varhaiset ajurit?
Voi hyvin olla, että nykyajureilla softalla tehdään asioita, jotka myöhemmillä ajureilla tehdään raudalla, kun ajurit on vielä keskeneräiset.
Nyt taitaa sinulta selitykset loppua 
