Intel valmistelee kulisseissa parhaillaan lukuisia eri arkkitehtuureja, kun se on joutunut jatkamaan työpöytäpuolella 14 nanometrin valmistusprosessin käyttöä selvästi aiottua pidempään. Nyt nettiin on vuotanut kuitenkin uutisia 10 nanometrin prosessilla valmistettavasta Tiger Lakesta.
Intelin Tiger Lake -arkkitehtuuri on tuttu muun muassa yhtiön kuluttajaprosessoreiden roadmapista, joka vuoti keväällä nettiin. Kyseessä on ainakin tämän hetkisen roadmapin mukaan vain kannettaviin U- ja Y-sarjalaisina päätyvä arkkitehtuuri. Se rakentuu Willow Cove -ytimistä ja Gen12 eli Xe-arkkitehtuurin grafiikkaohjaimesta.
InstLatX64 on nyt twiitannut Tiger Lake -prosessorin käynnistyslokin tiedot. Loki paljastaa mielenkiintoisia yksityiskohtia prosessorista, kuten tämän hetkisen Engineering Sample -version 1 GHz:n perus- ja 3,4 GHz:n Turbo-kellotaajuudet, neljä ydintä Hyper-threading-tuella sekä aiempaa isomman 12 Mt:n L3-välimuistin. Välimuistia on nyt siis 3 Mt per ydin, kun nykyisissä saman luokan prosessoreissa sitä on 2 Mt per ydin. Lisäksi prosessorille listataan täysi AVX512-käskylaajennostuki.
Kasvanut L3-välimuisti sopii Intelin vanhempaan arkkitehtuuridiaan, jossa Willow Cove -ytimen uusiin ominaisuuksiin listataan välimuistin uudelleensuunnittelu, transistoritason optimoinnit ja uudet turvallisuusominaisuudet. Willow Cove on Intelin seuraava uusi ydin tuoreissa Ice Lake -prosessoreissa käyttöön otetun Sunny Coven jälkeen.
Vuotaneiden roadmappien mukaan Willow Cove -ytimiä käyttävät Tiger Lake -prosessorit olisivat saapumassa markkinoille vuoden 2021 toisella vuosineljänneksellä. Roadmapissa on kuitenkin erillishuomiona lisätty Tiger Lake -prosessoreille merkintä ”TBD”, mikä viittaa siihen liittyvän edelleen joitain epävarmuustekijöitä.
Lähde: InstLatX64 @ Twitter
Minkä ihmeen vuoksi laittavat läppäriprosessoreihinsa AVX512:n?
Juurihan vertasivat nykyisiä läppäri/tablettiprosessoreitaan Ryzeneihin, eivätkä Intelin käyttämät testiohjelmat varmaan AVX512:sta tue.
Hukkaan menee sekin lisäys, ellei nyt Powerpointiin tai Wordiin tule tule joitakin merkillisiä matemaattisia lisävaateita.
katso liitettä 277917
Käsittääkseni AVX:n käyttö on ainakin tietyillä kuormilla paitsi nopeampaa, myös energiatehokkaampaa. Sinällään siis mobiililaitteissa ihan toivottava ominaisuus yrittää puristaa viimeisetkin minuutit akkukestoa irti, vaikka tuskin ne vaikutukset mitään megalomaanisen suuruisia normaalissa läppärikäytössä on.
Tuotahan vois joku testata jos on liikaa aikaa. Ei tarvii kuin kääntää kaikki softat uusiksi ilman AVX flagia. 😀
Jotta niillä voi ajaa AVX-512sta käyttäviä softia.
Ja jotta softankehittäjät voivat ja haluavat alkaa enabloimaan AVX-512-tukea softiinsa, kun AVX-512sta tukevia prossuja on paljon käyttäjillä.
:facepalm:
Ei mitään softaa optimoida käyttämään uusia käskykantalaajennoksia, ennen kuin on (tarpeeksi) rautaa, joka niitä pystyy ajamaan.
Oikea kysymys on, että kuinka intel vielä viime talvenakin on kehdannut julkaista sellaisia uusia työpöytäprossuja, joissa EI OLE AVX-512aa, kun intelillä on kuitenkin pari vuotta ollut jo markkinilla AVX-512sta tukevia ytimiä.
ja AVX-512n järkevyydestä yleisesti:
AVX-512:ssa ei ole kyse vain siitä, että SIMD-leveys tuplataan 256 bitistä 512 bittiin. Vaan se on ominaisuuksiltaan paljon AVXää/AVX2sta edellä ja sille voidaan vektoroida paljon sellaista koodia, jota AVX2lle ei voinut vektoroida, tai jonka vektoroiminen AVX2lle sisälsi huomattavasti overheadia.
(jo AVX2ssa olevat gatherin lisäksi) AVX-512 sisältää scatter-storen ja linjakohtaiset predikaatit. Tämä tarkoittaa, että käytännössä melkein mitkä tahansa loopit, jotka eivät sisällä gotoa, voidaan vektotoida AVX-512lle, riippumatta siitä, milllaista kontrollai ja osoitteidenlaskentaa siellä loopin sisällä on.
AVX-512 voisi antaa intelille tällä hetkellä huomattavan kilpailuedun AMDhen nähden, mutta Intel vaan seisoo tämän tekniikkansa päällä tuomatta sitä kuluttaja-työpöytä-prosessoreihinsa.
Mites hyvin edes näitä AVX ja AVX2 tuetaan nykyisin, kun ovat kuitenkin olleet vuosia olleet molempien valmistajien kivissä, poislukien intelin pentiumit ja celeronit?
Softat jotka tekee oikeasti järeätä numeronmurskausta kyllä tukee. Pelit jo heti paljon huonommin.
sivuhuomio:
Cinebenchin vanhemmat versiot (joilla alkuperäistä Zeniä benchmarkattiin ja saatiin kovia tuloksia inteliin verrattuna) eivät tukeneet AVXää.
Sitten kun AMD julkaisi zen2n(jossa oli täysileveä AVX-datapolku) niin sen julkaisun yhteydessä ajetut benchmarkit oli vihdoin ajettu cinebenchistä sellaisella versiolla, joka vihdoin tuki AVXää 😉
Olisi näyttänyt cinebench-benchmarkit zen vs skylake aika erilaiselta jos jo alusta pitäen olisi käytetty uutta AVXää tukevaa versiota, tai olisi näyttäynyt suorituskykyparannus zen->zen2 siinä testissä aika paljon pienemmältä, jos oltaisiin pysytty vanhan version käyttämisessä 😉
takaisin asiaan:
Ongelmana on usein se, että halutaan säilyttää yhteensopivuus vanhaan rautaan, ja jos halutaan sekä säilyttää yhteensopivuus vanhaan rautaan että tukea uusia käskykantoja uudella raudalla, pitäisi kikkailla monen eri koodipolun kanssa, joka monimutkaistaa softankehitystä selvästi.
ja intel tosiaan huomattavasti pahentaa tätä ongelmaa tuolla typerällä markkinasegmentoinnillaan että jättää AVXn pois noista "celeroneista" ja "pentiumeista"; Softankehittäjä ei voi vieläkään vaan sanoa kääntäjälle että "AVXää saa käyttää" koska sitten tulisi valitusta celeronien ja pentiumien omistajilta, että softa ei toimi heidän prosessoreillaan.
Ja useimmat pelit on vieläkin 32-bittisiä binääreitä, ja monet kääntäjät nykyään 32-bittisessä moodissa oletuksena targetoi P6sta jossa ei ollut edes MMXää. Kehittäjä pitää tosiaan tällöin erikseen sanoa kääntäjälle, mitä SIMD_käskykantoja saa käyttää.
64-bittisessä moodissa taas SSE ja SSE2 on aina tuettu, niitä saa sentään aina käyttää, eli kääntäjä oletuksena kytkee koodingeneroinnin niille päälle. Joten suurin osa pelinkehittäjistä menee niillä.
Avx512 on ymmärtääkseni myöhässä kuluttajaprossuista, koska sen tuominen niihin oli sidottu 10nm:ään.
Tuo "sitominen" on vaan typerä päätös inteliltä;
Intelillä kuitenkin on "14nm"llä tehty skylake-SP-ydin, jossa on AVX-512. Intel voisi aivan hyvin tehdä nykyisiä skylake-SP-piirejä pienemmän skylake-sp-ytimet sisältävät piirin, laittaa sen LGA1151-soketille ja myydä sitä kuluttajille.
(ja IMHO intelin olisi näin pitänyt tehdä jo silloin, kun coffee lake julkaistiin)
Voi olla, cannon lakesta se löytyy, mutta pienen viivästymisen vuoksi se ei koskaan tullut yhtä läppärimallia laajempaan käyttöön
Kukaan ei tainnut huomata sarkasmiansaa viestissäni :geek:
Ehkä seuraavassa läppäreiden ja 2-in 1 -koneiden nopeusvertailuissa Intel vertaileekin Cinebenchiä, tai vaikka CROMACSia tai muuta AVX512:ää tukevaa ohjelmaa, kun AMD:n Ryzeneissä ei sille ole tukea.
Voisi, mutta ehkä siellä on jatkuvasti uskottu, että 10nm tulee 6kk päästä ja sitä aikaa varten ei viitsi. Tjsp. Idioottimaista.
Nythän Intel kyllä ainakin väittää irrottaneensa prosessien ja ominaisuuksien kehityksen toisistaan.
Mutta missä TSX? Jos ne haluavat transaktionaalisen muistin yleistyvän softissa, sille pitäisi saada tuki koko skaalalla!
TSX on vahvasti feature, jota varten pitää olla rautatukea, että se yleistyisi softissa. Nyt käyttötapaukset rajoittuu aika selkeästi custom softaan, vaikka maailma olisi auki tälle!
Osaatko avata maalikolle, mikä ominaisuus tuo transaktionaalinen muisti on.
Mahdollistaa joidenkin asioiden tekemisen monisäikeisissä softissa ilman synkronointia.
Eli, normaalisti, jos kaksi säikettä yrittää käyttää samassa muistiosoitteessa olevaa yhtä aikaa, on arpapeliä, kumpi niistä saa käsiteltyä sitä ensin, kumpi myöhemmin, Ja arpa heitetään uusiksi jokaiselle muistiaccessille.
Jos meillä on joku looginen asia, jonka käsittelyyn tarvii tehdä monta muistiaccessia (esim. tietorakenne jonka lukeminen pitää tehdä monella lukuoperaatiolla, tai joku operaatio jonka yhteydessä arvo ensin luetaan muistista, muokataan sitä , ja sitten tallennetaaan musitiin), niin nämä monta muistioperaatiota voivat mennä limitetysti näiden kahden säikeen välille, ja se yleensä tarkoittaa sitä että koodi laskee väärin.
Esimerkki 1:
Oletetaan että meillä on joku laskuri A
Säie 1 lukee arvon A
Säie 2 lukee arvon A
Säie 1 muuttaa arvoa A ja tallettaa sen muistiin
Säie 2 muuttaa (aiemin lukemaansa) arvoa A ja tallettaa sen muistiin.
Tällöin säie 2 ylikirjoittaa säikeen 1 kirjoittaman arvon ja on kuin sitä ei koskaan olisi tehty. laskurin arvo onkin kuin sitä olisi päivitetty vain kerran, ei kaksi kertaa.
Tähän tyypillisenä ratkaisuna on joko synkronointi, jolla pakotetaan että säie 2 saa luettua arvon A vasta kun säie 1 on sen kirjoittanut, tai atomisuus, joka tarkoittaa että koko "luku-päivitys-kirjoitus" on muistin näkökulmasta yksi operaatio, jonka välissä ei saa tehdä muuta. Monissa käskykannoissa on atominen inc(yhdellä lisäys)-operaatio, muttei mitään monimtukaisempaa.
Synkronointi taas tarkoittaa huomattavaa määrää käskyjä ja liikennettä ytimien välillä.
Transaktionaalinen muisti tarkoittaa sitä, että monta muistioperaatiota (ja kaikki niiden välissä tapahtuvat laskentaooperaatiot) voidaan niputtaa muistin järjestyksen(konsistenttiuden) näkökulmasta atomiseksi "transaktioksi". Ennen kuin transaktio on suljettu, mikään sen tekemä ei näy muualle, eikä mikään muualla tällä välillä tehty näy sille. Ja transaktio voi myös failata/voidaan perua, jolloin näyttää kuin mitään sen sisällä olevaa ei olisi suoritettu.
Toinen esimerkki on esim. seuraava:
Säie 1 tuottaa dataa, vaikka pelin varsinainen engine joka pyörittää pelilogiikka ja fysiikkaa, ja tuottaa jatkuvsti uusia versioita datastaan.
Säie 2 kuluttaa dataa, vaikka pelin grafiikkaengine, joka piirtää kuvan. Sen pitää saada mahdollisimman uusi versio kokonaisesta datasta.
Jos uuden datan laskeminen on vielä kesken, sitten sen kuuluu lukea se viimeisin data joka on kokonaan saatavilla. Keskeneräisen datan lukeminen tarkoittaisi sitä, että sama objekti voisi olla maailmassa monta kertaa jne.
Ilman mitään syknronointia säie 2 lukisi keskeneräistä, epäkonsistentia dataa.
Eli data pitää synkronoida; Säie 2 odottelee ennen lukemistaan, että data on valmista, ja kun säie 1 saa datansa valmiiksi, se herättää säikeen 2 lukemaan sen.
Transaktionalisen muistin kanssa tilanne voisi teoriassa olla siten, että säie 1 kirjoittaa kamansa transaktionaaliseen muistiinsa sitä laskiessaan.
Mikäli säie 2 lukee muistia tällä välillä, se saa muisitista vanhan, konsistentin version.
Vasta kun se on laskenut kaiken, se "commitoi" transaktionsa ja vasta tämän jälkeen säe 2 voi nähdä sen datat.
Ja säie 2 lukee sitä dataa myös transaktiona; Vasta kun myös se on sulkenut oman transaktionsa, säikeen 1 tekemät muutokset näkyvät sille.
Saattoi olla myös, että jos useampi transaktio yrittää käsitellä samaa osoitetta yhtä aikaa, jälkimmäinen niistä ei odota ensimmäisen datoja vaan failaa ja pitää uudelleenkäynnistää, en ole varma yksityiskohdista.
Käytännössä intelin TSXn transaktion maksimikoko on paljon pienempi kuin mitä jonkun pelienginen data ovat, joten tuo kakkosesimerkkini ei oikeasti toimi tuollaisenaan; TSX:n toteutus pohjaa L1D-välimuistin käyttämiseen joten transaktion kokoa rajoittaa ainakin L1-välimuistin kapasiteetti (lake-sarjassa 32 kiB, cove-sarjassa 48 kiB). Ilmeisesti, mikäli transaktion koko olisi suurempi kuin mitä L1D-välimuistiin mahtuu, transaktio failaa. Ja tässä se koko ei mene suoraan tavuina vaan sen pitää siis mahtua niihin välimuistilinjoihin, mitä siellä välimuistissa on, niiden sääntöjen mukaan, miten data välimuistissa voi mennä.
Embrace and extend (ala MS).
Kun et pysty enää kilpailemaan yhteensopivan IPC:n suorituskykykisassa (etenkään suhteessa hintaan) ja omat arkkitehtuurimuutokset tulevat vuosien päästä, niin tee jotain epäyhteensopivaa, josta koitat tehdä standardin ja tehdä sillä kilpailijan tilanteen hankalammaksi.
Kaikki, joilla on markkina-aseman johto, yleensä käyttävät tätä teknologiateollisuudessa (MS, Intel, nVidia, Oracle, jne).
Eli omat epäyhteensopivat laajennukset, joita ei lisenssoida tai lisenssoidaan ylihintaan/viiveellä, ja väliajan sinulla on ainoa tarjonta markkinoilla ja rummutat tätä sitten Jeesuksen uutena tulemisena.
Tulee olemaan mielenkiintoista nähdä, kuinka nuo tulevat AVX-512 mobiilisirut tiputtavat kellotaajuuksiaan, että heppoiset läppärijäähyt pysyvät edes jotenkuten mukana lämmöntuotannossa.
OT: Intel osaa erottaa AVX-kellot ja normikellot toisistaan. Joku AVX-512 voi toimia ihan energiatehokkaasti esim. 2.0GHz ja olla silti hyödyllinen. Samaan aikaan läppäriprosessori turbottaa yhdellä säikeellä vaikka 4.5GHz ja tuo AVX-käskyjen suorittaminen ei hidasta sitä.
Eikö AMD:lla ole jo pääsy intelin AVX512 lisensseihin ristilisensointisopimuksen ansiosta? Toki AMD ei ihan päivässä saa siitä omiin kiviinsä.
Vähän vaikuttaa siltä, että AMD ei ole katsonut sitä toistaiseksi tarpeelliseksi, koska AVX-512 ei ole mikään uusi asia.
AVX-512:ta tukevissa 15W TDP:n Ice Lake-U -prosessoreissahan on peruskellotaajuus 1,0-1,3 gigahertsiä.
Pitäisi olla.
AMDllä vasta zen2ssa tuli edes 256-bittinen SIMD-datapolku.
AMDn filosofia on, että paljon datatason rinnakkaisuutta sisältävät workloadia ajetaan GPUlla, eikä CPUlla, joten AMDllä ei ole hirveää intoa nopeasti tukea AVX-512sta.
Käytännössä HSAn yms. yleistyminen on edennyt paljon hitaammin kuin mitä AMD toivoisi eikä AMDllä ole markkinoillakaan kovin tehokkaita yhdistelmäpiirejä joissa on sekä CPU- että GPU-ytimiä. Erillisnäyttiksen kanssa taas datansiirto-overheadit CPUn ja GPUn välillä estää käyttämästä näyttistä monissa "fine grained"-jutuissa jossa dataa massiivisen rinnakkaisuduen sisältävä koodi on lyhyt.
Ja muutenkin Intelillä on yleensä ollut selvästi enemmän asenne, että tehdään tulevaisuudenvarmoja prosessoreita joille pyritään tekemään hyvä suorituskyky koodilla, jota oletetaan muutaman vuoden päästä tarvitsemaan, siinä missä AMD pyrkii enemmän optimoimaan suorituskyvyn mahdollisimman hyväksi senhetkisillä softilla. (P4n kanssa vaan intel arvioi selvästi pieleen, mitä se "tulevaisuuden koodi" tulee olemaan). Tämä motivoi Inteliä ottamaan nopeammin käyttöön uusia käskykantalaajennoksia, siinä missä AMD ottaa uusia käskykantalaajennoksia käytöön pääasiassa lähinnä siinä vaiheessa, kun niitä ilmestyvät softat on jo ilmestyneet.
AMD:n osalta pari poikkeusta on 3Dnow ja x86_64. Okei toi x86_64 ei nyt oikeastaan olekaan vain käskylaajennos, niin ei ehkä kuulu tuohon joukkoon. 3Dnow oli aikanaan ihan hyvä, mutta Intelin Simd tappoi sen, niin selvästi AMD on oppinut, ettei heillä ole vielä tarpeeksi voimaa ja vaikutusvaltaa olemaan edelläkävijä laajennoksissa.
3dnow ei todellakaan ollut "ihan hyvä", koska se ei tukenut kaikkia IEEE-754n virallisia pyöritysmoodeja, mikä käytännössä esti kokonaan kääntäjiä vektoroimasta koodia sille; Ainoa tapa käyttää sitä oli että koodaaja erikseen kirjoitti 3dnow-assyä tai intrinsiccejä, missä oli hirveä vaiva (hukattua koodausaikaa, jolle olisi parempaakin käyttöä)
Kun taas SSElle kääntäjä pystyi vektoroimaan mitä tahansa floateilla laskevaa koodia.
Kyllä sen kääntäjän saa tuonkin homman tekemään, jotta sitä assyä ei tartte käyttää. Ja se oli kuitenkin tarkoitettu 3D -peleihin, joihin Intelin mmx-laajennos ei tarjonnut oikein mitään apua. Ja 3Dnow oli ennen SSE:tä, joten siksi se oli hyvä aikanaan (ennen SSE:tä). Lisäksi se SSE taisi puuttua halvemmista prossuista (Celeron), mutta tämä on nyt omaan muistiin nojaava mutu. Mutta muistelisin että SSE:tä tukeva järjestelmä olisi tuolloin ollut kalliimman puoleinen.
Sekoitatkohan nyt autovektorisoinnin ja intrinsiccien käytön keskenään?
Koska kääntäjän ei pitäisi SAADA autovektoroida mitään 3dnowlle väärien pyöristysten takia. Kääntäjä ei SAA tehdä koodia joka tuottaa väärän tuloksen (ellei sille laiteta päälle jotain "salli epätarkat liukulukulaskut"-flagiä)
3dnow tuli vain 9kk ennen SSEtä, mutta SSE oli paljon kehittyneempi.
Eli siinä vaiheessa, kun kukaan olisi oikeasti voinut alkaa 3dnow-koodia kirjoittamaan siten että sitä voi myös testata, tiedettiin jo SSEn spesifikaatiot ja tiedettiin myös että SSEtä tukevat prossut on aika pian tulossa.
SSE taisi tulla celeroneihin siinä vaiheessa, kun tuli coppermine-pohjainen celeron (eli n. vuosi P3n jälkeen)