Näin tapahtuu, mutta osuma tulee L2:sta L2:m mukaisella viiveellä, 12 kellojaksoa vs 3 yms, ei vaikuta suorituskykyyn millään tapaa merkittävästi.
Ilmeisesti et nyt ymmärtänyt alkuunkaan tilannetta.
Se, että L2n viive on 12 kellojaksoa ei ole normaalisti "kovin paha" kun sieltä L2sta osuman tullen
kerran ladataan koko välimuistilinja jota sitten käytetään todella monta kertaa.
Mutta jos siellä molempien molemmat virtuaaliytimet kilpailisivat siitä, kumpi saa pitää sitä välimuistilinja "itsellään", silloin sieltä ei voitaisi lukea niitä montaa lukua peräkkäin ilman misisä vaan se L1D missailisi JATKUVASTI kun välissä toinen kävisi nappaamassa sen itselleen ja sieltä tulisi moninkertainen määrä niitä huteja. Ja kun se 12 kellojakson viive tulee MONELLE accessille eikä joskus todella harvoin, sen vaikutus suorituskyvylle olisi todella paha.
Tätä kutsutaan ping-pong-efektiksi. Normaalisti sitä tapahtuu esim. pieleen optimoidulla softalla false sharingin tapauksessa, ja joskus muinaisuudessa sitä tapahtui usein esim. kolmen taulukon väillä välimuistin ollessa vain 2-tie-joukkoassosiatiivinen, ja kaikkien taulukoiden ollessa alignoitu vähintään välimuisti-wayn koon verran.
Se, että ihan normaalit luvut jo KAHDEN lukijan välillä jostain yhteisestä read-only-muuttujasta voisi aiheuttaa ping-pong-efektin olisi ihan älytön suunnitteluvirhe. AMDn insinöörit osaavat hommansa, ja sen huomaa myös Zenin testituloksista. Tällaisia ping-pong-efektejä ei ole datan lukemisessa Zenillä nähty.
Bonuksena poistuu sivukanava-vaara säikeiden välillä.
Jos ne säikeet on samasta prosessista, ei ne tarvi mitään suojaa sivukanavahyökkäyksiltä toisiaan vastaan, kun sen datan saa lukea ihan suoraankin.
Ja kun siellä välimuistissa on 4096kB wayt, sillä, käytetäänkö virtuaali- vai fyysisiä osoitteita ei ole mitään vaikutusta siihen, missä kohtaa välimuistia joku osoite voi olla.
Että ei poista mitään sivukanava-vaaraa säikeiden väliltä, kun oikeudet tarkastetaan ajoissa.
Asianhan näkee testeitä oikein hyvin, Intelin prosessorien threadien välinen viive SMT-ytimessä on huomattavasti pienempi kuin AMD:llä, ero on juuri kuten L1 vs L2 osumat.
Testeistä näkee oikein hyvin, että puhut taas ihan puhdasta paskaa. Kun testit nimenomaan näyttää, että mitään tällaista "huomattavaa" eroa ei Intelin ja AMDn välillä ole:
Kommunikaatioviiveissä saman ytimen eri säikeiden välillä Intelin ja AMDn välillä on n. 1-2 kellojakson ero. Ei >= 8 kellojakson eroa.
Ja meillä on myös Power9 esimerkkinä, joka käyttää myös way-predicted L1-cachea ja dokumentoidusti käyttää predikoitua dataa ennen varmistusta.
Missä tämä "dokumentoidusti käyttää predikoitua dataa ennen varmistusta" on dokumentoitu?
ja predikoitu on tuossa hyvin hämärä sana. Antaa hyvän mahdollisuuen siirrellä maalitolppia kun voi tarvittaessa vaihtaa sanan merkitystä
Itse löysin tällaisen dokumentin Power9in liittyen, kertoo jotain sen L1D-kakusta:
ibm.ent.box.com
Oleellinen sivu on 42
POWER9 manual sanoi:
EA-based set predict is used to determine the initial hit information. RA-based directory and ERAT is used to define real hit information. A flush can occur on a set-predict hit, directory miss. – A dedicated 64-byte reload interface from the L2 cache can supply 64 bytes in every processor clock. – Effective address index, real address tags (hardware fix-up on alias cases). That is, two different EAs that map to the same RA are not allowed to co-exist in the D-cache.
Eli siis, tosiassa se dokumentoidusti
1) sisältää virtuaaliosoitteesene pohjaavan way predictionin
2) sisältää fyysiseen osoitteeseen perustuvat TAGit. Eli siis VIPT, kuten kaikki järkeväet L1D-välimuistit.
Ainakaan tuo dokumentti nimenomaan EI sano mitään siitä, että
käyttäisi dataa ennen sen osoitteen varmistusta.
Ko. prosessori on 4-way SMT ja alkujaan L1D oli yhdistetty mutta Spectre/Meltdown-korjauksena tuli 2-bittinen thread ID jakamaan L1-datan per threadi.
Onko lähdetät tälle väitteelle?
Tuo löytämäni dokumentti ei kerro mitään tuollaisesta. Sen sijaan se kertoo, että siellä on thread-id TLBlle, ei L1D-välimuistille.
Intel myös tykkäisi kovasti L1-datan threadijakomahdollisuudesta mutta sen puuttuessa ratkaisuna on joissain tapauksissa disabloida koko SMT.
Mitä ihmettä nyt oikein horiset?
Ei tarvitse flushata L1:stä, vain utagit.
Datasta, johon ei pääse käsiksi ei ole mitään iloa. Zenissä L1D-välimuistissa olevaan dataan ei pääse käsiksi ilman matchäävää microtagia.
utagin flushaus implikoi itse välimuistin flushauksen Zenillä (paitsi ehkä silloin, kun aliasoitumistapauksissa vaihdetaan utag osoittamaan toiseen virtuaalisoiteeseen joka osoittaa samaan fyysiseen osoitteeseen, mutta tässäkin tapauksessa tähän menee ihan sama aika kuin täydellä L1-hudilla/L2-latauksella, tässä ei säästetä kuin virtaa)
Ja aivan kuten AMD:n dokumentaatio sanoo, L1-accessoidaan vain ja ainoastaan virtuaalisen utagin avulla joten context-switchissä L1 missaa ensimmäiset lataukset
AMDn dokumentaatio ei sano mitään tällaista. AMDn dokumentatio ainostaan sanoo, että way prediction tehdään sen avulla.
Tässä vielä koko kappale microtagiin liittyen AMDn optimointimanualaistai, siellä ei moisäsän sano mitään tuollaista, mitä väität:
AMD Optimizaiton manual sanoi:
The L1 data cache tags contain a linear-address-based microtag (utag) that tags each cacheline with the linear address that was used to access the cacheline initially. Loads use this utag to determine which way of the cache to read using their linear address, which is available before the load's physical address has been determined via the TLB. The utag is a hash of the load's linear address. This linear address based lookup enables a very accurate prediction of in which way the cacheline is located prior to a read of the cache data. This allows a load to read just a single cache way, instead of all 8. This saves power and reduces bank conflicts. It is possible for the utag to be wrong in both directions: it can predict hit when the access will miss, and it can predict miss when the access could have hit. In either case, a fill request to the L2 cache is initiated and the utag is updated when L2 responds to the fill request. Linear aliasing occurs when two different linear addresses are mapped to the same physical address. This can cause performance penalties for loads and stores to the aliased cachelines. A load to an address that is valid in the L1 DC but under a different linear alias will see an L1 DC miss, which requires an L2 cache request to be made. The latency will generally be no larger than that of an L2 cache hit. However, if multiple aliased loads or stores are in-flight simultaneously, they each may experience L1 DC misses as they update the utag with a particular linear address and remove another linear address from being able to access the cacheline. It is also possible for two different linear addresses that are NOT aliased to the same physical address to conflict in the utag, if they have the same linear hash. At a given L1 DC index (11:6), only one cacheline with a given linear hash is accessible at any time; any cachelines with matching linear hashes are marked invalid in the utag and are not accessible.
Että hienosti kyllä jatkuvasti väität omia väärintulkintojasi suurempien auktoriteettien sanomisiksi.
mutta osumien tullessa L2:sta ero on muutama kellojakso per access.
n. 8 kellojaksoa "muutama". Melko luova merkitys tuolle sanalla.
Mikä on suorituskykyvaikutus niin sen näkee esimerkiksi Intelin pätseistä joissa flushataan koko TLB context switchissä - on vaikutusta mutta ei merkittävää, puhutaan maksimissaan joistain prosenteista.
"puhutaan maksimissaan joistain prosenteista".
Se, että saadaan "joitain prosentteja" lisää suorituskykyä high-end-prosessoreihin maksaa ihan älyttömästi tuotekehitystä hyvin osaavilta ihmisiltä,
Sellaisia arkkitehtuurillisia ratkaisuja, jotka hukkaa "joitain prosentteja" ei todellakaan tehdä hepposiin perustein.
L1-TLB on prosessorin MMU:n cache. Eli haku ko. cachesta tapahtuu aivan kuten L1:stä itsestään, AMD:n L1-DTLB on 64 entry fully associative. Eli jos hakutulos tarvitaan mahdolisimman nopeasti täydellä osumutarkkuudella luetaan kaikki 64 48 bittistä TLB-tag bittiä ja vertaillaan niitä siihen 48:aan virtuaalibittiin jotta löydetään oikea TLB-entry.
Se virtuaalimuisti toimii minimissään 4 kilotavun sivuilla. Ne 12 alinta bittiä voidaan ignorate täysin sitä osoitemuunnosta tehdessä, eikä niitä koskaan tallenneta TLBhen, siellä TLBssä on varsinaisia tagibittejä 36 eikä 48. Tämän lisäksi sitten n. 3 tilabittiä, kokonaisbittimäärä n. 39.
Sen jälkeen kun oikea osuma on löydetty luetaan. ko TLB-cachesta nuo 30 bittiä joilla voidaan sitten tehdä vertailu cachelinjan fyysiseen tagiin.....
tässä joudutaan helposti lukemaan monikertainen määrä dataa cachesta verrattuna tilanteeseen jossa luetaan 8:n 8 bitin utagia ja 64 bittiä varsinaista haettavaa dataa. Säästöpotentiaali on valtava.
On aivan eri asia lukea jotain jostain ~tuhannen sana SRAM-arraystä ja reitittää se ziljoonan leveän muxin jonnekin kauas kuin lukea yksittäistä latchiä tarvitsematta reitittää sitä minnekään.
Tämä on taas näitä asioita jotka on aivan triviaaleja ihmiselle, joka on koskaan tehnyt tai opiskellut mitään digitaalisuunnitteluun liittyvää.
Sen TLBn TAGin lukeminen sinne vertailujalle on
todella halpaa ja energiatehokastakoska kullakin vertailijalla on tasan yksi paikka mistä se data voi tulla, siihen ei tarvita väliin
minkäänlaista muxia ja fyysisesti jokainen vertailuja voidaan sijoittaa aivan sen datan sisältävän latchin viereen, jolloin sen datan ei tarvi kulkeakaan montaasataa nanometriä.
Siellä on vastaavia latch-vertailijapareja ties kuinka monta kertaa enemmän esim. käskyskedulerissa, aktivoitumassa joka ikinen kellojakso, tosin niissä vertailijat on vähän kapeampia (~8 bittiä).
Stack overflowssa Payl A Clayton on kanssa sivunnut vähän aihetta
We know that the direct-mapped caches are better than set-associative cache in terms of the cache hit time as there is no search involved for a particular tag. On the other hand, set-associative ca...
stackoverflow.com
Tekniikkahan ei ole uusi, näemmä Pentium4 on hyödyntänyt 5 bittisiä utageja jotta on saatu hyöty irti 16 nopeasti lasketusta bitistä osoitteenmuodostuksessa
Niin, sitä on käytetty
way predictioniin. Ei mihinkään muuhun, eikä nytkään käytetä mihinkään muuhun.
- Zenissä yllättäen vastaavasti käytetään 8 bittisiä uTageja hashättynä toisella 8 bitillä mukaan, sattumoisin on juuri puolet tuetusta 56bitin virtuaalimuistiavaruudesta
Zen tukee 48-bittisiä virtuaaliosoitteita, ei 56-bittisiä.
Cove-sarja tukee 57-bittisiä. (Ja siihen, miksi se on 57 eikä 56 bittiä, on oikein hyvä tekninen syy, jonka ymmärtää, jos yhtään tuntee sitä miten (x86n) sivutaulut oikeasti matalalla tasolla toimii, eli siis se, että kunkin taulun koko on sivun kokoinen, ja kun kaikki on alignoitu kahden potenssien välein, tarkoittaa se sitä, että yksi taulukon tietue on PAE-/x86-64-moodissa 8 tavua (3 osoitebittiä) jolloin niitä mahtuu 4 kiB sivuun se 512 kpl (9 osoitebittiä). Yhden tason lisäämällä saatiin siis 9 osoitebittiä lisää.
Ja alkuperäinen 48 bittiä ei siis tule 6 * 8 tai 3*16 bitistä vaan siitä että se on 12 + 9 +9 +9 +9 bittiä, maksimi minkä saa nelitasoisella sivutaululla 4 kiB sivuilla)
joten melko varmaan myös AMD on optimoinut AGUT laskemaan ensin alemman puoliskon osoitteesta ja tekemään L1-muistihaun sen perusteella aivan kuten P4:ssä aikanaan.
Kiitos tästä, tässä oli jälleen erinomainen esimerkki siitä, miten teet vahvoja päätelmiä asioista täysin virheellisten "faktojen" perusteella.
Tämän päätelmäsi pohjatiedot on nimittäin parilla tapaa pielessä:
1) Kuten jo yllä mainitsin, se virtuaalimuistiavaruus Zenillä 48 bittiä, ja puolet 48 bitistä on 24 joka ei oikein toimikaan teoriasi kanssa.
2) Vaikka virtuaalimuistiavaruus on vain 48 bittiä. ne Zenin AGUt pystyy ihan 64-bittisiin laskutoimituksiin (koska niissä suoritetaan myös LEA-käskyjä ilman muistiaccessia). Puolet 64 bitistä taas onkin 32, joka on monta bittiä enemmän eikä olekaan sama kuin AMDn microtagin laskentaa käytetty bittimäärä.
3) Optimoidun yhteenlaskijan sekventiaalisen logiikkatasojen määrä skaalautuu logaritmisesti bittimäärään nähden, ei lineraarisesti, tosin sinne tulee jotain useampi-inputtisia portteja minkä takia kriittinen polku ei putoa ihan suoraan logaritmisesti, vaan hiukan vähemmän. Käytännössä se, että sen leveys putoaa 48-64 bitistä 24-32 bittiin tarkoittaa n. 20% säästöä sen varsinaisen laskennan kriittisessä polussa, ei sen puolittumista
Sen sijaan, JOS sinne laittaa kaksi täysin erillistä kapeaa adderiä peräkkäin kuten P4ssa, kokonaisviive matalista biteistä korkeisiin kasvaa selvästi suuremmaksi.
4) Ja ne matalat bitit nyt sattuu ihan luonnollisesti valmistumaan sieltä normaalilta yhteenlaskimesta nopeammin koska niille on vähemmän logiikkaa, sen hyödyntämiseen ei tarvi kikkailla mitään laskevien kellonreunojen tai tuplanopeus-kellosignaalin kanssa, vaan ne voi saman kellojakson sisällä esim. reitittää kaummas tai laittaa niiden ja seuraavien rekistereiden väliiin enemmän muuta logiikkaa, ja synteesityökalu osaa ihan automaattisesti ottaa tämän kaiken huomioon reitityksessä ja laskea että nyt pystytään suurempiin kelloihin jos yhteenlaskun tuloksesta käytetään vaan alempia bittejä johonkin.
Sen sijaan, jos tuloksen kaikki bitit menee rekisteriin, niiden kaikkein bittien pitää ehtiä valmistua sen kellojakson aikana.
