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

[Timo 2]

Kiitoksia @Sami Riitaoja ja @hkultala taas ymmärtää pikkasen enemmän prossuytimen toiminnasta.

Luulin, että olet joskus suorittanut TTYn/TTKKn"tietokonetekniikka"-kurssin. Siellä kyllä on asia selitetty.



Käskyn suorittamiseen pitää tehdä monta asiaa, yksinkertaisimmillaan esim.

1) hakea käsky (käskyväli)muistista (aikaa kuluu esim. 0.35 ns)
2) dekoodata, että mistä käskystä on kyse, mitä sen pitäisi tehdä, muodostaa tämän perusteella prosessorin sisäiset kontrollisignallit (aikaa kuluu esim. 0.2 ns)
3) lukea käskyn tarvitsema data rekistereistä (aikaa kuluu esim. 0.2 ns)
4) suorittaa varsinainen laskuoperaatio (aikaa kuluu esim. 0.3ns)
5) kirjoittaa tulos kohderekisteriin (aikaa kuluu esim. 0.15ns)

Mikäli mitään liukuhihnaa ei ole, ja käsky suoritetaan kellojaksossa, sen suorittamiseen menee aikaa kaikkein näiden summa eli tässä esimerkissä 1.2ns. Saavutetaan maksimissaan 833 MHz kellotaajuus.

Jos meillä onkin vaikka 2-vaiheinen liukuhinna, ekassa vaiheessa (ekalla kallojaksolla) haetaan käsky sekä dekoodataan se, toisessa vaiheessa (seuravalla kellojaksolla) luetaan data rekistereistä, suoritetaan laskuoperaatio ja kirjoitetaan tulos, nyt kellojaksossa pitää tehdä vain sen verran, mihin pidempi näistä vie aikaa, eli max(0.35 + 0.2 , 0.2 + 0.3 + 0.15) = max(0.55, 0.65) = 0.65ns, eli kellojakso saa kestää maksimissaan 0.65ns. Eli saavutetaankin 1/0.65 = 1.54 GHz kellotaajuus.

Jos meillä on vaikka 3-vaiheinen liukuhihna, ekassa vaiheessa haku, toisessa dekoodaus ja rekisterinluku, ja kolmannessa suoritus ja tuloksentallennus, pisin vaihe on 0.45ns eli saavutetaan 1/0.45ns = 2.2 GHz kellotaajuus.

Neljällä vaiheella yhdistämällä dekoodaus ja rekisterin luku pisin vaihe on dekoodaus+rekisterinluku eli 0.4 ns, eli saavutetaan 2.5 GHz kellotaajuus.

Viidellä vaiheella pisin vaihe on käskynhaku eli 0.35ns, eli saavutetaan 2.86 GHz kellotaajuus.

Splittaamalla käskyhaku kahteen osaan, kuusivaiheisella liukuhihnalla pisin vaihe olisi suoritus eli 0.3ns, saavutettaisiin 3.33 GHz kellotaajuus.

Käytännössä tosin liukuhinavaiheiden väliin tulee aina liukuhihnarekisteri (viive joitain kymmeniä pikosekunteja) joten kellotaajuus ei todellisuudessa skaaladu ihan näin hyvin, ja lisäksi joitain asioita ei vaan pysty splittaamaan useaan liukuhihnavaiheeseen järkevästi johtuen siitä, mitä se tekee.


Toki sitten prosessorin rakenteen monimutkaistuessa väliin tulee sellaisia liukuhihnavaiheita jotka tekevät asioita, joita yksinkertaisen prosessorin ei tarvitse ollenkaan tehdä. Esim. perinteisillä 1980-luvun RISC-prossuilla on tuossa laskuoperaatio(EXEC)- ja tuloksentallennusvaiheen(WB) välissä muistiaccess-vaihe (MEM) (ja niissä myös dekoodaus ja rekisterinluku oli yhdistetty samaksi vaiheeksi).

Ja siihen, kuinka paljon aikaa tarvitaan suoritukseen vaikuttaa aika paljon se, millaisia käskyjä on. kokonaislukujen kertolasku vaatii n. 2-3x enemmän aikaa kuin yhteen-/vähennyslasku, joten suurimmassa osassa prossuista on sitten rakenne jossa kertolaskulla on pidempi liukuhihna(ja siis enemmän viivettä käskyllä kellojakoissa mitattuna) kuin yhteen- ja vähennyslaskulla.

Rekistereitä uudelleennimeävät ja käskyjä uudelleenjärjestelevät prosessorit taas tarvitsevat vaiheet sille rekisterien uudelleenimeämiselle, käskyjen laittamiselle puskuriin odottamaan suoritusta sekä niiden skeudulointiin suoritukseen, sekä vielä tuloksen eläköitymiseen (retire) jolloin käsky virallisesti julistetaan suoritetuksi ja käskyvuo tuodaan takaisin alkuperäiseen järjestykseen. Eli käytännössä monimutkainen ja kehittynyt ydin tarvitsee muutaman vaiheen enemmän päästäkseen samaan kellotaajuuteen.


