Apple julkaisi M1-järjestelmäpiirin Mac-tietokoneisiin

[hkultala]

Koko L1-luku voi olla peräisin spekulatiiviselta käskyltä joka pitää nukettaa

Kyllä, niin VOI. Mutta n. 95% tapauksista se ei ole sitä. Se, että n. 5% prosentissa tapauksissa ongelmaa ei ole , ei poista ongelmaa niiltä 95%lta.

- mitään bränch predictoria ei ole kehitetty tarjoamaan lähellekään sitä osumatarkkuutta jonka järkevän, ei kokonaisen osoiteavaruuden tarjoaminen L1-datalle mahdollistaa.

Nyt menee kyllä taas logiikka ihan käänteiseksi.

Se, että TAGit täysin turhaan jätettäisiin tai tarkastettaisiin myöhässä pois ei mahdollista yhtään mitään.
Se ainoastaan hidastaisi ja monimutkaistaisi L1-hutia aivan turhaan

Miksi muistihaun osumatarkkuus pitäisi olla jotain muuta kuin muun koodinsuorituksen?

Kaiken osumatarkuuden pitää olla niin hyviä kuin helposti mahdollisia ja kaikkien viiveiden pitää olla niin lyhyitä kuin helposti mahdollisia ilman että muualla joudutaan mistään pahasti tinkimään.

Ei vaan ole mitään järkevää keinoa tehdä haarautumisennustushudista nopeampaa.

Sen sijaan L1D-hudin tarkastaminen on mahdollista hyvin aikaisin, jolloin L1D-hudin viive on pieni, sen tekeminen turhaan myöhään olisi täysin turhaa sen hidastamista.

Kun L1-datasta luetaan osittaisilla osoitteilla vain sitä dataa jonka ko-threadi on jo itse sinne hakenut ei kovin kummoista lisäinformaatiota saada sivukanavahyökkäyksillä kaivettua.

Jälleen hieno esimerkki siitä kuinka amatööri on totaalisen pihalla kuin ei tiedä perusasioita.

Käyttöjärjestelmässä jonka designissa on yhtään kiinnotetty huomiota suorituskykyyn(eikä menty mikrokernel-uskonnon perässä), samat säikeet pyörivät sekä käyttäjän prosesseissa että kernelinkoodissa, softa tekee kutsun kernelin rutiiniin ja sama säie vaihtaa kernelin puolelle ja sitten palaa sieltä.

Eli se säie on kernelin puolella voinut juuri käsitellä vaikka mitä sellaista dataa johon käyttäjän prosessilla ei ole lukuoikeuksia. Sitten vaan accessoidaan sallittua osoitetta jolla on sama hash-arvo kuin välimuistissa olevalla kernelin privaattidatalla.

Intelin prossuissa oli idiottimaisia ratkaisuja ja suoranaisia bugeja pilvin pimein.

Vähemmän ja vaikeammin hyödynnettäviä kuin sinun kuvittelemissasi ratkaisuissa. Mutta paljon helpompi huudella sivusta ja haukkua niitä jotka tekee kuin yrittää tehdä itse.

L1-datan pitäminen threadikohtaisena ja sen lukeminen osittaisella lineaarisella osoitteella ei ole yhtään sen vaarallisempaa kuin tuon store-forwardinkaan tapauksessa.

Vaikka Zenillä tehdään store-load-forwarding verraten latauksesta ja tallennuksesta vain alimpia 12 bittiä, sille latauksen osoitteelle kyllä tehdään ihan täydellinen osoitteenmuunnos ja jos yritään ladata laittomasta osoitteesta, lentää HETI page faultti ennenkuin data pääsee milekään seuraavalle käskylle.

Se "vain" 12 bittiä on siellä sitä varten että
1) ei tarvi verrata kaikkia n. 44*48 bittiä
2) se vertailu voidaan alottaa aiemmin kun se voidaan tehdä rinnakkain sen TLB-haun kanssa sen sijaan että se tehtäisiin sen jälkeen.

Mutta hieno esimerkki kehäpäätelmästä, käytät omaa harhakuvitelmaasi perusteluna sen harhakuvitelmasi järkevyydelle että "muualla täytyy olla sama ongelma" vaikkei tosiasiassa ole.

Että ei, Zenin 12-bittisissä STLF-vertailujoissa ei ole mitään merkittävää helposti hyödynnettävää sivukanava tietoturva-aukkoa mutta sinun "ideassasi" on L1D-kakun kokoinen massiivinen ja helposti hyödynnettävä sivukanava-aukko

Kova olet aina pätemään joo,

Minä olen se, joka oikeasti tiedän nämä asiat, sinä ole itse, joka yrität päteä vaikket oikeasti ole yhtään pätevä siihen pätemiseen.

Osaat ulkoa paljon pikkuyksityiskohtia, muttet ymmärrä kokonaiskuvaa ja toimintaperiaatteita siitä, miten asiat oikeasti toimii, ja sitten tulkitset niiden ulkoa muistamiesi yksityiskohtien merkityksiä aivan väärin.

mutta tosiaan mietihän vielä vaikka kerran paljonko cacheista tarvii dataa lukea ja vertailla suhteessa varsinaiseen luettuun dataan L1-haun yhteydessä jos tagit on täydellä fyysisellä tagilla. Ja jos vielä käytät hetken aikaa niin ehkä keksit keinoja kuinka tuota overheadia voidaan pienentää.

Mitään muuta keinoa siihen osuman varmistamiseen 100% varmuudella ei ole kuin sen täyden tagin lukeminen. Se, että 99% muistiaccesseista menee oiekaan paikkaan mutta 1% meneekin väärän paikkaan ei paljoa lohduta.

Kaikkien musitiaccessien nyt vaan täytyy mennä oikeisiin osoitteisiin, tälle ei vaan voi mitään. Ja joskus se tarkastus kuitenkin pitää tehdä. Ja sen myöhästämiseen ei vaan ole mitään järkevää syytä, siinä ei säästetä yhtään mitään.

Jos fyysinen muistiavaruus on luokkaa 44 bittiä ja wayn koko on 12 bittiä niin TAGia tarvii lukea 32 bittiä. Tämä nyt vaan täytyy lukea eikä siitä pääse millään yli eikä ympäri. Se on sitä overheadia joka tulee siitä, että ylipäätään käytetään välimuistia.

No mitkä olisivat ne ongelmat?

Selitetty yllä. Access sopivaan toiseen osoitteeseen (jota ei ole L1d-kakussa) sisältää saman hashin kuin eri osoite (jonka data löytyy L1D-kakusta). Alempana vielä esimerkki

Joka cachelinjalla on kuitenkin fyysiset tagit ja ne tarkistetaan dataa siirrettäessä L1:een joten mitään ongelmia pelkän virtualisen tagin käytöstä ei tule

Tagit tarkastetaan silloin kun tehdään muistihakua, sen takia, että niistä selviää, että onko halutun osoitteen dataa välimuistissa

Väännetään nyt vielä rautalangasta esimerkki, oletetaan vaikka että hashi muodostetaan käytettämällä siihen vain osoitteen bittejä 31:12, tässä esimerkissä ei ole edes väliä sillä, käytetäänkö fyysisiä vai virtuaalisia osoitteita.

1) Suoritetaan lataus osoitteesta
0x0000 0000 0000 1000 (luku paloiteltu 16-bittisiin osiin luettavuuden parantamiseksi)

Tämän osoitteen sisältämä data ladataan välimuistiin.
Tällöin muodostetaan hash biteistä 00001. Saadaan sille joku arvo, kutsutaan tätä vain nimellä X.

2) Suositetaan lataus osoittesta
0x0000 0001 0000 1000

Tällä osoitteella on tismalleen samat bitit välillä 31:12, eli se saa tismalleen saman hashin (x)
Zenin way prediction mikrotagin perusteella ennustaa osumaa siihen wayhin missä tuo aiemmin ladattu eri osoitteen data on.

Jos välimuistin osumantarkastus tehtäisiin pelkän microtagin perusteella, tämä jälkimmäionen lataus saisi tuon datan , eli lataus lataisi väärän arvon

(Mutta sitten siellä tehdään myös se oikean täyden TAGin tarkastus, joka kertoo, että yläbiteissä on eroa, ei ollutkaan osuma, eikä ladata mitään väärää dataa.)

. Ja se datan luenta tehdään predictionina eli se ei ole 100% varma tulos luettaessa ja käytettäessä, vain 99.999% tai sinnepäin. Loputkin osoitteesta tarkistetaan mutta sitä ei tarvitse tehdä turhaa energiaa polttaen ennen datan saamista käyttöön.

99.999% on täysin väärää kertaluokkaa oleva heitto. Todellinen on lähempänä luokkaa 99%.

