Kyllä se voi olla prossuvalmistajan vika jos se sille pitää kodata ihan erillä tapaa kun toiselle.
Tyyliin jotkut ekojen ryzenien järkyttävän hitaat käskyemulaatiot joilla ei tee mitään.
Se, että siellä on jostain äärimmäisen harvoin käytettävästä käskystä mikrokoodilla toteutettu versio ei tee siitä mitään" emulointia" ja niillä nimenomaan tekee hyvin paljon, niillä tekee sen, että niitä käyttävät softat
toimii.
Jos yksi sellainen käsky suoritetaan keskimäärin miljoonan kellojakson välein, sillä, että siihen menee parisataa kellojaksoa ei ole kokonaissuorituskyvyn kannalta mitään väliä.
Toki jos joku softa haluaakin käyttää niitä keskimäärin vaikka tuhannen eikä miljoonan kellojakson välein, silloin sillä alkaakin olemaan jo huomattavasti väliä, mutta siltikin edelleen sillä käskyllä tekee hyvin paljon. Sillä tekee silti sen, että se softa
toimii.
Erot Intelin prossujen ja Ryzenien välillä optimoinnin suhteen on käytännössä hyvin pieniä. Molemmissa on samankokoiset välimuistilinjat, joka on oleellinen asia mm. sen kannalta, miten data kannattaa sijoitella muistiin, ja miten dataa voi pilkkoa palasiksi jaettavaksi monelle ytimelle ilman että false sharing tulee ongelmaksi. Molemmat on moderneja OoOE-prossuja jotka eivät tarvi tarkkaa käskyskedulointia, vaan osaavat itse skeduloida suorituksensa, kunhan inputissa on vaan jotain järkeä (ja joo, yhdessä todellisessa pelissä vastaan tuli yksi tapaus, jossa inputissa ei ollut järkeä, tästä alempana lisää).
Zen2sta lähtien sekä Intelin että AMDn työpöytäprossuissa on myös ollut sama tilanne SIMD-käskykantojen suhteen, eli että sieltä löytyy 256-bittisellä toteutuksella oleva AVX2. Ja Zen1 jo tuki AVX2sta, tosin puolinopeusimplementaatiolla, mutta eipä siinäkään SSE4:n käyttäminen sen AVX2n sijasta juurikaan hyödyttänyt, joten käytännössä optimointi AVX2lle on ollut järkevää jo vuosien ajan molempien prossuilla.
Suurin ero optimoinnista Zen-sarjan ja intelin prossujen välillä tulee käytännössä Zenin CCX-rakenteesta, että miten asioita kannattaa säikeistää ja säikeiden jakaa dataa keskenään, intelillä on yksi jaettu L3-välimuisti, Zenillä taas useampia erillisiä L3-välimuisteja, ja jos samaa dataa käpistelee eri CCXssä olevat ytimet, tästä voi seurata epäoptimaalisuuksia. Mutta Zen3 muuttaa tätäkin lähemmäksi Inteliä, kun Zen3ssa saman L3-kakun jakavien ytimien määrä noysee kahdeksaan, ja Intelilläkään ei toisaalta seuraavassa sukupolvessa tule enempää kuin kahdeksaa ydintä, 10-ytimiset intelin työpöytäprossut jäi hyvin harvinaisiksi välimalleiksi.
Ja joo, Zen1llä ja Zen2lla oli niitä joitain yksittäisiä hyvin hitaita käskyjä(pdep, pext), mutta ne ei ole mitään sellaisia käskyjä joita tyypillisesti suoritetaan usein. Ja jotkut jonkin verran useammin mutta silti melko harvoin käytetyt käskyt (mm. gather) on myös selvästi (muttei tähtitieteellisesti) hitaampia kuin lake-sarjan prossuilla, mutta näiden nopeus on sellainen että sen tekemiseen mitä niillä tehdään ei ole mitään nopeampaakaan tapaa, niitä haluaa silti käyttää Zen1/zen2llakin.
Tapaus ashes of singularity:
Ja joo, Zenillä oli store-to-load-forwarding ei toimi usean non-temporal storen yli, ja tällaisen jälkeen dataa lataava load hidastui todella paljon. Vanha visual studio 2015 teki koodia, jossa nämä käskyt oli tässä "väärässä järjestyksessä" visual studio 2017 oli jo korjattu siten, että se skeduloi käskyt siten, että se store-to-load-forwarding toimii paljon useammin (eli siis toimii mm. ashes of singularityn tapauksessa).
Tosin se, että kirjoitetaan koodia jossa talletetaan arvo non-temporal storella ja sen jälkeen heti perään ladataan se on muutenkin typerää koodia ja veren kerjäämistä nenästä; Tämän koodin
kuuluisikin olla hidasta. Se, että se joillain prossuilla tai kääntäjillä toimii nopeasti on pikemminkin hyvää tuuria.
Lähinnä optimoinnissa AMDn ja Intelin prossujen välillä oleellista eroa tulee siinä vaiheessa kun Intel julkaisee AVX-512sta tukevat työpöytäprossut, että tällöin motivaatio alkaa optimoimaan softia sille kasvaa selvästi. Paitsi että ei ehkä kasvakaan, koska tätä iloa saadaan ehkä nauttia alle vuoden kunnes se ehkä jälleen katoaa Adler Lakessa. Ja tällöin se saattaakin kääntyä toisinpäin, että AMDllä voi Zen4ssa olla AVX-512 mutta Intelillä Adler Lakessa ei.
(IMHO käsittämätöntä tunarointia Inteliltä että edes AVXää ei ole saatu tuotua kaikkiin tuotteisiin (Lakefield) n. 9 vuotta sen ensimmäisen tulemisen jälkeen , ja AVX-512-tuen suhteen tuki on satunnaisissa tuotteissa, eikä ollenkaan työpöytäkoneissa, joita softankehittäjät pääsiassa käyttää; Vaikka sen eka implementaaatio (Skylake-SP/Skylake-X/Cascade Lake) on ollut suorituskyvyn kannalta huonohko, se, että se olisi tuettu edes jossain normaaleissa työpöytämalleissa mahdollistaisi sen, että softankehittäjät voisivat helpolla hankkia edes normaalin työpöytäkoneen, jossa testata sitä, mutta eipä sitten Intel saanut aikaiseksi tuoda edes Skylake-SP-ytimiä työpöytäkannoille, eikä myöskään Cannon Lakesta tai Ice Lakesta tullut mitään malleja työpöytäkannoille)