Kellotaajuuden kannalta ratkaiseva tekijä on siis pisimmän liukuhihnavaiheen pituus, ei suoraan likuhihnan vaiheiden määrä, mutta kun kyse on prosessoreista jotka ovat ominaisuuksiltaan melko samalla tasolla, nämä korreloivat hyvin vahvasti keskenään.

Mutta eikös ollut jotain että liian pitkä liukuhihna heikentää IPC arvoa, näinhän kävi ymmärtääkseni netburstin arkkitehtuurin kanssa, kun tehtiin jotain kompromissejä, jotta saadaan kovat kellotaajuudet.

 

[hkultala]

Kiitoksia @Sami Riitaoja ja @hkultala taas ymmärtää pikkasen enemmän prossuytimen toiminnasta.

Mutta eikös ollut jotain että liian pitkä liukuhihna heikentää IPC arvoa, näinhän kävi ymmärtääkseni netburstin arkkitehtuurin kanssa, kun tehtiin jotain kompromissejä, jotta saadaan kovat kellotaajuudet.

Liukuhihnan pituus vaikuttaa käytännössä aina haarautumisennustushudin pituuteen, eli siihen, että kuinka paljon keskeneräistä työtä joudutaan heittämään menemään ja kuinka monen kellojakson päästä saadaan taas prossun liukuhihnalla käskyjä suoritukseen asti.

Lisäksi pidempi liukuhihna tarkoittaa pidempiä viiveitä joillekin käskyille(yleensä yksinkertaisilämmilla käskyillä on silti vain yhden kellojakson viive), eli aiemman käskyn tulosta odottavat käskyt joutuvat odottelemaan kauemmin.

Mikäli kellotaajuus skaalautuisi suoraan liukuhihnavaiheiden suhteessa, kumpikaan näistä ei olisi hidaste, kun niihin ei absoluuttista aikaa menisi sen enempää.

Mutta koska kellotaajuus ei skaalaudu suoraan liukuhihnavaiheiden määrän mukaan, nämä hidastavat.

Pentium4lla suurin ongelma liian pitkästä liukuhihnasta oli kuitenkin siinä, että siinä jouduttiin tietyt asiat toteuttamaan "huonommin" koska niitä ei vaan voinut liukuhihnoittaa enempää tai niiden liiallinen liukuhihnoitus monimutkaisti aisoita selvästi:

1) p4n L1D-välimuisti oli läpikirjoittava eli kun sinne kirjoitettiin, kirjoitus meni heti L2lle asti. Tämä mm. aiheutti turhaa liikennettä (mm haaskasi virtaa). Bulldozerissa sama juttu.

2) Käskyskedulerin liukuhihnoitus on hyvin ongelmallista kun skedulointi pitäisi tehdä sen mukaan, stallaako aiempi käsky jolta dataa odotellaan vai ei, mutta se voi stallata liian myöhään. p4 oli optimisti ja skeduloi käskyt oletuksella että aiempi käsky ei stallannut. Ja jos se stallasi, siltä saatiin väärä arvo. Jolloin jo skeduloidun ja suorituksessa olevan käskyn suoritus piti perua ja tämä käsky suorittaa uudelleen myöhemmin. Haaskattiin sekä suorituskapasiteettia että virtaa.


Ja niin, p4n nopeat alut joilla ei sinänsä ollut mitään tekemistä pitkän liukuhihnan kanssa tarkoitti sitä, että bit-shiftaukset oli hitaita. Ja maailma sattui olemaan täynnä koodia jossa bitshiftausta käytettiin esim kahdella tai neljällä kertomiseen (tämä olisi p4lla ollut nopeampaa yhteenlaskulla)

 

[user9999]

Jotain testattu

Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch MacBook Pro

Apple introduced the first MacBook Air, MacBook Pro, and Mac mini with M1 Apple Silicon chips yesterday, and as of today, the first benchmark of the...

www.macrumors.com

 

[JL79]

Aika hurjat testitulokset.
Ja jos ensi vuonna tulee vielä useamman ytimen malleja, niin lisää jytkyjä on kyllä luvassa.

 

[pomk]

Oho! En olisi veikannu että menee noin kevyen oloisesti ohi intelin 8-ytimisistä 45W piireistä myös useamman säikeen kuormilla. Ja toi on vielä se tehottomin julkaistuista malleista.

 

[FlyingAntero]

Jotain testattu

Apple Silicon M1 Chip in MacBook Air Outperforms High-End 16-Inch MacBook Pro

Apple introduced the first MacBook Air, MacBook Pro, and Mac mini with M1 Apple Silicon chips yesterday, and as of today, the first benchmark of the...

www.macrumors.com

Kyseiset testit on ajettu Geekbenchin macOS AArch64-versiolla eli natiivilla ARM-softalla. Olisi mielenkiintoista nähdä tuloksia myös macOS x86 (64-bit) versiolla, että saisi jotain käsitystä Rosetta2:n toimivuudesta.

 

[Bladekill]

Aika hurjat testitulokset.
Ja jos ensi vuonna tulee vielä useamman ytimen malleja, niin lisää jytkyjä on kyllä luvassa.