Ja sen tarkastuksen viivästäminen ei säästäisi käytännössä yhtään mitään. Ihan saman määrä bittejä sieltä TAGeista pitää lukea vaikka sen luvun tekisi myöhemin.
Päin vastoin, se, että aletaan raahaaman niitä liukuhihnalla perässä seuraaville vaiheille ja träckäämään myöhempiä käskyjä joiden arvo riippuu siitä datasta että mitkä kaikki pitäisi perua ja uudelleenkäynnistää. se sitä energiaa haaskaisi ziljoona kertaa enemmmän.

Nykyprossuissa taitaa olla useamman kellojakson pituinen fetch-stage käskypuskurin ajovaiheessa. Ja rekisterifile - lukukäsky liukuhihnan vaiheessa x ja data tulee x+y kellojaksolle.

Hienoa korkean tason käsienheiluttelua, kun ei oikeasti ymmärretä niitä yksityiskohtia asioista, mistä pädetään.

Ei mikään voi kestää montaa kellojaksoa ellei siellä ole välissä rekistereitä.

Mihin väliin olisit ne rekisterit näissä tunkevasi?

Se, että se välimuisti voidaan jakaa pienempiin lohkoihin nimenomaan MAHDOLLISTAA sen, että sen käyttö voidaan liukuhihnoittaa useammalle kuin kahdelle kellojaksolle, kun varsinainen access jokaiseen lohkoon tehdään kahden kellojakson aikana (ekalla osoite sisään, toisella data ulos) ja muut vaiheet sitten reitittää dataa ja osoitetta oikealle lohkolle.

Mutta prosessorin voi kyllä backportata vanhemmalle prosessille ilman ongelmia vaikka siinä cachen lisäksi kaikki muukin siirtyy kauemmaksi...... eikö nämä ongelmat kuitenkin liity aika pitkälti toisiinsa?

Sotket nyt keskenään aivan eri tavalla skaalautuvia asioita, sekä sitä, mikä on ongelma ja mikä on muuttuja joka vaikuttaa suorituskykyyn.

Niin muistuuko mieleen Heikki jonka suunnittelemissa prosessoreissa lienee hyvin suuria koherenssiongelmia muistinkäsittelyn suhteen

Eipä tule mieleen ketään sellaista.

Yksikään suunnittelemani prosessoriydin ei ole edes yrittänyt olla välimuistikoherentti. Koska niissä käyttötarkoituksissa mihin ne on suunniteltu se olisi ollut täysin turhaa, ja vaan monimutkaistani designia ja lisäisi virrankulutusta.

Ja oikein hienoa yrittää päteä sillä, että vaikka itseltäsi on aivan alkeetkin hukassa niin sitten olet kerran onnistunut muistamaan jonkun välimuistikoherenttiusprotokollan pikkuyksityiskohdan minua paremmin niin pidät tätä suurena saavutuksena ja todisteena pätevyydestäsi.



Ja ne lähteet niihin väittämiisi Applen liukuhihnanpituuksiin/haarautumishutiviiveisiin uupuu yhä.

 

[SheikYerbouti]

Jos haluat kosketusnäytön, niin osta iPad Pro 12” + magic keyboard.

Siitä on tulossa lähes varmasti versio tuolla M1 piirillä kunhan ehtivät julkistaa.

Olettaisin, että M on kirjaimensa mukaisesti Maceille tarkoitettu prosessori. iPadit jatkossakin A-sarjan prossuilla.

 

[Juha Kokkonen]

Säätäkääs sitten sitten keskustelutyyliä muutama naksu vähemmän väheksyvään, piikittelevään ja hyökkäävään muotoon.

Sinänsä keskusteluun syvyyden tasosta propsit

 

[zepi]

Olettaisin, että M on kirjaimensa mukaisesti Maceille tarkoitettu prosessori. iPadit jatkossakin A-sarjan prossuilla.

Minun on ainakin vaikea keksiä, että miksi iPad pro:lle tehtäisiin erikseen erillinen prosessori.

A12x/z oli 4x perf-core + 4x efficient core ratkaisu, eli aivan kuten M1. Siinä oli myös sama 128bit-muistiväylä, kasa neural engineä ja mitälie. Nyt M1:seen tuli lähinnä Thunderbolt / USB4-tukea, mutta tuskin se haittaa kun iPad Pro:lle halutaan kuitenkin näyttöulostulot ja vaikka mitä dock-tukeakin taitaa jo olla.

Voi olla, että M1 re-brändätään A14X:seksi, mutta eiköhän se sama ydin tule olemaan.

 

[Euphemos]

Toki suurimmat ongelmat tässä uudistuksessa eivät liity rautaratkaisuihin... tietokoneen ja sen tuottaman käyttäjädatan omistusoikeudet kun siirtyvät yhä kiivaammin käyttäjän omien käsien ulottumattomiin.

Those shiny new Apple Silicon macs that Apple just announced, three times faster and 50% more battery life? They won’t run any OS before Big Sur.

These machines are the first general purpose computers ever where you have to make an exclusive choice: you can have a fast and efficient machine, or you can have a private one. (Apple mobile devices have already been this way for several years.)

 

[pomk]

Toki suurimmat ongelmat tässä uudistuksessa eivät liity rautaratkaisuihin... tietokoneen ja sen tuottaman käyttäjädatan omistusoikeudet kun siirtyvät yhä kiivaammin käyttäjän omien käsien ulottumattomiin.

Ikään kuin google olisi yhtään sen parempi jos puhelimista on kyse. Näiden uusien läppäreiden kohdalla on vielä selvittämättä että millaista diagnostiikkaa käyttäjät pakotetaan jakamaan.

 

[escalibur]

Toki suurimmat ongelmat tässä uudistuksessa eivät liity rautaratkaisuihin... tietokoneen ja sen tuottaman käyttäjädatan omistusoikeudet kun siirtyvät yhä kiivaammin käyttäjän omien käsien ulottumattomiin.

Jos ihan rehellisiä ollaan, ainut tapa saada yksityisyyttä on pysyä poissa internetistä jota ei alunperinkään ole suunniteltu olemaan yksityinen paikka oikeastaan yhtään millekään asialle.

 

[Euphemos]

Jos ihan rehellisiä ollaan, ainut tapa saada yksityisyyttä on pysyä poissa internetistä jota ei alunperinkään ole suunniteltu olemaan yksityinen paikka oikeastaan yhtään millekään asialle.

Kelpo karikatyyrin väkersit. Vastaväitteenä voisikin esittää, että jos kerran kaikki data on jo julkista vapaata riistaa, niin mihin näitä uusia tehokeinoja enää tarvittaisiin? Rahanhaaskausta vain rahanhaaskauksen vuoksi?

 

[escalibur]

Kelpo karikatyyrin väkersit. Vastaväitteenä voisikin esittää, että jos kerran kaikki data on jo julkista vapaata riistaa, niin mihin näitä uusia tehokeinoja enää tarvittaisiin? Rahanhaaskausta vain rahanhaaskauksen vuoksi?

Kukaan ei ole väittänyt että ne ovat vapaata riistaa. Pointtini oli että mikäli internetissä ollaan, on melko todennäköistä että pysyminen anonyymisenä on lähes mahdotonta. Olkoot kyseessä Applen, Googlen, Microsoftin, tai kenen tahansa muun vakoilu ja "vakoilu", käytännössä koko internetin käytöstä (mukaan lukien älypuhelimet) tulee miltei mahdotonta. Zero Trustin yleistymisen odotellessa.

Jääkööt offtopic osaltani kuitenkin tähän. Voidaan jatkaa ajatusten vaihtoa jossain toisessa ketjussa.

 

[sayravai]

Aina voi käyttää jotain OpenBSD:tä, jos tietoturva huolettaa. Ja ainakin kotiverkossa voi aika hyvin palomuurein ja lokaalilla nimipalvelulla kontrolloida minne koneet lähettelee dataa, vaikka lokaalia palomuuria ei saisikaan enää Big Sur:iin asennettua.

 

[Mäkkimies]

Suht pirteä aloitus Applelta M1:en kera. Aika lupaavaa nopeutta tulossa koneisiin. Nyt oli hyvä hetki myydä Mac Pro pois, kun siitä sai vielä rahaa. Yksi miinus näyttää olevan, että. Tulevat AMD RX 6800 XT ei saa tukea vanhoihin tai nyt julkaistuihin koneisiin.

 

[Sami Riitaoja]

Kyllä, niin VOI. Mutta n. 95% tapauksista se ei ole sitä. Se, että n. 5% prosentissa tapauksissa ongelmaa ei ole , ei poista ongelmaa niiltä 95%lta.

