Intelin julkaisematon Elkhart Lake -Atom-prosessorit löysivät tiensä myyntiin (Tremont)

[Kaotik]

Kaotik kirjoitti uutisen/artikkelin:
Vaikka suurin mielenkiinto markkinoilla keskittyy luonnollisesti suorituskykyisiin prosessoreihin, ei kehitystyö ja uudet mallit rajoitu niihin. Vaikkei Atom-prosessoreita juurikaan markkinoida enää kuluttajille, ne kuuluvat edelleen Intelin valikoimiin ja päivittyvät jälleen tänä vuonna.

Tuttu Twitter-vuotaja momomo_us on löytänyt nyt kiinalaiselta Cogobuy-kauppasivustolta listattuna kaksi Intelin vielä julkaisematonta Atom-prosessoria. Elkhart Lake -koodinimellä tunnetut ja myytävät prosessorit ovat kaksi tai neliytimisiä. Prosessoriytimet perustuvat Lakefield-prosessoreista tuttuun Tremont-arkkitehtuuriin ja grafiikkaohjain on Gen11-sukupolvea. Prosessorit ovat saatavilla 6, 9 ja 12 watin TDP:lle konfiguroituina.

Prosessorista löytyy erikseen listattuina industrial-versio sekä perusmalli, minkä erottaa toisistaan teollisuuskäyttöön tarkoitettujen mallien 5 astetta korkeampi 110 °C maksimilämpötila. Listatuista tiedoista ei paljastu esimerkiksi prosessoreiden kellotaajuuksia tai muuta vastaavaa. Aiempien tietojen mukaan prosessorit tullaan valmistamaan Intelin 10 nanometrin valmistusprosessilla.

Lähde: momomo_us, Cogobuy (1), (2)

Linkki alkuperäiseen juttuun

 

[SShadow]

Näissä oli joskus ensimmäisissä versioissa ikävä piirre, että piirisarja ei ollut vähävirtainen, vaan saattoi syödä sähköä huomattavasti enemmän kuin itse prosessori. Mikä lie nykyisin tilanne, olisi ihan kelpo korvike ARM-alustalle (Raspberry, Banana, Orange, Potato, jne.)

 

[hkultala]

Näissä oli joskus ensimmäisissä versioissa ikävä piirre, että piirisarja ei ollut vähävirtainen, vaan saattoi syödä sähköä huomattavasti enemmän kuin itse prosessori. Mikä lie nykyisin tilanne, olisi ihan kelpo korvike ARM-alustalle (Raspberry, Banana, Orange, Potato, jne.)

Nämä on jo monta vuotta ollut SoC:eja, ei näiden kanssa enää tarvita mitään piirisarjaa.


Mutta SMT-tuki on ylläri. Sitä ei aiemmissa mont-sarjan ytimissä muistaakseni ollut (vain muinaisessa todella mopossa Bonnellissa oli cache missistä tms. rautathreadinvaihto, coarse-grained MT) edit: EI ollutkaan ylläri, vaan uutisankka.

 

[zepi]

2-ydin prosessori 6W TDP:llä kuulostaa aika kovalta lukemalta, kun "isot" ZEN-ytimetkin menevät 3W/ydin tehoilla ihan siedettävillä kelloilla.

 

[hkultala]

2-ydin prosessori 6W TDP:llä kuulostaa aika kovalta lukemalta, kun "isot" ZEN-ytimetkin menevät 3W/ydin tehoilla ihan siedettävillä kelloilla.

Tuo on SoC, ei pelkkä prosessori.

Siellä piirillä on ziljoona muutakin asiaa kuin pelkät ytimet sitä sähköä kuluttamassa.

Näyttis, muistiohjain, pcie-väyläohjain, levyohjaimet, USB-ohjaimet jne.

Että vertailusi ontuu todella pahasti kun lasket pelkkiä ytimiä.

Eikä zen1-ydin ole mitenkään merkittävästi tuota "isompi". Tuossa on jopa leveämpi käskynhaku ja käskydekooderi kuin Zen:ssä. ALUja tuossa taas on vähemmän (3 vs 4), lataus- ja tallennusyksiköitä sama määrä ja ne ovat yhtä leveitä kuin zen1ssä. SIMD-puolella yksiköitä hiukan vähemmän.

zen2 sitten on tuota järeämpi myös lataus- ja tallennusyksiköiden ja SIMD-leveyden suhteen, mutta edelleen käskynhaultaan/dekoodaukseltaan kapeampi.

 

[L2K2]

2-ydin prosessori 6W TDP:llä kuulostaa aika kovalta lukemalta, kun "isot" ZEN-ytimetkin menevät 3W/ydin tehoilla ihan siedettävillä kelloilla.

