Edelleenkin oletat että TLB-lookup tehdään yhdessä muistihaun kanssa - ei varmana tehdä, data voidaan lukea sieltä cachesta paljon vähäisemmän informaation perusteella ja tarkistaa osuman oikeellisuus vaikka käskyn retire-vaiheessa.
Tervetuloa, uudet sivukanavahyökkäykset, ja tervetuloa, hyvin paljon virtaa tuhlaava ja suorituskykyä hukkaava replay-mekanismi kaikille L1-misseille. Jooei.
Ja joo, siellä Zenissä kyllä on se replay-mekanismi store->load-forwardeille, mutta hyöty siitä store-load-forwardingista on oikeasti suuri, ja sen false positive-hudit (jotka johtaa sen replayn aktivoitumiseen) on oikeasti hyvin harvinaisia, ja sen toteutus ilman sitä olisi oikeasti selvästi hankalampaa, kun siellä pitää vertailla joka kellojakso vertailla parin latauksen osoitteita kaikkiin store-puskurissa oleviin storehin(zen1:llä 44 kpl))
Se, että joku on teoriassa mahdollista ei tee siitä järkevää, kun suorituskyky- turvallisuus- ja virrankulutushaitat olisi moninkertaiset hyötyihin nähden.
L1-osuman tarkastaminen vasta retiressä olisi TODELLA HIDASTA, kun se retire voi tapahtua kymmeniä kellojaksoja myöhemmin ja sen latauksen jällkeen voi olla spekulatiivisesti suoritettu kymmeniä muita ladatusta datasta riippuvaisia käskyjä. KAIKKI NÄMÄ pitäisi heittää mäkeen ja replyttää nekin.
Käskyjen uudelleenjärjestyksen oleellinen hyöty tulee siitä, että kun tulee välimusitihuti, sitten skeduloidana suoritukseen
niitä käskyjä jotka ei ole riippuvaisia siitä datasta, jonka lataus kestää.
Se, että sitä hutia ei huomattaisi ja käskyskedulerille olisi aivan samanarvoisia käskyt joiden inputit on roskaa aivan toisesta osoitteesta (eikä ehkä edes roskaa vaan ehkä jopa sivukanavahyökkääjän tarkoituksella valmistelemaa hyökkäyspayloadia) ja jotka pitää heittää mäkeen, ja käskyt, joiden inputit on oikeasti sitä dataa mitä sen kuuluukin olla pilaisi aika paljon koko siitä pointista miksi käskyjen uudelleenjärjestely on niin kova juttu.
Ja joo, P4ssa oli replay L1D-misseille. Siinä se oli sen takia, että sen käskyskeduleri oli liukuhihnoitettu ja sitä tietoa siitä datan tuottavan loadin välimuistin osumasta tai hudista
ei vaan ollut millään saatavilla siinä vaiheessa kun käskyskeduleri sitä tarvitsi. Siinä se tieto tuli (vain)
yhden kellojakson myöhässä mutta silti ne replayt mitä se aiheutti sekä huomattavaa virrankulutuksen lisääntymistä että suorituskyvyn hidastumista, ja on juuri niitä oleellisia syitä miksi P4 oli niin huono kuin se oli.
Yksi P4n oleellisista opeista oli: L1D-hutiin ei haluta replaytä. Ja P4ssa siihen replayhin oli parempi syy (se liukuhihnoitettu käskyskeduleri) kuin millään uudella prossulla olisi.
TLB-käännökset ja täyden osoiteavaruuden käyttäminen olisi puhdasta typeryyttä.
Puhdasta typeryyttä on amatöörinä haukkua typeriksi ammattilaisten ratkaisuja, jotka on ainoita järkeviä ratkaisuita, kun amatöörin oma ymmärrys perustuu ei riitä tilalle tarjoamiensa vaihtoehtoisten "ratkaisujen" ongelmien ymmärtämiseen.
Ei ole edes kahta vuotta siitä kuin kutsuit intelin insinöörejä käytännössä idiooteiksi kun niiden prossuilla onnistuu meltdown-sivukanavahyökkäys mutta nyt ehdotat itse ratkaisua joka aiheuttaa vaan
vielä pahempia sivukanava-aukkoja ja samalla kutsut typeräksi toimivaa ja nopeampaa (ja oikeasti joka paikassa käytössä olevaa) ratkaisua jossa näitä sivukanava-aukkoja ei ole.
Kumpikos meistä suunnitteleekaan työkseen prosessoriytimiä, ja kumpi meistä ei ole opetellut prosessoriarkkitehtuureista edes alkeita missään yliopistossa tms. mutta yrittää sen sijaan päteä lukemalla satunnaisista lähteistä hyvin spesifistä nippelitietoa jonka ymmärtää hyvin usein väärin?
AMD on dokumentoinut uTaginsa vielä hyvin, ei siinä pitäisi olla epäselvää. Ja load-store forward on dokumentoitu myös, forwardoinnissa käytetään vain alinta 12 osoitebittiä, loput tarkastetaan myöhemmässä vaiheessa.
Joo, siitä on dokumentoitu hyvin, että sitä käytetään
way predictioniin.
Tässä ei ole mitään epäselvää.
Sen sijaan olet ihan omasta päästäsi kuvitellut että se korvaisi koko tagin, mitä se ei tee.
Ja pidät sitä vielä "aivan varmana" tajuamatta yhtään mitä kaikkia ongelmia se aiheuttaisi.
Vanhemmat Applen ytimet on dokumentoitu, eli ensimmäiset 64-bittiset versiot oli 16-19 pituisilla liukuhinoilla.
Lähteitä näihin dokumentteihin?
Tuolloin tosin ydin oli paljon pienempi, eli liukuhihnoitusta on melkoisen varmasti jouduttu lisäämään jotta esimerkiksi käskyjen fetchaus 4-kertaiseksi kasvaneesta puskurista tai rekisterien luku/kirjoitus 4-kertaa suurempaan ja tuplasti moniporttisempaan rekisterifileen kasvaisi muuten joko liian hitaaksi tai liian energiatehottomaksi - näillä data-arraylla on huomattavasti enemmän ongelmia skaalautua suuremmiksi kuin cacheilla jotka voidaan raudalla helposti pilkkoa pienempiin osiin.
Miten kuvittelet sen rekisterifileen tai käskypuskurin lukemisen liukuhihnoittavasi?
Ja väitän tietäväni aika paljon sinua paremmin, miten rekisterifileen koko ja porttimääärä vaikuttaa sen kokoon ja nopeuteen - olen oikeasti työkseni optimoinut näitä asioita ja miettinyt miten jostain rekisterifileestä saadaan portteja vähennettyä.
Ja joo, välimuistin voi pilkkoa pienempiin osiin, mutta se ei tuo sitä kaukana olevaa dataa yhtään lähemmäksi, ja tarvitaan silti muxit väliin valitsemaan, mistä palasta sitä dataa haetaan.
Mutta rekisterifileestäkin voi tehdä monipankkisen, tosin sitten pitää olla keino hanskata pankkikonfliktit, ja tämäkin menee helposti hyvin monimutkaiseksi.
Muistelen nähneeni joku vuosi sitten silloisesta Applen ytimestä(12?) analyysin jossa saatiin liukuhinan pituudeksi määriteltyä 25-30.
Jospa nyt vaan laittaisit sitä linkkiä niihin lähteisiin tämän mutun sijaan.
Minäkin muistan joskus jostain lukeneeni, että muistiosoitteet osoittaa yksittäisiin bitteihin eikä tavuihin, taisin kuulla sen joltain internetin luotettavimmalta lähteeltä jonka nimikirjaimet oli "SR".