Sun päättelyketjut on hyvin outoja, 5% latauksista jokatapauksessa nuketetaan, jos osoitetarkkuuden tiputtamisella 1/3:aan näiden poistettavien käskyjen määrä lisääntyy 0.01% näistä tulee ongelma? Avaapas vähän päättelyketjuasi.

Nyt menee kyllä taas logiikka ihan käänteiseksi.

Se, että TAGit täysin turhaan jätettäisiin tai tarkastettaisiin myöhässä pois ei mahdollista yhtään mitään.
Se ainoastaan hidastaisi ja monimutkaistaisi L1-hutia aivan turhaan

Osumatarkkuus haetaan sellaiseksi että osoitetarkkuuden laskeminen ko. tagin tarkuuden takia ei vaikuta nopeuteen millään tavalla merkittävästi. Normaalin L1-hudin tapauksessa TLB-muunnos pitää sitten aloittaa ainakin kellojaksoa myöhemmin, mutta sekään ei välttämättä ole hitaampaa koska vähäisempien TLB-munnosten takia energibudjettia ko. hommaan on monikymmenkertaisesti vielä edes huomioimatta että TLB voitaneen samalla muuttaa kääntämään vain yhden osoitteen per kellojakso sen sijaan että se joutuisi kääntämään L1-porttien mukaisen määrän dataa per kellojakso.

Kaiken osumatarkuuden pitää olla niin hyviä kuin helposti mahdollisia ja kaikkien viiveiden pitää olla niin lyhyitä kuin helposti mahdollisia ilman että muualla joudutaan mistään pahasti tinkimään.

Tähänhän perustuu fyysisten tagien käyttö L1-luvussakin, se löytää ne synonyymitkin. AMD on selkeästi dokumentoinut että L1-synonyymit tunnistaa L2 ei L1 joten L1-hakuun ei tule parempaa osumatarkkuutta vaikka osuman fyysiset tagit tarkistettaisiinkin joskus - aivan turhan työn tekeminen prosessorin krittisellä linjalla on aivan älytöntä.

Sen sijaan L1D-hudin tarkastaminen on mahdollista hyvin aikaisin, jolloin L1D-hudin viive on pieni, sen tekeminen turhaan myöhään olisi täysin turhaa sen hidastamista.

Sulta menee se pointti täysin ohi, L1-cache on 32kilotavua, siihen lähestulkoon täydellisen osumatarkkuuden saaminen ei vaadi 64 bittistä osoiteavaruutta. Jo silloin aikanaan laskeskelin järkevää osoiteavaruutta L1-osoitukseen ja päädyin aavistuksen suurempaan L1-tagin pituuteen kuin AMD käyttää, mutta AMD käyttää yksinkertaista hashia eli tagit bitit xorrataan vastaavan määrän ylempien bittien kanssa jotta aliasoivat osoitteet eivät ole minkään vakiokaavan mukaisia ja käytännössä L1-cachen osoiteavaruus menee suoraan sinne järkevän alueen yläpäähän.

Jälleen hieno esimerkki siitä kuinka amatööri on totaalisen pihalla kuin ei tiedä perusasioita.

Käyttöjärjestelmässä jonka designissa on yhtään kiinnotetty huomiota suorituskykyyn(eikä menty mikrokernel-uskonnon perässä), samat säikeet pyörivät sekä käyttäjän prosesseissa että kernelinkoodissa, softa tekee kutsun kernelin rutiiniin ja sama säie vaihtaa kernelin puolelle ja sitten palaa sieltä.

Eli se säie on kernelin puolella voinut juuri käsitellä vaikka mitä sellaista dataa johon käyttäjän prosessilla ei ole lukuoikeuksia. Sitten vaan accessoidaan sallittua osoitetta jolla on sama hash-arvo kuin välimuistissa olevalla kernelin privaattidatalla.

No et ole tosissasi Meillä on siellä datassa se bitti joka kertoo ko. datan lukuoikeuden prosessorin käyttölevelille, se että Intelin prosessori siitä huolimatta lukee tämän datan ei ole tämän tekniikan heikkous. Katsohan nyt peiliin ennenkuin yrität päteä.

Kaikkien musitiaccessien nyt vaan täytyy mennä oikeisiin osoitteisiin, tälle ei vaan voi mitään. Ja joskus se tarkastus kuitenkin pitää tehdä. Ja sen myöhästämiseen ei vaan ole mitään järkevää syytä, siinä ei säästetä yhtään mitään.

Et taas ole tosissasi. Kaikki mikä voidaan tehdä hitaasti säästää energiaa verrrattuna nopeaan suoritukseen, tämä oli Intelin insinöörien pääpointti Core-prossujen esittlyssä, prosessorissa on keskitytty tekemään kaikki niin hitaasti kuin mahdollista sen vaikuttamatta suorituskykyyn.

Jos fyysinen muistiavaruus on luokkaa 44 bittiä ja wayn koko on 12 bittiä niin TAGia tarvii lukea 32 bittiä. Tämä nyt vaan täytyy lukea eikä siitä pääse millään yli eikä ympäri. Se on sitä overheadia joka tulee siitä, että ylipäätään käytetään välimuistia.

Olen selittänyt tätä enennin, overheadi on PALJON suurempi. Jos L1-TLB on 8-way ensin luetaan ja vertaillaan niitä 8:aa lineaarisen osoitteen dataa, sen jälkeen luetaan se 32 bittinen fyysinen data ja vertaillaan sitä L1-cachen tagiin. Ja tasan tiedetään että L1-cachen accessiin ei tarvita fyysistä käännöstä, se voidaan hoitaa virtuaalisellakin osoitteella mutta fyysiset tagit tarvitaan joka linjaan koherenssiprotokollalle, ja samalla fyysisillä tageilla hoituu synonyymi ja homonyymiongelmat. Linjan tuplataggausta ei haluta käyttää kun se lisää kriittisen polun overheadia cachessa, mutta erikoistapaus jossa L1 on subset L2:sta ongelma hoituu aivan itsestään, jokainen cachelinjat on tagattu L2:ssa joka hoitaa koherenssit ja synonyymit eikä homonyymejä voi syntyä.

Tagit tarkastetaan silloin kun tehdään muistihakua, sen takia, että niistä selviää, että onko halutun osoitteen dataa välimuistissa

Väännetään nyt vielä rautalangasta esimerkki, oletetaan vaikka että hashi muodostetaan käytettämällä siihen vain osoitteen bittejä 31:12, tässä esimerkissä ei ole edes väliä sillä, käytetäänkö fyysisiä vai virtuaalisia osoitteita.

1) Suoritetaan lataus osoitteesta
0x0000 0000 0000 1000 (luku paloiteltu 16-bittisiin osiin luettavuuden parantamiseksi)

Tämän osoitteen sisältämä data ladataan välimuistiin.
Tällöin muodostetaan hash biteistä 00001. Saadaan sille joku arvo, kutsutaan tätä vain nimellä X.

2) Suositetaan lataus osoittesta
0x0000 0001 0000 1000

Tällä osoitteella on tismalleen samat bitit välillä 31:12, eli se saa tismalleen saman hashin (x)
Zenin way prediction mikrotagin perusteella ennustaa osumaa siihen wayhin missä tuo aiemmin ladattu eri osoitteen data on.

Jos välimuistin osumantarkastus tehtäisiin pelkän microtagin perusteella, tämä jälkimmäionen lataus saisi tuon datan , eli lataus lataisi väärän arvon

(Mutta sitten siellä tehdään myös se oikean täyden TAGin tarkastus, joka kertoo, että yläbiteissä on eroa, ei ollutkaan osuma, eikä ladata mitään väärää dataa.)

Tämä on aivan oikein, ladataan jo cachessa oleva data sen sijaan että haettaisiin oikea data muistista. Virhe huomataan jossain vaiheessa myöhemmin aivan kuten väärin menneen haarautumisennustuksen kanssakin ja korjataan, ei mitään ongelmaa kunhan ko. tapauksia ei tule niin paljon että se alkaisi hidastaa suorituskykyä.

Ja sen tarkastuksen viivästäminen ei säästäisi käytännössä yhtään mitään. Ihan saman määrä bittejä sieltä TAGeista pitää lukea vaikka sen luvun tekisi myöhemin.
Päin vastoin, se, että aletaan raahaaman niitä liukuhihnalla perässä seuraaville vaiheille ja träckäämään myöhempiä käskyjä joiden arvo riippuu siitä datasta että mitkä kaikki pitäisi perua ja uudelleenkäynnistää. se sitä energiaa haaskaisi ziljoona kertaa enemmmän.

Koko sivukanavahyökkäysten aalto tulee siitä että tarkastuksia ei tehdä ajoissa vaan viivestetysti. Kaikki mikä voidaan kannattaa tehdä hitaasti eikä nopeasti, tämä on ihan perusasioita piirin optimoinnissa ja on mm. Intelin esitelmässä kun he julkaisivat core-arkkitehtuurin.