Joo, joku 12-16 core versio 32-64GB tuella kun tulee niin voi tehokäyttäjätkin ja yrityksetkin alkaa näitä laittamaan.

 

[weetabix]

Ne kaikki tärkeimmät (mikä ikinä sitten kenellekin esim. yrityspuolella aina vuorollaan ovat) softat pitää vaan ensin toimia erittäin hyvin. Suorituskyky on vain yksi osa softan toimivuutta ja näissä siirtymissä vaikka se tärkeä onkin, niin ainakin henkilökohtaisesti se kaikista vähiten tärkeä. Toki lähinnä katsellut vierestä vain näitä alustavaihdoksia ja kauniisti sanottuna niissä olevat ongelmat ovat yleensä liittyneet suuresti muihin ongelmiin kuin jonkin verran huonompaan suorituskykyyn (jonka kanssa monesti pystyy elämään ellei suorituskyky merkittävästi laske).

 

[pomk]

Ne kaikki tärkeimmät (mikä ikinä sitten kenellekin esim. yrityspuolella aina vuorollaan ovat) softat pitää vaan ensin toimia erittäin hyvin. Suorituskyky on vain yksi osa softan toimivuutta ja näissä siirtymissä vaikka se tärkeä onkin, niin ainakin henkilökohtaisesti se kaikista vähiten tärkeä. Toki lähinnä katsellut vierestä vain näitä alustavaihdoksia ja kauniisti sanottuna niissä olevat ongelmat ovat yleensä liittyneet suuresti muihin ongelmiin kuin jonkin verran huonompaan suorituskykyyn (jonka kanssa monesti pystyy elämään ellei suorituskyky merkittävästi laske).

Koko mäsän ja googlen pakka toiminee hyvin heti julkaisussa, alkuvuodesta sit loput isommat softatalot perässä. Perus toimistohommiin ei nykyään kauheasti noiden lisäksi tarvitse mitään.

 

[sayravai]

Ne kaikki tärkeimmät (mikä ikinä sitten kenellekin esim. yrityspuolella aina vuorollaan ovat) softat pitää vaan ensin toimia erittäin hyvin. Suorituskyky on vain yksi osa softan toimivuutta ja näissä siirtymissä vaikka se tärkeä onkin, niin ainakin henkilökohtaisesti se kaikista vähiten tärkeä. Toki lähinnä katsellut vierestä vain näitä alustavaihdoksia ja kauniisti sanottuna niissä olevat ongelmat ovat yleensä liittyneet suuresti muihin ongelmiin kuin jonkin verran huonompaan suorituskykyyn (jonka kanssa monesti pystyy elämään ellei suorituskyky merkittävästi laske).

Apple on vaihtanut arkkitehtuuria jo aika monta kertaa (MC68000 -> PPC -> x86 -> ARM), ja nuo siirtymät ovat olleet jälkeenpäin ajatellen yllättävänkin kivuttomia käyttäjän kannalta (itsellä ollut aktiivikäytössä noita kaikkia, paitsi luonnollisesti tätä uusinta). Yhteensopimattomuudet on hoidettu emulaattorilla ja koska uusi rautasukupolvi on ollut vanhaan verrattuna niin nopeaa, ei se ole menoa haitannut. En siis keksi, miksi nyt olisi toisin. Joidenkin yksittäisten, rautaa lähellä olevien softien kanssa voi toki olla toinen tilanne.

 

[Juha Uotila]

Koko mäsän ja googlen pakka toiminee hyvin heti julkaisussa, alkuvuodesta sit loput isommat softatalot perässä. Perus toimistohommiin ei nykyään kauheasti noiden lisäksi tarvitse mitään.

Microsoft julkaisu jo arm-betan MS Office for Mac:stä eilen illalla, eli natiiviversio varmaan tulossa suht nopeasti. Ehkä jopä ennen vuodenvaihdetta.

 

[FlyingAntero]

Geekbenchin tietokannasta löytyi A12Z Bionic -järjestelmäpiiriin perustuvalla Developer Transition Kitillä ajettuja tuloksia sekä macOS AArch64 että x86 (64-bit) versiolla.

• ADP3,2 vs ADP3,2 - Geekbench Browser

Developer Transition Kit (A12Z)

• ARM: 1143/4870
• x86: 844/2957

Noiden lukujen perusteella suorituskyky putoaa Rosetta2:lla single coressa 26% ja multi coressa 39%. x86:lla prosessori tosin tunnistuu "1 processor, 4 cores", kun ARM:lla se on "1 processor, 8 cores". A12Z on 4+4 big.LITTLE prosessori.

 

[SheikYerbouti]

Microsoft julkaisu jo arm-betan MS Office for Mac:stä eilen illalla, eli natiiviversio varmaan tulossa suht nopeasti. Ehkä jopä ennen vuodenvaihdetta.

Ja Office-softia tosiaan esiteltiin jo WWDC:ssä Apple Siliconilla.

 

[Kaotik]

Ja Office-softia tosiaan esiteltiin jo WWDC:ssä Apple Siliconilla.