Tuossa 6 W on mukana myös (mahdollisesti kohtalaisen tehokas) integroitu GPU ja kaikki muut prosessorin oheistoiminnot. Ei vain kaksi ydintä.

 

[Kaotik]

"Cores: 2/4" taitaakin tarkoittaa että niitä on 2- ja 4-ytimisinä eikä virheellisesti tulkitsemaani 2C4T:tä, uutista korjattu:

 

[hkultala]

"Cores: 2/4" taitaakin tarkoittaa että niitä on 2- ja 4-ytimisinä eikä virheellisesti tulkitsemaani 2C4T:tä, uutista korjattu:

Anandillahan oli tuosta Tremontista juttu jo viime lokakuussa, mutta oli mennyt minulta ohi, nyt huomasin kun aloin googletella.

Se, että siinä on nuo kaksi fetch- ja decode-clusteria hämäsi minut aika hyvin. Ajattelin, että sopisi hyvin SMTn kanssa, toinen toiselle säikeelle ja toinen toiselle säikeelle.

Mutta se toinen onkin sitä varten, että sillä fetchataan ja dekoodaaan koodia eri puolilta haaraa saman kellojakson aikana. Ja jos haarautumisenennustus sanoo että mitään haaraa ei juuri sillä hetkellä ole tulossa, sitten toinen clusteri idlaa.

Perinteisestihän
1) kun käskyjä haetaan normaalisti käskyvälimuistista, fetch-yksikkö hakee vaan joka kellojakso käskyvälimuistista ison yhtämittaisen klöntin (esim 16 tai 32 tavua) ja sitten dekooderi erottelee siitä käskyt erilleen. Ja jos tulee hyppy (muualle kuin parin käskyn päähän saman klöntin sisällä), sitten hypyn kohteesta voidaan hakea käskyjä aikaisintaan seuraavalla kellojaksolla.
2) nopeimmissa prossuissa(zen, sandy brige ja siitä eteenpäin) on myös mikrokoodia tallettava L0-käskyvälimuisti josta voidaan käskyjä hakea myös "tarkemmalla granulariteetilla" ilman tätä rajoitusta.

Tässä Tremontissa sinänsä hienosti haarautumisenennustusta hyödynnetään siihen, että saadaan helpommin dekoodattua enemmän käskyjä kellojaksossa; Monen käskyn dekoodaaminen samasta fetch-klöntistä kellojakson aikana on hankalaa koska seuraavan käskyn aloituspaikka tiedetään vasta kun edellistä on dekoodattu tarpeeksi, joten jos vaikka halutaan dekoodata 4 käskyä kellojaksossa niin jokaisen pituus pitäisi teoriassa selvittää neljäsosakellojakson aikana. (*)

Mutta kun klöntti on lyhyt ja haarautumisenennustus on jo kertonut tarkan paikan mistä seuraava käsky todennäköisesti alkaa, edes sen paikka on selvillä ilman että tarvii odotella edellisten käskyjen pituuden selvittämistä, voidaan dekoodata useampaa käskyä rinnakkain ilman että meillä on ilkeitä riippuvuuksia niiden käskyjen dekoodauksen välillä.


(*) Tosin käytännössä homma yleensä ratkaistaan siten että siellä dekoodataan spekulatiivisesti monesta paikasta yhtä aikaa, aloitetaan dekoodaa esim. rinnakkain sekä kohdista 0, 1,2,3,4,5,6,7, 8, 9, 10, 11, 12,13, ja sitten siinä vaiheessa kun selviää, että ekan käskyn pituus on 3 tavua, heitetään mäkee kohdista 1 ja 2 aloitetun dekoodaukset, ja kun selviää että tokan käskyn pituus on 4 tavua, heitetään mäkeen kohdista 4,5,6 alkaneet dekoodaukset. Ja kun selviää, että kolmannen käskyn pituus on 2 tavua, heitetään mäkeen kohdas 8 alkanut dekoodaus jne.

Käytännössähän ne eri dekoodaukset valmistuu todennäköisesti aika lailla yhtä aikaa, eli ekan käskyn pituustuloksen perusteella vaan valitaan muutamasta eri vaihtoehdosta, että mistä otetaan seuraavan käskyn pituustulos, summataan ne, käytetään tätä taas indeksoimaan sitä että minkä dekoodauken tuloksesta löytyy seuraavan käskyn oddsetti jne, kriittisellle polulle tulee käytännössä yhden käskyn pituuden dekoodaus, sekä jokaista rinnakkaista käskyä kohden adder ja mux.

Mutta se, että dekoodataan monesta paikkaa rinnakkain ja heitetään näistä n. 2/3 mäkeen on melkoista energianhukkaa, sen takia tätä ei haluta näissä virrankulutusoptimoiduissa ytimissä tehdä kovin suuressa mittakaavassa.