Hienoa korkean tason käsienheiluttelua, kun ei oikeasti ymmärretä niitä yksityiskohtia asioista, mistä pädetään.

Ei mikään voi kestää montaa kellojaksoa ellei siellä ole välissä rekistereitä.

Mihin väliin olisit ne rekisterit näissä tunkevasi?

Jankaat vain jankaamisen ilosta jonkun aivan turhan pointin perässä. Esimerkissä oli kyse että kun tehdään haku rekisterifileen tulos tulee myöhemmin eli esimerkiksi haku rekisterifileestä voi olla jaettu useampaan vaiheeseen, siellä on kuitenkin ~400 osoitetta valittavana. Datan tulo rekisterifileestä voi tulla suoraan tai sitten siinä tosiaan voi olla välirekisteri datan siirtoon jos siirrettävä matka on niin pitkä että se ei ehdi tai energiatehokkuuden takia sitä ei haluta siirtää yhdessä kellojaksossa.

Eipä tule mieleen ketään sellaista.

Yksikään suunnittelemani prosessoriydin ei ole edes yrittänyt olla välimuistikoherentti. Koska niissä käyttötarkoituksissa mihin ne on suunniteltu se olisi ollut täysin turhaa, ja vaan monimutkaistani designia ja lisäisi virrankulutusta.

Ja oikein hienoa yrittää päteä sillä, että vaikka itseltäsi on aivan alkeetkin hukassa niin sitten olet kerran onnistunut muistamaan jonkun välimuistikoherenttiusprotokollan pikkuyksityiskohdan minua paremmin niin pidät tätä suurena saavutuksena ja todisteena pätevyydestäsi.

Datakoherenssi on aika yksinkertainen asia, datasta ei ole kuin yksi versio missään. Mesi-protokolla on erittäin yksinkertainen ja esittää kuinka ko. saadaan toteutettua useampien cachejen kanssa. Näistä perusasioista voi sitten johtaa muuta perusasiaa kuten sen että saman datan käsittely useammassa eri prosessoriytimissä yhtäaikaa on helvetin hidasta. Ja tämähän ei ole kuin raudan näkökulma, saman datan käsittely yhtä aikaa useammalla eri ytimellä on ohjelmoinnin kannalta katastrofi jonka takia samaa dataa ei käsitellä yhtäaikaa vaan yhteinen data lukitaan tavalla tai toisella sitä käyttävälle ytimelle. Näistäkin sun on pitänyt vääntää ja vaikka ja mitä vastaan vaikka perusasia on hukassa.

Ja mitä tuohon kommentoimaasi virheeseen tulee niin meni joo bitit ja tavut sekaisin ja sen myötä laskut pieleen mutta sekö on pointtisi tämän threadin argumentteja vastaan? Osoita mulle selkeesti missä menee pieleen niin en minä siitä väitä vastaan mutta väitän insinööriä joka haluaa käyttää 32 kilotavun datan osoittamiseen 64 bitin osoiteavaruutta ihan vitun typeräksi.

Ja ne lähteet niihin väittämiisi Applen liukuhihnanpituuksiin/haarautumishutiviiveisiin uupuu yhä.

Applen vanhemmat prosessorit on julkisesti dokumentoitu, googlaa. Niissä liukuhihnan pituus on aivan sama kuin Intelin/AMD:n prossuissa ja L1-latenssi sama 3, uusimpien prossuversioiden tiedot on vain spekulaatioita mutta ainakaan minun silmiin ei ole näkynyt kenenkään spekuloivan liukuhihnan lyhennyksistä prosessorin monimutkaisuuden lisääntyessä valtavasti, näitä päinvastaisia on jokunen näkynyt. Mutta siis liukuhihna Applen prosessoreisssa ei ole dokumentoidusti ollut millään merkittävällä tavalla lyhyempi kuin Intelin/AMD:n tuotoksissa kuten väitit aikaisemmin, mikä lienee ollut vain omaa vailla pohjaa olevaa spekulaatiotasi.

 

[Sami Riitaoja]

Sotket nyt keskenään aivan eri tavalla skaalautuvia asioita, sekä sitä, mikä on ongelma ja mikä on muuttuja joka vaikuttaa suorituskykyyn.

Backporttausesta siis. Sinä väität sinisin silmin että siinä ei ole mitään ongelmaa - minä väitän että on. Se prosessorille hirveällä vaivalla ja laskentakapasiteetillä laskettu layoutti menee aivan vituiksi jos sitä yritetään kasvattaa reilusti aiottua suuremmaksi. Ei vaan siis voi onnistua. Nythän vastaväitteenä tulee tietenkin että Intel teki kuitenkin, no siltä se ehkä yksinkertaisesta näkökulmasta näyttää mutta olen melko varma että siellä on täysin uusiksi laskettu ytimen layoutti, eli Intel on suunnitellut 14nm:lle uuden prosessoriytimen. Tähänhän vähän viittaisi nimikin eli eri ytimelle annetaan eri nimi.

Mistä päästään asiaan Skylake. Taisit vaihteeksi hakata sitä päätäsi seinään kun kerroin että Skylake ja Skylake-x omaavat saman coren, tietohan oli peräisin suoraan Intelin esitelmästä. Sinulta se meni yli hilseen. Skylake-extended omaa peruscoressa joitain pieniä muutoksia ja tilaa vaativat palikat on vain liitetty kylkeen - tämä osoittaa kuinka helvetin vaikea ja kallis se prosessoriytimen layoutti oikein on, ei sitä huvin vuoksi suunnitella moneen kertaan.

 

[Primusol]

Onkos näistä vielä tullut mitään kolmannen osapuolen puolueettomia testejä? Kiinnostaa kovasti pitkäaikainen rasitus, pitääkö kellot ja mitkä on lämmöt.

 

[smicke]

Ei

 

[Baldrick]

Onkos näistä vielä tullut mitään kolmannen osapuolen puolueettomia testejä? Kiinnostaa kovasti pitkäaikainen rasitus, pitääkö kellot ja mitkä on lämmöt.

Ei ole. Ja luotto siihen maagiseen Rosetta 2:eenkin on sitä luokkaa, että Cinebenchistä puskettiin ulos uusi versio natiivituella.

 

[hkultala]

Datakoherenssi on aika yksinkertainen asia, datasta ei ole kuin yksi versio missään.

Perusasiat väärin jälleen kerran melko pielessä, asioissa joissa amatööri yrittää jälleen päteä ja neuvoa ammattilaista.

Samasta datasta voi aivan hyvin olla erilaisia kopioita eri paikoissa, kunhan ne täyttävät muistin konsistenssiusehdot. (jotka on sitten käskykanta-arkkitehtuurikohtaisia).

Datan eikä edes välimuistin invalidointisignaalin ei tarvitse ehtiä salamannopeasti joka paikkaan.

Se, että datasta voisi koskaan olla vain yksi versio missään tarkoittaisi sitä, että kaikkialta pitäisi olla kytkennät kaikkialle yhden kellojaksoin sisällä, että tätä ei voi tapahtua, ja oltaisiin jossain 100 MHz kellotaajuusluokassa jollain monen piilastun EPYCillä.

Esim. kahden eri ytimen store-puskurissa voi aivan hyvin olla kirjoitus samaan osoitteeseen.

Samoin ytimillä 1 ja 2 voi olla välimuistissaan sama data siten että ydin 1 kirjoittaa sinne uuden arvon kellojaksolla N ja ydin 2 lukee vanhan arvonsa kellojaksolla N+1, tai N + 10.

Tämä on täysin sallittua, kunhan näiden muistioperaatioiden välissä ei ole tapahtunut muita muistioperaatiota siten että muistin konsistenttiussäännöt rikkoontuvat.

mutta väitän insinööriä joka haluaa käyttää 32 kilotavun datan osoittamiseen 64 bitin osoiteavaruutta ihan vitun typeräksi.

Mistä ihmeen 64 bitin osoiteavaruudesta nyt oikein höpiset?

Ei siellä ole mitään 64-bittistä osoiteavaruutta. Fyysiset osoitteet on nykyisillä x86-64-mikroarkkitehtuureilla n. luokkaa 44 bittiä ja osumatarkkuus nyt pitää tehdä täydellä bittileveydellä kaikista mahdollisista osotteista, mitä sinne välimuistiin voidaan säilöä, mitään muuta vaihtoehtoa vaan ei ole.

Todella typerää on todellisuudessa se, että kuvittelet että välimuistin TAG-tarkastuksesta voitaisiin jotenkin "säästää bittejä", etkä näe tässä mitään ongelmaa, vaikka kuinka yrittää asiaa vääntää rautalangasta.