Ainakin vielä tuolloin oli huhuja että kyse oli Rosetta-versiosta

 

[SheikYerbouti]

Ainakin vielä tuolloin oli huhuja että kyse oli Rosetta-versiosta

Jotenkin ihanaa, että alan huhut on tasoa "microsoft office muuten pyöri wwdc 2020:n aikana apple silicon -laitteilla oikeasti rosetta 2 -versioina".

Ei minulla mitään asiaa varsinaisesti ollut. Joskus vaan lämmittää huomata kuuluvansa johonkin ihmisryhmään kuin kotiinsa.

 

[escalibur]

Microsoft julkaisu jo arm-betan MS Office for Mac:stä eilen illalla, eli natiiviversio varmaan tulossa suht nopeasti. Ehkä jopä ennen vuodenvaihdetta.

Onneksi Officen Web-sovellukset ovat parantuneet huomattavasti ja asennettavien softien tarve pienenee jatkuvasti. Excelissä on tiettyjä ominaisuuksia, joita ei ole online-versiossa, samoin jos on Outlookissa jotain talon sisäisiä plugareita yms. Muussa tapauksessa antaisin online-versioille mahdollisuuden. "Sotkisin" konetta asennuksilla vasta siten kun jokin asia ei oikeasti toimi.

 

[JL79]

Kolmannen osapuolen softat varmaan aluksi vähän vähissä, mutta eiköhän ne aika äkkiä yleisty.

 

[Kaotik]

Kumma jos mainostavat tuota natiivina appsina, jos emuloituna pyörii

Jaha, video oli timestampattu sen jälkeen kun tuo sanottiin

 

[weetabix]

Itsekin Officea käytän vain selaimen kautta. Ei mitään tarvetta leikkiä millään muulla ja toimii kuitenkin ihan riittävästi Linuxin puolella (joka on se alusta jolla Office käytän jos käytän). Arm kehitys siis kiinnostaa kyllå, ei tosin juuri ollenkaan se toimivatko Macin softat nopeammin, hitaammin vai eivät ollenkaan. Pelituki/softatuki natiivina Raspberry PI -laitteelle kelpaisi kyllä...

 

[Obi-Lan]

Jos käyttää pelkkää selainta ja selainsovelluksia niin eikö chromebox tai chromebook olisi silloin riittävä ja paljon halvempikin vaihtoehto?

Jotekin olen siinä käsityksessä, että Applella on nyt oma rauta ja omat rajapinnat joita vasten sovellukset pitää koodata. Joten mitään muuta alustariippumatonta tapaa tuoda sovelluksia ei ole kuin selainpohjaiset? Ja siinäkin varman ios tyyliin pakotetaan kaikki käyttämään Safarin moottoria , joten Apple loppupeleissä päättää senkin osalta mikä pyörii ja mikä ei.

 

[pomk]

Kolmannen osapuolen softat varmaan aluksi vähän vähissä, mutta eiköhän ne aika äkkiä yleisty.

No enpä tiedä. Jos tekee sovelluskehitystä applen työkaluilla niin tuo tapahtuu kuulemma jotakuinkin automaattisesti. Lisäksi diehard applefanit, jotka on enemmän tai vähemmän vastuussa suurimmasta osasta softakehityksestä kyseisellä alustalla, ovat varmaan ensimmäisenä jonossa vaihtamassa uusiin laitteisiin niiden nopeuden takia. Veikkaan että tammikuuhun mennessä 99% käytetyimmistä softista löytyy natiivituella.

Jotekin olen siinä käsityksessä, että Applella on nyt oma rauta ja omat rajapinnat joita vasten sovellukset pitää koodata. Joten mitään muuta alustariippumatonta tapaa tuoda sovelluksia ei ole kuin selainpohjaiset? Ja siinäkin varman ios tyyliin pakotetaan kaikki käyttämään Safarin moottoria , joten Apple loppupeleissä päättää senkin osalta mikä pyörii ja mikä ei.

Aika paljon ripeämmin nää selainpohjaisia appejaki pyörittää. Safarin moottoria ei ole pakko käyttää, sen ku asentaa minkä vaan selaimen ja käyttää sitä. Suuri osa linuxtyökaluista pyörii hyvin pienin muutoksin macOS:lla.

Sä sekotat nyt aika pahasti iOS:n ja macOS:n alustan rajallisuuden suhteen.

 

[RageDaddy]

Geekkipenkki vitosella ajeltu jo jotain ja jotain.

Apple's M1-Based MacBook Air Benchmarked

When Apple announced that they are going to switch their Mac lineup from Intel-based x86 processors to the custom "Apple Silicon," everyone was wondering how the new processors will look and perform. To everyone's luck, Apple has just a few days ago announced its first Apple Silicon custom...

www.techpowerup.com

 

[FlyingAntero]

Geekkipenkki vitosella ajeltu jo jotain ja jotain.

Apple's M1-Based MacBook Air Benchmarked

When Apple announced that they are going to switch their Mac lineup from Intel-based x86 processors to the custom "Apple Silicon," everyone was wondering how the new processors will look and perform. To everyone's luck, Apple has just a few days ago announced its first Apple Silicon custom...

