Intelin Willow Lake -arkkitehtuuri kasvattaa L3-välimuistia 50 %

[Kaotik]

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

Linkki alkuperäiseen uutiseen (io-tech.fi)

 

[demu]

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.

 

[edup]

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.

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.

 

[hkultala]

Minkä ihmeen vuoksi laittavat läppäriprosessoreihinsa AVX512:n?

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

Ja tosiaan mitä leveämpi SIMD, sitä energiatehokkaampaa sen käyttäminen on. Sopii erityisen hyvin läppäreihin jos niistä pitää saada paljon suorituskykyä irti.

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.

Ei mitään softaa optimoida käyttämään uusia käskykantalaajennoksia, ennen kuin on (tarpeeksi) rautaa, joka niitä pystyy ajamaan.

Että "nykysoftat ei hyödy" on todella typerä argumentti. Ei tietokoneisiin laiteta kalliita tehokkaita prossuja sen takia, että nillä ajetaan muinaisia kevyitä softia, vaan sen takia, että niillä pyörii myös tulevaisuuden raskaat softat hyvin.


Oikea kysymys on, että kuinka intel vielä viime talvenakin on julkaissut sellaisia uusia työpöytäprossuja, joissa EI OLE AVX-512aa, kun intelillä on kuitenkin pari vuotta ollut jo markkinoilla 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 vektoroida AVX-512lle, riippumatta siitä, milllaista kontrollia ja osoitteidenlaskentaa siellä loopin sisällä on.

Kun taas AVX2lle ei voida järkevästi vektotoida koodia jos siellä vaikka kirjoitetaan eri iteraatiossa osoitteisiin jotka ei ole peräkkäisiä peräkkäisille iteraatioille, ja myös vektoroitavan loopin sisällä olevan kontrollin hanskaaminen sillä on vaikeampaa (käytännössä aina myös hitaampaa, ja välillä ei onnistu ollenkaan, jolloinei voi kuin jättää loopin vektoroimatta)


AVX-512 voisi antaa intelille tällä hetkellä huomattavan kilpailuedun AMDhen nähden, mutta Intel vaan pääosin seisoo tämän tekniikkansa päällä tuomatta sitä kuluttaja-työpöytä-prosessoreihinsa ennen kuin joskus ehkä ensi vuonna, kolmisen vuotta sen jälkeen kun se oli intelillä jossain saman kokoluokan ytimessä; Palvelin-/HPC-puolella AVX-512 on käytännössä ainoa asia joka pitää intelin jossain määrin kilpailukykyisenä uusia EPYCejä vastaan, ilman sitä Intel ottaisi kaikessa uusilta EPYCieltä köniin mutta nyt intelin Xeonit pärjää hyvin sellaisessa HPC-kamassa joka hyödyntää AVX-512sta

 

[svk]

Mites hyvin edes näitä AVX ja AVX2 tuetaan nykyisin, kun ovat kuitenkin olleet vuosia olleet molempien valmistajien kivissä, poislukien intelin pentiumit ja celeronit?

 

[hkultala]

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än 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ä.

 

[zepi]

Avx512 on ymmärtääkseni myöhässä kuluttajaprossuista, koska sen tuominen niihin oli sidottu 10nm:ään.

 

[hkultala]

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)

 

[svk]

Avx512 on ymmärtääkseni myöhässä kuluttajaprossuista, koska sen tuominen niihin oli sidottu 10nm:ään.

Voi olla, cannon lakesta se löytyy, mutta pienen viivästymisen vuoksi se ei koskaan tullut yhtä läppärimallia laajempaan käyttöön

 

[demu]

Kukaan ei tainnut huomata sarkasmiansaa viestissäni
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.

 

[zepi]

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)

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.

 

[jokumuu]

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!

 

[ovastu02]

Mutta missä TSX? Jos ne haluavat transaktionaalisen muistin yleistyvän softissa, sille pitäisi saada tuki koko skaalalla!

Osaatko avata maalikolle, mikä ominaisuus tuo transaktionaalinen muisti on.

 

[hkultala]

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

 

[halcyon]

Minkä ihmeen vuoksi laittavat läppäriprosessoreihinsa AVX512:n?

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.

 

[hsalonen]

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

 

[svk]

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.

Eikö AMD:lla ole jo pääsy intelin AVX512 lisensseihin ristilisensointisopimuksen ansiosta? Toki AMD ei ihan päivässä saa siitä omiin kiviinsä.

 

[vemkki]

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.

 

[vemkki]

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.

AVX-512:ta tukevissa 15W TDP:n Ice Lake-U -prosessoreissahan on peruskellotaajuus 1,0-1,3 gigahertsiä.

 

[hkultala]

Eikö AMD:lla ole jo pääsy intelin AVX512 lisensseihin ristilisensointisopimuksen ansiosta? Toki AMD ei ihan päivässä saa siitä omiin kiviinsä.

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.

 

[Stephen Elop]

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.

 

[hkultala]

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.

 

[Stephen Elop]

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öä)

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.

 

[hkultala]

Kyllä sen kääntäjän saa tuonkin homman tekemään, jotta sitä assyä ei tartte käyttää.

Sekoitatkohan nyt autovektorisoinnin ja intrinsiccien käytön keskenään?

Koska kääntäjän ei pitäisi SAADA oletuksena 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ä)

Ja toisin kuin Intelillä, AMDllä ei myöskään ollut omaa kääntäjää, ja microsoftin visual studion ja muinaisen gccn kykyyn vektoroida ylipäätään millekään juuri mitään vuonna 1998 en oikein usko.

Intelin kääntäjä taas on perinteisesti ollut vektoroinnin suhteen selvästi gcctä ja mikkisoftan kääntäjää edellä.

Esimerkiksi gcc 3.4n manuaaleista löytyy optio -mfpmath=unit, jossa vaihtoehdot on
387
sse
sse, 387 (käyttää molempia tilanteen mukaan)

Mutta ei ollenkaan 3dnow:ta.

Lisäksi sieltä löytyy optiot:

-m3dnow
-mno-3dnow
These switches enable or disable the use of built-in functions that allow direct access to the MMX, SSE, SSE2, SSE3 and 3Dnow extensions of the instruction set.

See X86 Built-in Functions, for details of the functions enabled and disabled by these switches.

To have SSE/SSE2 instructions generated automatically from floating-point code, see -mfpmath=sse.

Eli tuon dokumentaation mukaan ei tekisi mitään varsinaista koodingenerointia 3dnow:lle vaan ainoastaan tukee noita intrinsiccejä, sen sijaan sse:tä voi käyttää normaalin liukulukukoodin suorittamiseen.

Ja tämä on siis gcc 3.4, ajalta kun 3dnow oli jo monta vuotta vanha (paljon aikaa tuen sille lisäämiseen) mutta ei vielä kuitenkaan obsolete, kaikissa AMDn tuon ajan prossuissa oli edelleen 3dnow

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.

3dnow tuli vain 9kk ennen SSEtä, mutta SSE oli selvästi 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 tuli celeroneihin siinä vaiheessa, kun tuli coppermine-pohjainen celeron (eli n. vuosi P3n jälkeen)

Intel Celeron 600 "Coppermine128"