Mutta joo, ei tunnu menemään kaaliin. Kun on lusikalla annettu, ei voi kauhalla vaatia.

Jospa nyt aloittaisit siitä, että opettelisit edes ohjelmoinnin alkeet. Sen jälkeen voisit jatkaa siitä, että luet Patterson-Hennessyn computer architecture-kirjan.

Applen vanhemmat prosessorit on julkisesti dokumentoitu, googlaa.

Mitkään Applen omasuunnittelemat CPU-ytimet ei ole "julkisesti dokumentoitu", Apple ei ole koskaan julkaissut mitään tarkkoja speksejä itsesuunnittelemistaan prossuista.

Sen sijaan esim. Anandtech on tehtyt testejä niiden haarautumisennustushudeista , ne löytyy googlella ja niistä käy ilmi että haarautumisenennustusviive on A6lla 12 kellojaksoa joka on n puolet siitä mitä alunperin väitit.

The iPhone 5 Review

www.anandtech.com

Niissä liukuhihnan pituus on aivan sama kuin Intelin/AMD:n prossuissa

Ei ole.

esim. Zenin liukuhina on 19-vaiheinen. Vaikka pari viimeistä vaihetta olisi pelkille liukuluvuille, tekee se silti selvästi enemmän

ja L1-latenssi sama 3

"sama" ????

Sekä AMD että Intel molemmat kasvattivat L1D-minimiviiveensä kolmesta neljään n. kymmenen vuotta sitten (Bulldozer, Nehalem) ja Cove-sarjassa Intel on mennyt jo viiteen.

Kolme ei todellakaan ole sama kuin neljä tai viisi. Tämä pitäisi olla jo ala-asteen ekan luokan matematiikkaa.

, uusimpien prossuversioiden tiedot on vain spekulaatioita mutta ainakaan minun silmiin ei ole näkynyt kenenkään spekuloivan liukuhihnan lyhennyksistä prosessorin monimutkaisuuden lisääntyessä valtavasti, näitä päinvastaisia on jokunen näkynyt. Mutta siis liukuhihna Applen prosessoreisssa ei ole dokumentoidusti ollut millään merkittävällä tavalla lyhyempi kuin Intelin/AMD:n tuotoksissa kuten väitit aikaisemmin, mikä lienee ollut vain omaa vailla pohjaa olevaa spekulaatiotasi.

Ei ole mitään dokumentatiota joka näin sanoo. Melkoista Trumpismia väittää tällaista.

Mistä päästään asiaan Skylake. Taisit vaihteeksi hakata sitä päätäsi seinään kun kerroin että Skylake ja Skylake-x omaavat saman coren, tietohan oli peräisin suoraan Intelin esitelmästä. Sinulta se meni yli hilseen. Skylake-extended omaa peruscoressa joitain pieniä muutoksia ja tilaa vaativat palikat on vain liitetty kylkeen - tämä osoittaa kuinka helvetin vaikea ja kallis se prosessoriytimen layoutti oikein on, ei sitä huvin vuoksi suunnitella moneen kertaan.

"kerroit". Jospa käytettäisiin kuitenkin oikeaa termiä eli "satuilit". Mutta melkoista pään seinän hakkaamista seinään kyllä on minkään selittämisen yrittäminen sinulle kun uit niin syvällä Dunning-Kruegerissasi että mikään ei uppoa kun perusasiat on niin hukassa.

Luet asioita jatkuvasti jostain ymmärtämättä mitä ne tarkoittaa, kuvittelet niiden tarkoittavan jotakin ja vaikka kuinka sinulle yrittäää selittää miten olet ymmärtänyt ne väärin, ei uppoa. Koska itsetuntosi tms. ei vaan anna periksi sille, että voisit myöntää että et ymmärtänyt lukemaasi oikein.

Ja sitten jatkuvasti väität että alkuperäinen lähde sanoi jotain mikä on pelkkää omaa tulkintaasi eikä yhtään sitä mitä se alkuperäinen lähde todellisuudessa sanoi.


Ei sinne fyysiseen piirin voi vaan "liimata" jotain kylkeen kun kaikki dataväylät ja kytkennät pitää olla olemassa.

Se, mitä voidaan tehdä on, että otetaan se olemassaolevan designin RTL-koodi ja lisätään siihen lisää toiminnallisuutta. ja sitten olemassaolevien osien paikoista voi suurimman osan jättää layoutissa ennalleen mutta kyseessä ei tällöin ole sama ydin vaan selvästi muokattu/laajennettu ydin.

Uusia käskyjä ei voi vaan lisätä lisäämällä niille suoritusyksiköt, vaan ne pitää lisätä käskydekooderiin, ja kaikki niiden vaatimat kontrollisignaalit ja kytkennät rekisterifileisiin pitää toteuttaa jne.

Piirillä olemassaolevia osia pitää muokata huomattavasti.


Se, että väittää sitä "täysin samaksi ytimeksi" on todella typerää.

Toinen meistä oikeasti suunnittelee prossuytimiä työkseen, toinen ei. Kannattaisi ehkä vähän miettiä, kummalla on parempi tietämys siitä, miten niitä suunnitellaan.

 

[user9999]

Onkos näistä vielä tullut mitään kolmannen osapuolen puolueettomia testejä? Kiinnostaa kovasti pitkäaikainen rasitus, pitääkö kellot ja mitkä on lämmöt.

Ei löydy kuin nuo Geekbench testit

Mac Benchmarks - Geekbench

OpenCL testissä Apple M1 saanut 19579

Macmini9,1 - Geekbench

Benchmark results for a Macmini9,1 with an Apple Silicon processor.

browser.geekbench.com

Metal testissä Apple M1 saanut 22123

Mac mini (Late 2020) - Geekbench

Benchmark results for a Mac mini (Late 2020) with an Apple M1 processor.

browser.geekbench.com

 

[Sami Riitaoja]

Perusasiat väärin jälleen kerran melko pielessä, asioissa joissa amatööri yrittää jälleen päteä ja neuvoa ammattilaista.

Samasta datasta voi aivan hyvin olla erilaisia kopioita eri paikoissa, kunhan ne täyttävät muistin konsistenssiusehdot. (jotka on sitten käskykanta-arkkitehtuurikohtaisia).

Datan eikä edes välimuistin invalidointisignaalin ei tarvitse ehtiä salamannopeasti joka paikkaan.

Se, että datasta voisi koskaan olla vain yksi versio missään tarkoittaisi sitä, että kaikkialta pitäisi olla kytkennät kaikkialle yhden kellojaksoin sisällä, että tätä ei voi tapahtua, ja oltaisiin jossain 100 MHz kellotaajuusluokassa jollain monen piilastun EPYCillä.

Esim. kahden eri ytimen store-puskurissa voi aivan hyvin olla kirjoitus samaan osoitteeseen.

Samoin ytimillä 1 ja 2 voi olla välimuistissaan sama data siten että ydin 1 kirjoittaa sinne uuden arvon kellojaksolla N ja ydin 2 lukee vanhan arvonsa kellojaksolla N+1, tai N + 10.

Tämä on täysin sallittua, kunhan näiden muistioperaatioiden välissä ei ole tapahtunut muita muistioperaatiota siten että muistin konsistenttiussäännöt rikkoontuvat.

Eli jaksat vääntää MESI-protokollaa edelleenkin joksikin muuksi kuin mitä se on. Se pitää vain cachet synkroonissa, eikä siinä tarvitse minkään tapahtua yhden kellojakson viiveillä tai ylipäätään millään määritetyillä viiveillä. Ongelma on ratkaistu niin että ennenkuin prosessori voi kirjoittaa cacheen tämä cache pala on eksklusiivisessä statessa ts. kaikki muut datan kopiot muissa cacheissa on invalidoitu ENNEN tätä kirjoitusta, jonka jälkeen MESI-protokolla voi myöntää cachelinjalle eksklusiivisen staten. Store puskurissa voi olla mitä vain, se odottaa siellä kunnes cachen state on eksklusiivinen ja se voidaan kirjoittaa cacheen. MESI-protokolla ei mitenkään yritä ratkaista monisäikeisen ohjelmoinnin ongelmia johon tarvitaan lukitussäännöt datalle, sen ainoa tehtävä on pitää cachen sisältö joka kellojaksolla yhtenäisenä.

 

[Sami Riitaoja]

Mistä ihmeen 64 bitin osoiteavaruudesta nyt oikein höpiset?

Ei siellä ole mitään 64-bittistä osoiteavaruutta. Fyysiset osoitteet on nykyisillä x86-64-mikroarkkitehtuureilla n. luokkaa 44 bittiä ja osumatarkkuus nyt pitää tehdä täydellä bittileveydellä kaikista mahdollisista osotteista, mitä sinne välimuistiin voidaan säilöä, mitään muuta vaihtoehtoa vaan ei ole.