www.techpowerup.com

Tulokset oli linkattu jo ylempänä mutta single coressa M1 näyttäisi olevan kaikkein nopein CPU ja multi core tulos on Ryzen 5 3600X:n tasoa. Tuloksissa kannattaa tosin huomioida ARM vs. x86 eroavaisuus sovellusversiossa. Jos joudutaan emuloimaan, niin M1 ottaa todennököisesti hittiä 30-40% suorituskyvyssä.

• MacBook Pro 17,1" (M1): 1714/6802 (AArch64)
• AMD Ryzen 9 5950X: 1628/15744 (x86)
• AMD Ryzen 5 3600X: 1251/6973 (x86)

 

[zepi]

Jos käyttää pelkkää selainta ja selainsovelluksia niin eikö chromebox tai chromebook olisi silloin riittävä ja paljon halvempikin vaihtoehto?

Jotekin olen siinä käsityksessä, että Applella on nyt oma rauta ja omat rajapinnat joita vasten sovellukset pitää koodata. Joten mitään muuta alustariippumatonta tapaa tuoda sovelluksia ei ole kuin selainpohjaiset? Ja siinäkin varman ios tyyliin pakotetaan kaikki käyttämään Safarin moottoria , joten Apple loppupeleissä päättää senkin osalta mikä pyörii ja mikä ei.

MacOS on posix-yhteensopiva käyttöjärjestelmä, joten melkein kaikki yleisimmät linux-sovellukset saa nappia painamalla käännettyä toimimaan Mac:lle. Ongelmia muodostaa lähinnä GUI-osuus, joskin Mac:lle on ainakin aikaisemmin saanut X11-libraryt, joilla monet linux-ohjelmat toimivat suoraan. Yksi mitä olen joskus käyttänyt on wireshark.

Toki käyttöjärjestelmien tarjoamat API-kutsut eivät sitten ole suoraan yhteensopivia.

 

[vemkki]

Tulokset oli linkattu jo ylempänä mutta single coressa M1 näyttäisi olevan kaikkein nopein CPU ja multi core tulos on Ryzen 5 3600X:n

Mahtaakohan multicore-testissä tulla TDP vastaan? Toisaalta tietty neljä ydintä on niitä vähemmän järeitä (mutta toisaalta vähän virtaa kuluttavia).

 

[maustevoi]

Mielenkiintoinen prosessori, jos väitteet yms. pitää paikkansa. Innolla seuraillaan, pääsekö muut vastaamaan kilpailuun Applelle ja/tai onko tuo niin hyvä prosessori, kuin kehutaan..

 

[zepi]

Mahtaakohan multicore-testissä tulla TDP vastaan? Toisaalta tietty neljä ydintä on niitä vähemmän järeitä (mutta toisaalta vähän virtaa kuluttavia).

Geekbench on ainakin mobiililla sen verran lyhy testi, että jos kylmällä koneella ajaa, niin lämmöt tuskin tulevat ensimmäisellä ajolla vastaan.

Turbot ovat todennäköisesti Macbook Airissa pistetty ylemmäs kuin minne sustained-clockit taipuvat, joten pitäisi testata sekä first-run lukemat, että sustained-lukemat pidemmän ajamisen jälkeen.

 

[Infy]

Onko mahdollista rakentaa tuollaista Apple tyylistä x86 prossu ydintä jossa olisi yhtä kova IPC kuin Applella alhaisella virrankulutuksella? Anandtechin arittekeleista olen saanut kuvan, että ARM käskykannalla se on muka jotenkin helpompaa kuin x86:lla.

Ja jos sellaisen x86 prosessorin voisi tehdä, niin miksi ei ole tehty? Toki Intel mikroarkitehtuuri kehityksessään nosti jalat pöydälle Sandy Bridgen jälkeen ja AMD lähti Bulldozer harharetkilleen. Nyt Ryzenin myötä x86 maailmassa oikeasti viimein tapahtuu jotain kehitystä.

 

[jive]

Kellotaajuuden kannalta ratkaiseva tekijä on siis pisimmän liukuhihnavaiheen pituus, ei suoraan likuhihnan vaiheiden määrä, mutta kun kyse on prosessoreista jotka ovat ominaisuuksiltaan melko samalla tasolla, nämä korreloivat hyvin vahvasti keskenään.

Kiitoksia erinomaisesta vaikkakin pitkähköstä vastauksesta. Loppukaneetti sisälsi sen olennaisen. Olen kyllä lukenut digitaalisuunnittelua ja mikroelektroniikkaa. Opinnoista alkaa olla vaan yli 20v aikaa ja välissä olen tehnyt jotain ihan muuta.

 

[zepi]

Jos joudutaan emuloimaan, niin M1 ottaa todennököisesti hittiä 30-40% suorituskyvyssä.

Olet nyt toistanut tätä aika monta kertaa aivan kuin x86-emulointi olisi jotenkin jatkuvasti pakollista.

