Ehdion hukkamaan lähteen, vaikea oli löytää.
Menet taas asian vierestä. Excavatorin suunnittelu aloitettiin Zenin suunnittelun kanssa suunnilleen samoihin aikoihin.
Ei, vaan pari vuotta aiemmin.
Excavator nähtiin jo mm. lokakuussa 2011 julkaistuissa slideissä.
Excavatorin tiedetiin olevan marginaalitapaus jonka myyntimäärät jäävät pieniksi ja joka tehdään vanhentuneella 28nm valmistusprosessilla.
Suunnittelun alussa ei.
Ensinnäkin, noiden APUjen myyntimäärät on tyypillisesti olleet paljon suurempia kuin AMDn erillis-CPUiden.
Toisekseen, siinä vaiheessa kun mikroarkkitehtuurin suunnittelu aloitettiin, siitä oli vielä tarkoitus tehdä myös iso Opteron-/FX-sarjalainen pelkkä CPU-piiri.
Steamroller- ja excavator-pohjaiset pelkät CPU-piiirit kuitenkin peruttiin siinä vaiheessa, kun AMD tajusi, että ne eivät olisi kilpailukykyisiä, ja päätti säästää tuotekehityksessä eikä tuhlata turhaan rahaa piireihin, joiden tuoteketyskustannuksia ei saisi katettua, ja toi näistä ulos pelkästään APU-piirit, ja jatkoi piledriver-pohjaisen Visheran valmistusta rinnan Kaverin kanssa.
Joten miksi AMD tekisi noinkin suurta arkkitehtuurimuutosta marginaalitapaukseen
Mistä ihmeen suuresta arkkitehtuurimuutoksesta nyt oikein puhut? Se, että aivan samanlaisten cache-wayden määrä nostetaan neljästä kahdeksaan ei ole mikään suuri arkkitehtuurimuutos. Se on vaadittavan tuotekehityksen kannalta todella yksinkertainen arkkitehtuurimuutos moneen muuhuin verrattuna.
ellei siitä saataisi yhtään mitään hyötyä jatkossa? AMD:lle oli ihan sama saako Excavator 5% lisää IPC:ta tai ei.
Ei, vaan pienistä puroista kasvaa suuri virta.
Prosessorien uusien mallien kehittäminen on nykyään nimenomaan sitä, että tehdään 10 kpl pikkuviilauksia, joista jokainen antaa keskimäärin puolen prosentin suorituskykylisäyksen, ja sillä saadaan yhteensä 5% suorituskykyä lisää
Rajallisten resurssien takia kaikki panostus oli Zeniin joten tuon tason muutosta ei tehdä ihan huvin vuoksi. Se on tässä koko ajan se pääpointti.
Tuotekehitysresurssien kannalta välimuistin tuplaaminen on erinomainen tapa käyttää niitä tuotekehitysresursseja. Vaatii hyvin vähän mitään tuotekehitystä. Se, että aletaan kehittämään usuai algoritmeja johonkin haarautumisenennustukseen tai jonkun käskyn toteutukseen vaatii paljon monimutkaisempaa logiikkaa, jossa on paljon enemnän työtä, ja paljon enemmän mahdollisuuksia bugeille eli vaatii myös paljon enemmän testaamista. Ja siinä niiden yksittäisten parannusten suorituskykyhyöty on paljon pienempi.
Olennainen kysymys kuuluu, miksi Excavatorissa se cache suurennettiin 32 kilotavuun? Marginaaliprosessorissa on yksi ja sama saako sillä jonkun 5% lisäåä IPC:ta tai ei.
5% on nykyaikana ihan älyttömän SUURI ipc-parannus jos sen saa yhdellä muutoksella.
Miksi koko excavator ylipäätään kehitettiin? miksei vaan jatkettu steamrollerilla?
Excavatoria ei alun perin suunniteltu marginaaliprosessoriksi, se ajautui sellaiseksi koska ei pystynyt kilpailemaan intelin prossuja vastaan, ja vaikka tehdään kuinka marginaaliprosessoria, ei sen tuotekehityksessä voi lepsuilla.
Suorituskyvyn lisäksi L1-välimuistin kasvattaminen parantaa myös prosessorin energiatehokkuutta, kun hakuja kauempana olevaan L2-välimuistiin tulee vähemmän. Tosin bulldozer-johdannaisten läpikirjoittava L1D-kakku tarkoittaa sitä, että hyöty tästä jää hiukan pienemmäksi, kun kirjoitukset kuitenkin heti tehdään sinne L2-kakkuun asti.
Ja niin, tämä oli tosiaankin myös hyvin oleellinen toimintaperiaate-ero excavatorin ja zenin L1D-kakkujen välillä. Excavatorin L1D on läpikirjoittava, zenin L1D takaisinkirjoittava. Tämä myös tarkoittaa välimuisteille melko erllaista rakennetta.
Että voisitko nyt lopettaa paskapuheesi siitä kuinka samanlaisia ne välimuistit on kun et ymmärrä niistä yhtään mitään?
AMD:lla ei yhdessäkään aikaisemmassa prosessorissa ole ollut 1. 32KB:n kokoista L1 data cachea 2. 8-way L1 data cachea.
.. paitsi Bobcatissä, Pumassa ja Jaguarissa
Niinkuin oikeasti. Olet pihalla kuin lumiukko ja jankutat vaikka mitä päätöntä.
Ts. AMD:lla on nollakokemus siitä miten tällainen ratkaisu voisi toimia käytännössä.
Mistähän kokemuksesta nyt oikein puhut? Nämä on numerollisia parametreja, ei algoritmeja. Niiden suunnittelu/valmistaminen menee siten että otetaan kahkdensa kappaletta 4 kiB cache waytä ja laitetaan ne rinnakkain. Eteen ehkä way prediction-logiikka, mutta se varmaan on ollut jo ennestään että sen 4-way -välimuistin on saanut toimimaan pienellä virrankulutuksella, ihan sama way prediction-logiikka toinii kahdeksallekin kuin neljälle waylle.
Ja sen osumatarkkuuden kannalta taas tämän simuloimiseen kykenevän välimuistisimulaattorin koodaa muutamassa päivässä. Tai siis kun se välimuistisimulaattori on jo olemassa niiden kaikkien aiempien prosessoreiden kehittämistä varten, siihen olemassaolevaan välimuistisimulaattoriin syöttää parissakymmenessä sekunnissa sen uuden välimuistin parametrit.
Ja niin, se kokemus tosiaankin juuri tällaisita parametreista oli jo ennestään niistä pikkukissoista.
Pikemminkin kysymys on, että miksei tätä tehty jo aiemmin? Varmaan, koska oletettiin kellotaajuuden kärsivän tästä enemmän, kuin mitä tästä saatiin IPC-hyötyjä. Excavatorissa tähdättiin enemmän energiatehokkuuteen kuin aiemmissa, joten tämä ehkä sen takia koettiin tässä vaiheessa järkeväksi muutokseksi.
Tai sitten tässä vaiheessa vihdoin tajuttiin, että arkkitehtuurissa on muualla pahempia kriittisiä polkuja, ja että tämä ei lopulta hidastakaan sitä kellotaajuutta.
Excavator on mitä mainioin beta-testi, koska homman mennessä puihin haitta on minimaalinen. Instruction cachen osalta vastaavaa beta-testiä ei voitu tehdä kunnolla Excavatorin rakenteen takia. Zeniin parannettiin Excavatorin ratkaisua kuten monia muitakin, luonnollisesti.
Suorituskyvyn kannalta Excavator oli uhrattavissa, tässä tapauksessa testi tosin onnistui.
Muuten vaan piireistä löytyy suuri määrä yhtäläisyyksiä. Excavatorin ehkä suurimmat muutokset ovat L1 data cache (pitkälti vastaava kuin Ryzenissä)
Tuotekehitysajan kannalta ei todellakaan. Tuotekehitysajan kannalta se L1D oli käytännössä triviaaleimmasta päästä olevia muutoksia. Sen sijaan siellä lisättiin tuki monille sellaisille käskyille, joita steamrollerissa ei ollut tuettu, ja näiden toteutus oli
Mutta ihan turha tästä L1Dstä on jankuttaa kun pitäisi olla jo tehty täysin selväksi, että se on zenissä oikeasti täysin erilainen kuin excavatorissa, vaikka ulkoiset kokoparametrir onkin samat.
Vähän sama, kun väittäisi 1.5l maitopurkkia ja 1.5 limsapurkkia samoiksi purkeiksi sen takia, että molempien tilavuus on 1.5 litraa ja molemmat säilöö nestettä.
ja branch prediction yksikkö (patenttien perusteella Ryzenissä on pitkälti vastaava vaikka sitä onkin muokattu).
Jotain lähdettä excavatorin haarautumisenennustusparannuksille? vai mutuiletko vaan jälleen?
Tästähän käytiin aiemmin keskustelua Sandy Bridgen osalta. Edeltäjäänsä nähden Sandy Bridge oli liukuhihnan pituudelta, välimuisteilta, laskentayksiköiden määrältä, monisäikeistykseltä ja niin edelleen käytännössä täysin vastaava. Silti se oli "täysin uusi arkkitehtuuri". Joten "täysin uusi arkkitehtuuri" ei edellytä mainittujen asioiden osalta mitään muutosta.
Sandy bridgessä ytimen oleellinen toimintaperiaate muuttui täysin.
Jälleen palataan siihen, että ignoraat sellaiset pointit, mitä et ymmärrä.
On ihan normaalia ettei AMD laita kaikista harvinaisemmista (tai yleisemmistäkin) erikoiskäskyistä nopeaa versiota heti alkuun. On kuitenkin melkoinen "sattuma" että AMD pitää samaa käskyä "tarpeettomana" vielä vuosia myöhemmin. AMD:lla oli myös "varaa" lisätä Zeniin uusia lisäkäskyjä.
BMI2 on uusi käskykantalaajennos, jota äärimmäisen harvat softat käyttää.
Eikä sinulla ole mitään tietoa siitä, kuinka nopa PEXT-käsky on excavatorilla.
Se vasta kummaa olisikin, jos joku uusi hyvin harvinaisen käyttötarkoitukseen tehty erikoiskäsky yleistyisi kahdessa vuodessa sillai että yhtäkkiä se olisi hirveä pullonkaula koko prosessorin nopeudelle.
Perusteletko esim. sen miten AMD:lla on varaa suunnitella Zen puhtaalta pöydältä, heti perään Zen2 ja vielä Excavatoriin tehdä huomattavia muutoksia arkkitehtuuriin vaikka resursseista on pulaa?
Excavatoriin ei tehty mitään "huomattavia muutoksia steamrollerista", ja ne muutokset, mitä tehtiin, tehtiin pääosin ENNEN Zenin kehitystä.
Muutokset välillä Piledriver->Steamroller olivat paljon merkittävämpiä ja vaativat paljon enemmän tuotekehitystyötä.
Ja zen2 taas on suoraa jatkokehitelmää zenistä. Kaikki sellaiset ideat, mitä ei ole aikaa toteuttaa ajoissa zeniin siirrettiin sinne.
Toisekseen, Zenin kehityksen aikana tuotekehitysporukkaa siirrettiin GPU-puolella CPU-puolelle, että zen saatiin aikaiseksi sillä aikataululla kuin se nyt saatiin aikaiseksi. Tämän huomaa hyvin AMDn GPUiden viimeaikaisessa kehityksessä-
Tämä lienee myös oleellinen syy siihen, miksi Lisa Su:lla ja Raja Kodurilla meni sukset ristiin, raja koko että hän ei saa tarpeeksi resursseja kehittää tehokkaita näyttiksiä joita hän olisi halunnut kehittää. ja Vega myöhästyi selvästi ja oli alitehoinen.
... paitsi että se sama tiimi siinä välissä suunnitteli ainakin myös ivy bridgen, eikä projektit muutenkaan toimi siten, että projekti julistetaan valmiiksi ja loppuu kuin seinään ja samalla hetkellä kaikki siirtyvät seuraavaan projektiin.
FX-sarja, rakennuskonesarja, sama asia.
Sitä suuremmalla syyllä: koska AMD panostaa täysillä Zeniin, miksi ihmeessä haaskataan resursseja Excavatoriin ellei siitä saada muuta hyötyä kuin Excavator nopeammaksi?
Ensinnäkin, excavatorin arkkitehtuurisuunnittelu oli käytännössä jo melkein valmis kun zen-projekti alkoi, joten arkkitehtuurisuunnittelun osalta excavator ei ollut paljoa zenistä pois.
Piirisuunnittelun osalta taas, siinä vaiheessa kun excavatorin piirisuunnittelua tehtiin, zenin arkkitehtuurista ei ollut paljoa vielä niin lukossa, että sen piirisuunnittelu olisi voinut kunnolla edetä.
Ja kolmannekseen.. jos vaikka tiedetään, että "vuoden päästä tarvitaan paljon piirisuunnittelijoita seuraavalle, hyvälle arkkitehtuurille", niin paras tapa varmistaa niiden piirisuunnittelijoiden osaaminen silloin vuoden päästä on laittaa ne tekemään jotain oikeaa siksi vuodeksi. Se, että piirisuunnittelijat olisivat pyöritelleen peukaloitaan odotellessaan, koska pääsevät zeniä kehittämään olisi tarkoittanut selvästi bugisempaa ja mahdollisesti myös kellotaajuudeltaan hitaampaa zeniä.
Ja se kaikkein tärkein: AMD tarvi myytäviä uusia (Steamrolleria/kaveria/Godavaria parempia) tuotteita myös välille 2015-2016.
Annat ymmärtää AMD:n panostaneen täysillä Zeniin ja samalla annat ymmärtää panostaneen "turhiin asioihin" kuten Excavatoriin
Excavator ei ollut turha. Se vaan ei pärjännyt intelin piirejä vastaan kovin hyvin, mihin oli syynä sekä
1) bulldozer-kuona (läpikirjoittava L1D, pitkät viiveet monilla käskyillä, liian hidas viive L2-kakussa, liian pieni määrä kokonaislukuliukuhihnoja, ...
2) huono valmistustekniikka
3) intelin liian kova suoriutuminen noihin aikoihin
4) sen matalan tason piirisuunnittelussa optimoitiin vähemmän kellotaajuutta, enemmän tiheyttä ja pienen kellotaajuuden sähkönkulutusta. Päätös tästä tehtiin todennäköisesti myöhemmin kuin aivan arkkitehtuurisuunnittelun alkuvaiheessa.
Mikäli ymmärtäisit lukemaasi, huomaisit vastapuolen välttävän vastaamista niihin kysymyksiin jotka ovat pääasiallisia pointtejani.
Pääasialliset pointtisi ovat pintapuolisia virheellisiä oletuksia excavatorin ja zenin mikroarkkitehtuureista.
Olen jo selittänyt hyvin selvästi nämä pointtisi vääriksi, mutta silti jaksat jankuttaa niiden pohjalta tekemiäsi virhepäätelmiä.
Arkkitehtuuriltaan Zen muistuttaa itse asiassa kissasarjan ytimiä paljon enemmän kuin Bulldozer-sarjaa. Kun ensimmäiset tiedot zenin arkkitehtuurista tuli, luulin sitä kissa-sarjan jatkokehitelmäksi, mutta sitten myöhemmin kun arkkitehtuurista tuli tarkempia tietoja, kävi ilmi, että se on oikeasti puhtaalta pöydältä tehty, eikä vain paljon lihotettu(tai lihastettu) kissa.
"Analyysisi" perustui mihin 
Jos nuo huhut IPC suorituskyvyn kasvusta Zen 2:ssa pitävät paikkaansa, pitää Intel asemansa ihan pelkällä kellotaajuus erolla. Tietysti siinä tilanteessa, että TSMC:n 7nm prosessi mahdollistaisi Zenille korkeammat kellotaajuudet voisi AMD saada Intelin kiinni lähes kaikessa. 