Todella typerää on todellisuudessa se, että kuvittelet että välimuistin TAG-tarkastuksesta voitaisiin jotenkin "säästää bittejä", etkä näe tässä mitään ongelmaa, vaikka kuinka yrittää asiaa vääntää rautalangasta.

Mutta joo, ei tunnu menemään kaaliin. Kun on lusikalla annettu, ei voi kauhalla vaatia.

Jospa nyt aloittaisit siitä, että opettelisit edes ohjelmoinnin alkeet. Sen jälkeen voisit jatkaa siitä, että luet Patterson-Hennessyn computer architecture-kirjan.

Osoiteavaruuden määrä ei ole nyt tästä pointti, älä aina yritä vängätä huomiota pois oleellisista asioista.


Se L1-data pitää saada sieltä cachesta mahdollisimman nopeasti ja energiatehokkaasti ulos. Ei siinä kannata tarkistaa koko osoiteavaruutta mahdollisimman nopeasti polttaen vähintään turhaan energiaa, pahimmassa tapauksessa rajoittaen myös mahdollista maksimikellotaajuutta. Esim AMD:n dokumentoiduissa toiminnassa data voidaan hyvin lukea L1:stä mikrotagin perusteella ja täysi tagi voidaan liukuhihnoittaa vaikka L2:n puolelta käskyn retire-puolelle - prossun kriittiseltä nopeutta rajoittavalta polulta on näin saatu pois suurinpiirtein puolet cacheluvun datasta.

 

[Sami Riitaoja]

Mitkään Applen omasuunnittelemat CPU-ytimet ei ole "julkisesti dokumentoitu", Apple ei ole koskaan julkaissut mitään tarkkoja speksejä itsesuunnittelemistaan prossuista.

Sen sijaan esim. Anandtech on tehtyt testejä niiden haarautumisennustushudeista , ne löytyy googlella ja niistä käy ilmi että haarautumisenennustusviive on A6lla 12 kellojaksoa joka on n puolet siitä mitä alunperin väitit.

A6 on 32-bittinen arkkitehtuuri. A7 on ensimmäinen 64-bittinen ja TÄYSIN eri arkkitehtuuri. Tuosta Cyclonesta on tietoja, mm ROB 192, integer-pipeline 16 ja FP 19 kellojaksoa. Löytynee vaikka wikichipistä ja monesta muusta paikasta.

Ei ole.

esim. Zenin liukuhina on 19-vaiheinen. Vaikka pari viimeistä vaihetta olisi pelkille liukuluvuille, tekee se silti selvästi enemmän

No niin on Applen A7 Cyclonen fp-liukuhihnakin. Taitaa sekä integer että fp-liukuhihnat olla tasaman samanpituiset. Sama suunnittelijikan ollut mukana kummankin tekemisessä.

Kuriositeettinä nyt voisi vielä mainita että Zen3:n load-store puoli on liki täysin sama kuin Applen prosssuissa, eli optimoitu 128-bittisille accessseille, pystyy kolmeen lukuun tai kahteen 128 bittiseen kirjoitukseen per kellojakso, 256-bittisillä yhteen vähempään kummassakin.

 

[Sami Riitaoja]

"sama" ????

Sekä AMD että Intel molemmat kasvattivat L1D-minimiviiveensä kolmesta neljään n. kymmenen vuotta sitten (Bulldozer, Nehalem) ja Cove-sarjassa Intel on mennyt jo viiteen.

Kolme ei todellakaan ole sama kuin neljä tai viisi. Tämä pitäisi olla jo ala-asteen ekan luokan matematiikkaa.

Mihin oikein vastailet, lopeta se pääs hakkaaminen seinään ettei viimeinenkin järki katoa. Puhe oli tietenkin Apple A7 ja eteenpäin joiden liukuhihnojen pituus tiedetään ja L1-latenssi on 3 ja koko on 128 kilotavua. Sinähän väitit jotenkin että tuo L1 cachen koko ja latenssi osoittaa että liukuhihnan pituus ei ole yhtäpitkä kuin Intelillä/AMD:llä, kuitenkin löytyy prosessori joka osoittaa väitteesi aukottomasti vääräksi.

 

[Sami Riitaoja]

"kerroit". Jospa käytettäisiin kuitenkin oikeaa termiä eli "satuilit". Mutta melkoista pään seinän hakkaamista seinään kyllä on minkään selittämisen yrittäminen sinulle kun uit niin syvällä Dunning-Kruegerissasi että mikään ei uppoa kun perusasiat on niin hukassa.

Luet asioita jatkuvasti jostain ymmärtämättä mitä ne tarkoittaa, kuvittelet niiden tarkoittavan jotakin ja vaikka kuinka sinulle yrittäää selittää miten olet ymmärtänyt ne väärin, ei uppoa. Koska itsetuntosi tms. ei vaan anna periksi sille, että voisit myöntää että et ymmärtänyt lukemaasi oikein.

Ja sitten jatkuvasti väität että alkuperäinen lähde sanoi jotain mikä on pelkkää omaa tulkintaasi eikä yhtään sitä mitä se alkuperäinen lähde todellisuudessa sanoi.


Ei sinne fyysiseen piirin voi vaan "liimata" jotain kylkeen kun kaikki dataväylät ja kytkennät pitää olla olemassa.

Se, mitä voidaan tehdä on, että otetaan se olemassaolevan designin RTL-koodi ja lisätään siihen lisää toiminnallisuutta. ja sitten olemassaolevien osien paikoista voi suurimman osan jättää layoutissa ennalleen mutta kyseessä ei tällöin ole sama ydin vaan selvästi muokattu/laajennettu ydin.

Uusia käskyjä ei voi vaan lisätä lisäämällä niille suoritusyksiköt, vaan ne pitää lisätä käskydekooderiin, ja kaikki niiden vaatimat kontrollisignaalit ja kytkennät rekisterifileisiin pitää toteuttaa jne.

Piirillä olemassaolevia osia pitää muokata huomattavasti.


Se, että väittää sitä "täysin samaksi ytimeksi" on todella typerää.

Toinen meistä oikeasti suunnittelee prossuytimiä työkseen, toinen ei. Kannattaisi ehkä vähän miettiä, kummalla on parempi tietämys siitä, miten niitä suunnitellaan.

No kuten jo aikaisemmin kerroit, älä siirrä omaamiasi yksinkertaisia asioita monimutkaisempiin. Tottakai Skylake on suunniteltu heti alusta pitäen yhtenäisenä niin että siitä voidaan valmistaa kahta versiota. Peruslayoutti on työpöytäversiossa ja Extended servereissä, extended versio on selkestä hiukan outo design jossa ylimääräinen AVX512-unitti ja L2-cache on peruslayoutin neliön ulkopuolella. Intel on itse asian kertonut ihan avoimesti ja asia on varmistettu dieshoteilla mutta sinä tiedät kuitenkin asian paremmin, anteeksi vain jos en pidä sinua tässä asiassa luotettavimpana lähteenä.

Ja Intelin omat esitelmät ovat varmasti todella typeriä verrattuna kunnon prosessorisuunnittelijan absoluuttiseen totuuteen.

 

[Juha Uotila]

Ei ole. Ja luotto siihen maagiseen Rosetta 2:eenkin on sitä luokkaa, että Cinebenchistä puskettiin ulos uusi versio natiivituella.

Jep varmaan ollut juuri tuo syy, että halutaan tuoda natiivi sovellus tarjolle

 

[Zerppo]

Ei ole. Ja luotto siihen maagiseen Rosetta 2:eenkin on sitä luokkaa, että Cinebenchistä puskettiin ulos uusi versio natiivituella.

Mitä väliä Rosetta 2:n suorituskyvyllä edes on kun kaikesta tulee hyvin nopeasti natiiviversiot?

Eikö näillä nyt ole kuitenkin tarkoitus ajella pääsääntöisesti pelkkiä natiivisoftia hyvinkin pian?

 

[njake]

Aika lupaavia näyttöjä.

Alkaakohan nyt inteliäkin arm kiinnostamaan ja onko tuossa mahdollisuus, että x86 arkkitehtuuri alkaa hiipua pois?

 

[Zerppo]

Jep varmaan ollut juuri tuo syy, että halutaan tuoda natiivi sovellus tarjolle

Tietysti tuodaan natiiviversio, koska kaikesta muustakin tulee natiiviversio.

Ei kai M1:n todellista suorituskykyä kannata muulla kuin natiivibenchmarkeilla arvioidakaan. Toki hauska nähdä lukemat myös Rosettan läpi eri benchmarkeissa, vaikka sillä ei kauaa väliä olekaan.

(vai oliko kommenttisi sarkasmia )

 