Jos nyt tänään tilaa uuden mäkin, niin joo, joutuuhan sitä muutaman viikon/kuukauden emuloimaan jotain, mutta kun joskus ensi keväänä konetta käyttelee, niin monella käyttäjällä menee päiviä tai viikkoja ilman, että yhtään x86-executablea käynnistyy.

Toki jos tietää tarvitsevansa erikoisempaa softaa, niin tilanne on eri, mutta miksi silloin edes harkitsisi arm-mac:n ostoa? Tai miksi ei harkitsisi softan vaihtoa?

 

[FlyingAntero]

Olet nyt toistanut tätä aika monta kertaa aivan kuin x86-emulointi olisi jotenkin jatkuvasti pakollista.

Jos nyt tänään tilaa uuden mäkin, niin joo, joutuuhan sitä muutaman viikon/kuukauden emuloimaan jotain, mutta kun joskus ensi keväänä konetta käyttelee, niin monella käyttäjällä menee päiviä tai viikkoja ilman, että yhtään x86-executablea käynnistyy.

Toki jos tietää tarvitsevansa erikoisempaa softaa, niin tilanne on eri, mutta miksi silloin edes harkitsisi arm-mac:n ostoa? Tai miksi ei harkitsisi softan vaihtoa?

Ei sitä emulointia tietenkään joudu jatkuvasti tekemään mutta ihan hyvä sen vaikutus on tiedostaa. M1 on aivan ylivertainen piiri jos ja kun sovellukset ovat saatavilla ARM:lle käännettynä ja Rosetta2 toimii sulavasti tarpeen vaatiessa. Siinä vaiheessa, kun Apple korvaa Intelin prosessorit myös iMaceissä, niin muutosvaihe ollaan varmaan saatu tehtyä.

 

[Xanthe_]

Hyvä asia että kehittyy ja itse odottanut että tulisi rohkeampi hyppy kehityksessä.


Huono juttu, suljettu ympäristö. Et voi paljon iloita siitä. T. MacBook käyttäjä.

 

[HerraHumppa]

Tulokset oli linkattu jo ylempänä mutta single coressa M1 näyttäisi olevan kaikkein nopein CPU ja multi core tulos on Ryzen 5 3600X:n tasoa. Tuloksissa kannattaa tosin huomioida ARM vs. x86 eroavaisuus sovellusversiossa. Jos joudutaan emuloimaan, niin M1 ottaa todennököisesti hittiä 30-40% suorituskyvyssä.

• MacBook Pro 17,1" (M1): 1714/6802 (AArch64)
• AMD Ryzen 9 5950X: 1628/15744 (x86)
• AMD Ryzen 5 3600X: 1251/6973 (x86)

Jos tämä on verrannollinen keskimääräiseen suorityskykyyn kautta ohjelmistojen, niin melkoinen pommi on tarjolla. Alkaa houkuttelemaan Apple läppäriksi, enää tuo suljettu ekosysteemi pidättelee. Muuten olisi luottokortti jo vedetty tappiin

 

[maustevoi]

Jos tämä on verrannollinen keskimääräiseen suorityskykyyn kautta ohjelmistojen, niin melkoinen pommi on tarjolla. Alkaa houkuttelemaan Apple läppäriksi, enää tuo suljettu ekosysteemi pidättelee. Muuten olisi luottokortti jo vedetty tappiin

Jos tosiaan tuo virrankulutus / tehosuhde on noin hyvä kun väitetään, niin täälläkin hypätään kyllä Applen kelkkaan läppäreissä mahdollisesti - tosin vasta siinä vaiheessa kun Apple laittaa kosketusnäytön noihin Aireihin.. Montakohan vuotta pitää sitä odotella vielä, 2-4v? "The next big thing".

 

[zepi]

Jos tosiaan tuo virrankulutus / tehosuhde on noin hyvä kun väitetään, niin täälläkin hypätään kyllä Applen kelkkaan läppäreissä mahdollisesti - tosin vasta siinä vaiheessa kun Apple laittaa kosketusnäytön noihin Aireihin.. Montakohan vuotta pitää sitä odotella vielä, 2-4v? "The next big thing".

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.

 

[HerraHumppa]

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.

Eipä taida tabletista olla siihen vähäänkään ohjelmointiin mille on tarvetta?

EDIT: täällä nyt vastaillaan vääriin viesteihin...

 

[Obi-Lan]

Aika paljon ripeämmin nää selainpohjaisia appejaki pyörittää. Safarin moottoria ei ole pakko käyttää, sen ku asentaa minkä vaan selaimen ja käyttää sitä. Suuri osa linuxtyökaluista pyörii hyvin pienin muutoksin macOS:lla.

Sä sekotat nyt aika pahasti iOS:n ja macOS:n alustan rajallisuuden suhteen.

Olettaisin Applen oman piirin rajaavan vapauksia enemmän ios hengessä. Ei varmaan Safari pakotuksia vielä kuitenkaan. Bootcamp lähtee ja jatkossa varmaan hackintoshitkin kun käyttis pyörii vain tietyllä alustalla.

 

[escalibur]