[user9999]

Nyt tuolla on Rosetta 2 testi.

Apple Silicon M1 Emulating x86 is Still Faster Than Every Other Mac in Single Core Benchmark

The first native benchmarks of Apple's M1 chip appeared on the Geekbench site last week showing impressive native performance. Today, new...

www.macrumors.com

MacBookAir10,1 - Geekbench

Benchmark results for a MacBookAir10,1 with a VirtualApple processor.

browser.geekbench.com

 

[FlyingAntero]

Nyt tuolla on Rosetta 2 testi.

Apple Silicon M1 Emulating x86 is Still Faster Than Every Other Mac in Single Core Benchmark

The first native benchmarks of Apple's M1 chip appeared on the Geekbench site last week showing impressive native performance. Today, new...

www.macrumors.com

MacBookAir10,1 - Geekbench

Benchmark results for a MacBookAir10,1 with a VirtualApple processor.

browser.geekbench.com

Suorituskyvyn pudotus näyttää olevan yhden ytimen osalta (-23%) samalla tasolla kuin A12Z pohjaisen Developer Transition Kitin kanssa. Useamman ytimen testissä suorituskyky putoaa kuitenkin vain 21%, kun Developer Kitillä pudotus oli 39%. Ero johtuu ilmeisesti siitä, että M1 tunnistuu 8-ytimiseksi, kun A12Z vain 4-ytimiseksi. Molemmat on todellisuudessa 4+4 big.LITTLE prossuja. Lisäksi Rosetta2:n kautta ajettaessa kellotaajuus on Geekbenchin mukaan aina 2,4Ghz. Liekkö tuolla sitten jotain vaikutusta?

 

[zepi]

Suorituskyvyn pudotus näyttää olevan yhden ytimen osalta (-23%) samalla tasolla kuin A12Z pohjaisen Developer Transition Kitin kanssa. Useamman ytimen testissä suorituskyky putoaa kuitenkin vain 21%, kun Developer Kitillä pudotus oli 39%. Ero johtuu ilmeisesti siitä, että M1 tunnistuu 8-ytimiseksi, kun A12Z vain 4-ytimiseksi. Molemmat on todellisuudessa 4+4 big.LITTLE prossuja. Lisäksi Rosetta2:n kautta ajettaessa kellotaajuus on Geekbenchin mukaan aina 2,4Ghz. Liekkö tuolla sitten jotain vaikutusta?

Todennäköisesti prosessorin kellotaajuus ei ole rajoittunut 2.4GHz:taan rosettan kanssa, vaan ainoastaan x86-emuloinnin läpi se geekbenchin executable ei näe oikein niitä fyysisiä kellotaajuuksia.

 

[hkultala]

A6 on 32-bittinen arkkitehtuuri. A7 on ensimmäinen 64-bittinen ja TÄYSIN eri arkkitehtuuri. Tuosta Cyclonesta on tietoja, mm ROB 192, integer-pipeline 16 ja FP 19 kellojaksoa. Löytynee vaikka wikichipistä ja monesta muusta paikasta.

Ei löydy

A7 - Apple - WikiChip

Apple A7, also known as Apple H6, is codenamed Alcatraz.

en.wikichip.org

Ax - Apple - WikiChip

Ax is a family of high-performance 32-bit and 64-bit ARM system on chips designed by Apple exclusively for their consumer products.

en.wikichip.org

Tuolla ei puhuta mitään liukuhinnan pituudesta.

Mutta LLVMn lähdekoodeista(AArch64SchedCyclone.td) vihdoin löytyi, haarautumisennustushuti Cyclonessa on sen mukaan lyhimmillään 14 kellojaksoa.

Mutta sieltäkään ei löydy mitään tietoja mistään uudemmista malleista kuin Cyclonesta (A7).

Ja samassa koodissa sanotaan Cyclonen L1-viiveeksi 4 kellojaksoa, ei kolme, mikä tiedetään Applen nyky-ytimien L1-viiveeksi, ja samoin monen muunkin käskyjen viiveiden tiedetään lyhentyneen, esim, fadd on lyhentynyt 4->3 kellojaksoon ja kokonaislukujen kertolasku on lyhentynyt 4 -> 3 kellojaksoon. Tämä taas vihjaisi siihen, että liukuhihnaa on Cyclonen jälkeen lyhennetty.

Taitaa sekä integer että fp-liukuhihnat olla tasaman samanpituiset. Sama suunnittelijikan ollut mukana kummankin tekemisessä.

Suurimmassa osassa prosessoreita skalaaripuoli on lyhempi kuin liukuhihnapuoli, koska skaalaripuolella ei usein ole mitään muuta enempää kuin kolmea kellojaksoa kestäviä liukuhihnoitettuja käskyjä kuin lataukset (jakolasku ei usein ole liukuhihnoitettu), ja suurin osa kokonaislukupuolen käskyistä suoritetaan yhdessä kellojaksossa.

Liukuluvuilla taas FMA kestää tyypillisesti 4-5 kellojaksoa, mutta on täysin liukuhihnoitettu. Ja joillain prossuilla liukulukukäskyjen exec-vaihekin n yhtä kellojaksoa myöhemmin kuin kokonaisluku-/skalaaripuolella.

Ja nyt kun tutkin lisää tuota Cyclonen llvm-koodia niin sen mukaan liukulukupuoli olisi kellojakson verran pidempi kuin kokonaislukupuoli.

Kuriositeettinä nyt voisi vielä mainita että Zen3:n load-store puoli on liki täysin sama kuin Applen prosssuissa, eli optimoitu 128-bittisille accessseille, pystyy kolmeen lukuun tai kahteen 128 bittiseen kirjoitukseen per kellojakso, 256-bittisillä yhteen vähempään kummassakin.

Pelkkä uteliaisuus ei nyt riitä kun faktat on ihan muuta:

Ensinnäkin, Applen nykyprosessoreissa ei taida olla mitään 256-bittisiä muistioperaatiota. Siellä on tietääkseni vain 128-bittinen SIMD-datapolku.

Toisekseen, Zen3 ei tietääkseni pysty tekemään kolmea 128-bittistä lukua eikä kahta 128-bittistä talletusta vaan vain 3 64-bittistä lukua ja 2 64-bittistä talletusta.

Kolmannekseen, Zen3 ei pysty tekemään enempää kuin kolme muistioperaatiota kellojaksossa. Jos tehdään 3 latausta, ei tehdä yhtään tallennusta, ja jos tehdään kaksi tallennusta, tehdään vain yksi lataus. Applen uudet prossut tekee kaksi latausta + yksi tallennus + yksi JOMPI KUMPI, yhteensä 4 / kellojakso.

 

[SheikYerbouti]

Availin tuonne prossualueelle aiheesta keskustelun.

Applen CPU:t -keskustelu (M1, M1 Pro, M1 Max...)

Aiheesta keskustellaan jo useammassa ketjussa, joten keskitetäänkö tänne? Tänään pilpahti Rosetta 2 -tuloksia Geekbenchiin. Kovia lukuja, jos pitävät paikkaansa: https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-benchmark/

bbs.io-tech.fi

 

[Sami Riitaoja]

Mutta LLVMn lähdekoodeista vihdoin löytyi, haarautumisennustushuti Cyclonessa on sen mukaan lyhimmillään 14 kellojaksoa, tosin samassa koodissa sanotaan Cyclonen L1-viiveeksi 4 kellojaksoa, ei kolme. Mikä taas vihjaisi siihen, että liukuhihnaa on Cyclonen jälkeen lyhennetty.

L1-viive Applella on 4 kellojaksoa monimutkaisille osoitteille ja 3 yksinkertaisille. Sama yhden kellojakson ero useimmilla x86-prosessoreillakin.

 

[Sami Riitaoja]

Suurimmassa osassa prosessoreita skalaaripuoli on lyhempi kuin liukuhihnapuoli, koska skaalaripuolella ei usein ole mitään muuta enempää kuin kolmea kellojaksoa kestäviä liukuhihnoitettuja käskyjä kuin lataukset (jakolasku ei usein ole liukuhihnoitettu), ja suurin osa kokonaislukupuolen käskyistä suoritetaan yhdessä kellojaksossa.

Liukuluvuilla taas FMA kestää tyypillisesti 4-5 kellojaksoa, mutta on täysin liukuhihnoitettu.

Tarkoitin siis että sekä Zenissä että Applen A7:ssa kokonaiskuhihna 16 pitkä ja liukuluku 19. Ainakin ovat hyvin lähellä samoja mittoja.

 

[Sami Riitaoja]

Pelkkä uteliaisuus ei nyt riitä kun faktat on ihan muuta:

Ensinnäkin, Applen nykyprosessoreissa ei taida olla mitään 256-bittisiä muistioperaatiota. Siellä on tietääkseni vain 128-bittinen SIMD-datapolku.