Jos käyttää pelkkää selainta ja selainsovelluksia niin eikö chromebox tai chromebook olisi silloin riittävä ja paljon halvempikin vaihtoehto?

Chromebookit ovat taas Google-sidonnaisia ja se taas jakaa mielipiteitä. Uskalttaisin väittää että MacBookeissa on yleisesti parempi rauta mitä tulee esim. näyttöjen paneelien laatuun, isoihin resoluutioihin, touchpadin toimintaan ja tuntumaan yms asioihin. Siinä olisi Googlella hyvät saumat tarjota "parempaa" vaihtoehtoa, panostamalla tuotevalikoimiin ja mm. premium-luokan mallistoon.

Jotekin olen siinä käsityksessä, että Applella on nyt oma rauta ja omat rajapinnat joita vasten sovellukset pitää koodata. Joten mitään muuta alustariippumatonta tapaa tuoda sovelluksia ei ole kuin selainpohjaiset? Ja siinäkin varman ios tyyliin pakotetaan kaikki käyttämään Safarin moottoria , joten Apple loppupeleissä päättää senkin osalta mikä pyörii ja mikä ei.

Toisaalta taas jos kaikki toimii, mikäpäs siinä. Selainpohjaisissa sovelluksissa on sekin etu että niiden tietoturva on mitä todennäköisemmin paremmalla tasolla, kuin paikallisten sovellusten, joita yleensä ajetaan "I Accept, yes, yes..."-periaatteella. Eiväthän nekään tietty ole 100% tietoturvallisia, mutta niissä on kuitenkin huomattavasti vähemmän tartuntapintaa kuin admin-tasoisella tunnuksella ajettu sovellustiedostolla.

Mitä rajoituksiin tulee, toivottavasti eivät lähde liikaa rajoittamaan esim. selainten engineiden osalta. iOS:n puolella olivat jopa löystäneet sääntöjä sallimalla vaihtamaan oletusselaimen ja mm. sähköposticlientin. Tämä on toki hieman eri asia mutta "toivoa on".

 

[zepi]

Olettaisin Applen oman piirin rajaavan vapauksia enemmän ios hengessä. Ei varmaan Safari pakotuksia vielä kuitenkaan. Bootcamp lähtee ja jatkossa varmaan hackintoshitkin kun käyttis pyörii vain tietyllä alustalla.

Miksi se oma piiri rajaisi yhtään mitään?

Edelleen suuri osa ohjelmistosta muuttuu seuraavalla tavalla Arm:lle:

Editoit yhtä riviä konffifilestä ja käännät uudelleen. Ulos tuleva softa on arm-versio x86-version sijaan.

MacOS:ssä joko on tai ei ole rajoituksia sen suhteen, että voiko sillä ajaa signaamatonta softaa vaiko ei. Toistaiseksi ei ole mitään rajoituksia joita ei klikillä/parilla voisi kiertää.

Ihan samankaltaisille klikeillä joita jo windowssissa tarvitsee tehdä, jos ei käytä konetta jatkuvasti admin-tunnuksella.

 

[jive]

Chromebookit ovat taas Google-sidonnaisia ja se taas jakaa mielipiteitä. Uskalttaisin väittää että MacBookeissa on yleisesti parempi rauta mitä tulee esim. näyttöjen paneelien laatuun, isoihin resoluutioihin, touchpadin toimintaan ja tuntumaan yms asioihin. Siinä olisi Googlella hyvät saumat tarjota "parempaa" vaihtoehtoa, panostamalla tuotevalikoimiin ja mm. premium-luokan mallistoon.

Toisaalta taas jos kaikki toimii, mikäpäs siinä. Selainpohjaisissa sovelluksissa on sekin etu että niiden tietoturva on mitä todennäköisemmin paremmalla tasolla, kuin paikallisten sovellusten, joita yleensä ajetaan "I Accept, yes, yes..."-periaatteella. Eiväthän nekään tietty ole 100% tietoturvallisia, mutta niissä on kuitenkin huomattavasti vähemmän tartuntapintaa kuin admin-tasoisella tunnuksella ajettu sovellustiedostolla.

Chromebookit on aivan eri hintaluokassa. Selainpohjaiset sovellukset ja tietoturva taas eivät sovi samaan lauseeseen.

 

[vemkki]

Itse kyllä arvelen, että tässä on potentiaalia siihen, että Apple kahmii varsinkin läppäreissä reilusti markkinaosuutta PC:ltä. Haasteena on tietysti edelleen se, että hintaskaala alkaa yli tonnista.

 

[jive]

Editoit yhtä riviä konffifilestä ja käännät uudelleen. Ulos tuleva softa on arm-versio x86-version sijaan.

mikä ympäristö näin hyvin toimii?

 

[zepi]

mikä ympäristö näin hyvin toimii?

macOS 11 Big Sur compatibility on Apple Silicon · Issue #7857 · Homebrew/brew

Latest news on native ARM compatibility (2020-12-26) We currently have 3168 formulas bottled for Apple Silicon in homebrew-core. At this point, the table below is probably not really relevant anymo...

github.com

Esim. Tuolla on listaa asioista jotka toimivat jo nyt natiivina. Aika moni asia toimii, vaikka dev-kittejä on OS-devaajilla varmasti todella vähän.

Se tarkoittaa, että moni projekti on kääntynyt käytännössä ilman isompia ongelmia, muuten paljon harvempi juttu toimisi.

 

[escalibur]

Chromebookit on aivan eri hintaluokassa.

Hintaerosta huolimatta mainitsemani erot ja edut ovat silti olemassa.

Selainpohjaiset sovellukset ja tietoturva taas eivät sovi samaan lauseeseen.

Vai niin.

 

[pomk]

Olettaisin Applen oman piirin rajaavan vapauksia enemmän ios hengessä. Ei varmaan Safari pakotuksia vielä kuitenkaan. Bootcamp lähtee ja jatkossa varmaan hackintoshitkin kun käyttis pyörii vain tietyllä alustalla.

Bootcamp toki lähtee (ei tolle taida microsoftilla olla binääriäkään mitä asentaa), mutta muista nykyisestä poikkeavista rajoituksista ei ole mitään havaintoja. Ihmettelisin jos haistattaisivat paskat alustalla oleville kehittäjille.

 

[jive]

Hintaerosta huolimatta mainitsemani erot ja edut ovat silti olemassa.

jos on laittaa muutama sata euroa päätelaitteeseen niin se ei lämmitä että sillä tuhannella eurolla jota ei ole saisi parempaa rautaa.

 

[Sami Riitaoja]

Lisäksi se L1D-access on osa sitä prosessorin liukuhihnaa. Ihan samanlailla se on jaettu liukuhihnavaiheisiin kuin kaikki muukin. Käytännössä menee (noiden kolmen välimuistiviiveessä näkyvän vaiheen osalta) suurinpiirtein siten, että ekassa vaiheessa lasketaan osoite, toisessa vaiheessa 1) aloitetaan TLB lookup sekä sen kanssa rinnakkain 2) way prediction ja aloitetaan sen jälkeen sen perusteella access jonnekin rinnakkain sekä data- että tag-arrayhin, kolmannessa vaiheessa sitten saadaan TLB-lookupin tulos, verrataan sitä TAGiin ja sen perusteella joko annetaan luettu data eteenpäin tai nostataan pystyyn hutiflägi.

Tässä on aika monta (osittain peräkkäistäkin) asiaa tehtäväksi aika pienessä ajassa. Se, että esim. way predictionille voidaan pyhittää oma vaihe ja aloittaa accessit sinne data- ja tag-arrayihin heti seuraavan kellojakson alussa (eikä vasta kellojakson loppupuolella) voi helpottaa aika paljon sitä millä kellotaajuudella homma vielä toimii. Ja mitä enemmän on aikaa TLB-lookupille, sitä isompi (ja paremman osumatarkkuuden omaava) ensimmäisen tason DTLB ytimelle voidaan laittaa

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. TLB-käännökset ja täyden osoiteavaruuden käyttäminen olisi puhdasta typeryyttä.

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.

Ja niin, sitä linkkiä siihen lähteeseen Applen ytimien haarautumishutiviiveestä odotellaan yhä.

Vanhemmat Applen ytimet on dokumentoitu, eli ensimmäiset 64-bittiset versiot oli 16-19 pituisilla liukuhinoilla. 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. Muistelen nähneeni joku vuosi sitten silloisesta Applen ytimestä(12?) analyysin jossa saatiin liukuhinan pituudeksi määriteltyä 25-30.

 

[kaarlos]

Bootcamp toki lähtee (ei tolle taida microsoftilla olla binääriäkään mitä asentaa), mutta muista nykyisestä poikkeavista rajoituksista ei ole mitään havaintoja. Ihmettelisin jos haistattaisivat paskat alustalla oleville kehittäjille.

Näinpä. Ihan kiinnostavaa nähdä millä aikataululla kehitystyökalut saapuvat ARM-käännettyinä - itselleni riittäisi kun olisi Docker, relevantit Java openjdk-versiot sekä Intellij IDEA.

Vaihtui kyllä juuri työläppäri muutama viikko sitten uuteen, että joutaahan tässä taas 3 vuotta odottelemaan.

 

[hkultala]

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".

 

[Sami Riitaoja]

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.

Koko L1-luku voi olla peräisin spekulatiiviselta käskyltä joka pitää nukettaa - 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. Miksi muistihaun osumatarkkuus pitäisi olla jotain muuta kuin muun koodinsuorituksen?
.

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.

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.

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.

Intelin prossuissa oli idiottimaisia ratkaisuja ja suoranaisia bugeja pilvin pimein. L1-datan pitäminen threadikohtaisena ja sen lukeminen osittaisella lineaarisella osoitteella ei ole yhtään sen vaarallisempaa kuin tuon store-forwardinkaan tapauksessa.

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?

Kova olet aina pätemään joo, 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ää.

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.

No mitkä olisivat ne ongelmat? 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. 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.

Miten kuvittelet sen rekisterifileen tai käskypuskurin lukemisen liukuhihnoittavasi?

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

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 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?

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".

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