Toisekseen, Zen3 ei tietääkseni pysty tekemään kolmea 128-bittistä lukua eikä kahta 128-bittistä talletusta vaan vain 3 64-bittistä lukua ja 2 64-bittistä talletusta.

Kolmannekseen, Zen3 ei pysty tekemään enempää kuin kolme muistioperaatiota kellojaksossa. Jos tehdään 3 latausta, ei tehdä yhtään tallennusta, ja jos tehdään kaksi tallennusta, tehdään vain yksi lataus. Applen uudet prossut tekee kaksi latausta + yksi tallennus + yksi JOMPI KUMPI, yhteensä 4 / kellojakso.

AMD:n omassa diassa oli mainittu poikkeukseksi vain 256-bittiset operaatiot, jossain tosin huomasin jonkun väittävän että koskee vain kokonaislukupuolta. Taivun AMD:n oman dian kannalle tässä vaiheessa.

Juu Applen prossu taitaakin pystyä jo neljään operaatioon,

 

[Sami Riitaoja]

Esim. kahden eri ytimen store-puskurissa voi aivan hyvin olla kirjoitus samaan osoitteeseen.

Juu lukitus on hankalaa. Eli jotta vältyttäisiin bugiselta koodilta pitää toimia vähän vaikeasti, eli esimerkiksi lukea lukituskoodi, todeta se vapaaksi, kirjoittaa sitten oman threadin lukituskoodi lukkoon ja sen jälkeen tarkistaa että siellä on nimenomaan oman threadin lukituskoodi eikä jonkun muun. Ja jos siis suoraan vain lukee ko. lukituksen koko suoritus pysyy prosessorin sisällä eikä cache-koherenssius auta asiaa. Eli prosessorin sisäiset puskurit pitää ensin flushata jne. No onneksi noita lukitusschemejä on ihan riittämiin valmiina että ei niitä itse juuri kenenkään tarvitse itse hallinnoida ja debugata.

Ja jos kaksi kirjoitusta samaan osoitteeseen koskee jotain muuta kuin lukitusta niin voisi melkein sanoa että ongelma ei ole raudassa..... kilpailuasetelma, bugi jossa ko. osoitteen lopullinen arvo on tuurista kiinni.

Samoin ytimillä 1 ja 2 voi olla välimuistissaan sama data siten että ydin 1 kirjoittaa sinne uuden arvon kellojaksolla N ja ydin 2 lukee vanhan arvonsa kellojaksolla N+1, tai N + 10.

Tämä on täysin sallittua, kunhan näiden muistioperaatioiden välissä ei ole tapahtunut muita muistioperaatiota siten että muistin konsistenttiussäännöt rikkoontuvat.

Tässä tapauksessa muisti ei ole yhtenäistä, eli on tilanne että muistissa on samasta datasta kaksi eri versiota. Nyt jos meillä on esimerkiksi lukitus jossa vain luetaan lukon arvo ja sen näyttäessä vapaata kirjoitetaan sinne lukitus ja hypätään operoimaan jaettuun dataan toinen threadi voi lukea lukituksen vanhan arvon omasta välimuististaan ja hypätä myös kirjoittamaan samaan data-alueeseen eli lukitus ei toimi ja data korruptoituu. MESI-hoitaa kyseisen ongelman sillä että kirjoitus onnistuu vain eksklusiiviseen cachelinjaan - protokolla invalidoi ko. linjan muista cacheista ennenkuin ytimelle annetaan oikeus kirjoittaa ko. linjaan.

Prosessorin muistikonsistenttiussäännöthän taas eivät suoraan ole sidoksissa välimuistikoherenttiuteen, eli vaikka välimuisti olisi koherenttia jos prosessori voi kirjoittaa välimuistilinjoille vapaassa ( eli ei ohjelman käskyjärjestyksessä) järjestyksessä se saattaa kirjoittaa lukituskoodin cachelinjalle joka on välimuistissa enenkuin data jota ko. lukitus on suojannut on poistunut store-bufferista välimuistiin - ja joku toinen threadi voi todeta lukon olevan vapaa ja lukea lukituista datoista vanhoja versioita - ja data korruptoituu muistin epäkoherenssiuteen vaikka itse välimuistit ovat 100% synkronoitu.

Itehän olen sen verran ehkä naiivi että en näe total store-orderille mitään tarvetta, jos lukituksen muut osat saa kuntoon niin kyllä siihen pitäisi saadan synkronointikäskytkin sovitettua mukaan ihan ogelmitta. Mutta ainakin osa tyypeistä jotka näitä työkseen tekee näkee tuon TSO:n vähentävän bugeja, ja kait muutakin kuin että buginen koodi toimii sattumalta.

Ja MESIä kai käyttää vämuistikoherenssiprotokollana nykyään kaikki kun se on siihen hommaan sangen hyvä, ainoa puute on hidas kirjoitus jaettuun dataan. Voisihan sitä leikitellä ajatuksella että prosessorin annetaan kirjoittaa jaettuun dataan suoraan ja suorittaa invalidointi vasta sen jälkeen, mutta mitä käy jos kaksi prosessoria toimii näin yhtäaikaa? Mesihän on siitä harvinainen tapaus että se vaikuttaa olevan täydellinen, alkuperäiseen oon nähnyt lähinnä Intelin F(orward)-lisäyksen eli jaettuun dataan annetaan vain yhdelle oikeus jakaa sitä eteenpäin, vähentää koherenssiliikennettä.

 

[Juha Kokkonen]

Nyt sitten palataan sieltä yleisen tason keskustelusta ja AMD-/Intel-akselilta ketjun aiheeseen.

Ja @Sami Riitaoja käytä foorumin lainaus-toimintoa sen sijaan että kirjoitat useamman peräkkäisen viestin ketjuun, kiitos

 

[saan]

Ainakaan vuotojen Cinebench R23 tulokset 990/4530 ei ihan hirmuisesti vakuuta, verrattuna myynti puheiden "up to" lukemiin, jos nuo tulokset pitää paikkaansa. Melko samaa tasoa tuon Surface pro 7:n (I5-1035g4) 1030/3960 kanssa, mitä äsken testasi omalla tabletilla.

Apple's M1 MacBooks Are Stronger Than Intel MacBooks, Even When Emulated

Even with the Rosetta 2 translation layer running, M1 MacBooks come out on top.

www.tomshardware.com

 

[Sami Riitaoja]

Ainakaan vuotojen Cinebench R23 tulokset 990/4530 ei ihan hirmuisesti vakuuta, verrattuna myynti puheiden "up to" lukemiin, jos nuo tulokset pitää paikkaansa. Melko samaa tasoa tuon Surface pro 7:n (I5-1035g4) 1030/3960 kanssa, mitä äsken testasi omalla tabletilla.

Apple's M1 MacBooks Are Stronger Than Intel MacBooks, Even When Emulated

Even with the Rosetta 2 translation layer running, M1 MacBooks come out on top.

www.tomshardware.com

Tuo tuloshan lienee Applen kehityspöntön A12Z-prosessorin tulos, esimerkiksi M1:n ST kellotaajuus on 3,2GHz eikä 2.5. Jokatapauksessa tulos on epäilyttävän alhainen.

 

[saan]

Tuo tuloshan lienee Applen kehityspöntön A12Z-prosessorin tulos, esimerkiksi M1:n ST kellotaajuus on 3,2GHz eikä 2.5. Jokatapauksessa tulos on epäilyttävän alhainen.

Näyttäisi tosiaan täsmäävän tuon dev kitin tuloksiin mitä tuohon oli kaivettu.

 

[Humanoid]

Uuden MacBook Pron Cinebench-tulos: 7508 multicore, 1498 singlecore

 

[-vmk-]

Tässä 10 minuutin run. Ei näytä tulokset droppaavan.

 

[exkomura]

Voisko tän siirtää prossu alueelle. Jotenkin tyhmää että tämä on täällä piilossa ja keskustelu on hujan hajan.

 

[vemkki]

Voisko tän siirtää prossu alueelle. Jotenkin tyhmää että tämä on täällä piilossa ja keskustelu on hujan hajan.

On aiheesta jo siellä keskusteluaihe, mutta väki kommentoi edelleen tänne. Ehkä tämä ketju kannattaisi lukita.

Applen CPU:t -keskustelu (M1, M1 Pro, M1 Max...)

Aiheesta keskustellaan jo useammassa ketjussa, joten keskitetäänkö tänne? Tänään pilpahti Rosetta 2 -tuloksia Geekbenchiin. Kovia lukuja, jos pitävät paikkaansa: https://www.macrumors.com/2020/11/15/m1-chip-emulating-x86-benchmark/

bbs.io-tech.fi