AMD CPU-spekulaatio (Zen6/Zen7 ...)

[JiiPee]

Eikö tämä ole oikea ketju kysyä upottajalta twiittien sisältöä , eli mitä tuo LPDDR4(x) tarkoittaa ?
Lisäinformaationa joku käyttäjä voisi kertoa miten tuollainen muisti asennetaan emoon

Googlen käyttö liian vaikeaa?

JEDEC Updates Standards for Low Power Memory Devices | JEDEC

www.jedec.org

 

[ratkakapu]

Eikö tämä ole oikea ketju kysyä upottajalta twiittien sisältöä , eli mitä tuo LPDDR4(x) tarkoittaa ?
Lisäinformaationa joku käyttäjä voisi kertoa miten tuollainen muisti asennetaan emoon

Low power versio DDR4 muistista, X-versio on nopeampaa kuin ilman X:ää

Juottamalla asennetaan, mobiililaitteisiin suunnattu

 

[TheMeII]

Olis se hyvä jos joku kirjoittais tuon twiitin auki , mitä ihmettä siinä oikein puhutaan

koko twiitin idea on tuossa eka viestissä:

Renoirissa vanhat säännöt eri väylien kellotaajuuksista ei päde ja 1:1:1 mclock/uclock/fclock ei ole käytössä kuin tietyissä tilanteissa

Eli prossu, muisti ja infinityfabrick voi toimia toisista riippumattomilla kelloilla.
Tämä prossu myös tietää että raskas gpun käyttö tarttee muistikaistaa joten heittää muisteille maximit ja alikellottaa prossua kun taas raskas prossukäyttö tarttee latensseja ja silloin se lukitsee kaikki samaan nopeuteen jolloin muistit hidastuu mutta viiveet vähenee.

Eikö tämä ole oikea ketju kysyä upottajalta twiittien sisältöä , eli mitä tuo LPDDR4(x) tarkoittaa ?
Lisäinformaationa joku käyttäjä voisi kertoa miten tuollainen muisti asennetaan emoon

On, viittaus olikin twitterin käyttöhalukkuuskeskusteluun.

LP = Low Power eli matalemmilla jänniteillä toimiva mutta pienemmän väylän / muistipiiri omaava muisti
DDR = Double Data Rate muisti eli muisti jossa siirretään dataa kellopulssin nousevalla ja laskevalla reunalla
4 = neljäs ddr sukupolvi
x= jatkokehitysmalli (yleisesti nopeampi)

Läppäreissä joko se kolvataan emoon tai käytetään so-dimm kampaa ja pöytäkoneessa ihan perinteistä dimm tyyppistä kampaa:

ok, LPDDR4 äxällä tai ilman kolvataan aina emoon eli ei työpöytäpuolelle. Alempana parikin käyttäjää korjasi tämän virheen, eli työpöydille ja lisäiltävinä muisteina pitää käyttää edelleen perus DDR4 ja kohtapuoliin (noh, ehkä pari vuotta) DDR5 kampoja.

Unohdinko jotain?

 

[Kaotik]

koko twiitin idea on tuossa eka viestissä:

Eli prossu, muisti ja infinityfabrick voi toimia toisista riippumattomilla kelloilla.
Tämä prossu myös tietää että raskas gpun käyttö tarttee muistikaistaa joten heittää muisteille maximit ja alikellottaa prossua kun taas raskas prossukäyttö tarttee latensseja ja silloin se lukitsee kaikki samaan nopeuteen jolloin muistit hidastuu mutta viiveet vähenee.

On, viittaus olikin twitterin käyttöhalukkuuskeskusteluun.

LP = Low Power eli matalemmilla jänniteillä toimiva mutta pienemmän väylän / muistipiiri omaava muisti
DDR = Double Data Rate muisti eli muisti jossa siirretään dataa kellopulssin nousevalla ja laskevalla reunalla
4 = neljäs ddr sukupolvi
x= jatkokehitysmalli (yleisesti nopeampi)

Läppäreissä joko se kolvataan emoon tai käytetään so-dimm kampaa ja pöytäkoneessa ihan perinteistä dimm tyyppistä kampaa:

Unohdinko jotain?

Sen verran kun noista kammoista mainitsit, että LPDDR4X on poikkeuksetta juotettu emolle, eli työpöytä-Renoireilla tuskin pääsee moisista nauttimaan.

 

[KognaK]

Unohdinko jotain?

LPDDR4(x):ssä on samantyyppinen muistiväylärakenne kuin GDDR6:ssa. Eli 2x16bit muistikanavat per piiri. Missään dimmeissä näitä ei ole eikä tule, juotostavaraa suoraan emolevylle. Renoir pystyy käyttämään 4 piiriä maksimissaan(128bit).

 

[demu]

AMD on julistamassa 14. heinäkuuta Ryzen Threadripper PRO 3995WX processorin.
Prosessorissa on 8-kanavainen DDR4-muistiväylä, ja se tukeee maksimissaan 2TB DDR4 ECC -muisteja.
Threadripper PRO 3995WX tulee todennäköisesti tarjolle suuremmilla kellotaajuuksilla kuin vastaavat EPYC-prosessorit.
Emolevyiksi veikataan uusia sWRX8 (AMD WRX80 piirisarja) sekä mahdollisesti yhteensopivuutta sTRX4 -emolevyjen kanssa.

(Itse uskon ennemminkin, että prosessori sopii suoraan EPYC-emolevyihin, kun noilla PCIe-väylämäärillä (128 kpl PCIe gen 4) varsinainen lisäliitäntöjä tarjoava piiriisarja on pikkuisen turha kustannustekijä. Äänipiirit yms. voitaisiin laittaa omien PCIe-kanavien taakse, eivätkä kanavat heti pääse loppumaan kesken)

AMD Ryzen Threadripper PRO 3995WX spotted, could launch next week - VideoCardz.com

AMD is rumored to launch a new Ryzen Threadripper series for a high-end workstations. AMD to launch Threadripper PRO series? AMD Ryzen Threadripper PRO 3995X processor as leaked by Chiphell Just hours ago we teased an anonymous tip we received regarding a possible launch of AMD Ryzen...

videocardz.com

AMD Ryzen Threadripper PRO 3995WX Processor Pictured: 8-channel DDR4

Here is the first picture of the Ryzen Threadripper PRO 3995WX processor, designed to be part of AMD's HEDT/workstation processor launch for this year. The picture surfaced briefly on the ChipHell forums, before being picked up by HXL (@9550pro) This processor is designed to compete with Intel...

www.techpowerup.com

 

[Timo 2]

AMD on julistamassa 14. heinäkuuta Ryzen Threadripper PRO 3995WX processorin.
Prosessorissa on 8-kanavainen DDR4-muistiväylä, ja se tukeee maksimissaan 2TB DDR4 ECC -muisteja.
Threadripper PRO 3995WX tulee todennäköisesti tarjolle suuremmilla kellotaajuuksilla kuin vastaavat EPYC-prosessorit.
Emolevyiksi veikataan uusia sWRX8 (AMD WRX80 piirisarja) sekä mahdollisesti yhteensopivuutta sTRX4 -emolevyjen kanssa.

(Itse uskon ennemminkin, että prosessori sopii suoraan EPYC-emolevyihin, kun noilla PCIe-väylämäärillä (128 kpl PCIe gen 4) varsinainen lisäliitäntöjä tarjoava piiriisarja on pikkuisen turha kustannustekijä. Äänipiirit yms. voitaisiin laittaa omien PCIe-kanavien taakse, eivätkä kanavat heti pääse loppumaan kesken)

AMD Ryzen Threadripper PRO 3995WX spotted, could launch next week - VideoCardz.com

AMD is rumored to launch a new Ryzen Threadripper series for a high-end workstations. AMD to launch Threadripper PRO series? AMD Ryzen Threadripper PRO 3995X processor as leaked by Chiphell Just hours ago we teased an anonymous tip we received regarding a possible launch of AMD Ryzen...

videocardz.com

AMD Ryzen Threadripper PRO 3995WX Processor Pictured: 8-channel DDR4

Here is the first picture of the Ryzen Threadripper PRO 3995WX processor, designed to be part of AMD's HEDT/workstation processor launch for this year. The picture surfaced briefly on the ChipHell forums, before being picked up by HXL (@9550pro) This processor is designed to compete with Intel...

www.techpowerup.com

Mitä lisää tämä toisi?
enemmän kelloja ja muistikanavia?

 

[pomk]

Mitä lisää tämä toisi?
enemmän kelloja ja muistikanavia?

kaksinkertaisen muistikaistan, lisäksi mahdollisesti tuplamäärän pcie väyliä.

 

[akse]

Kyllä vian on oltava jossain päässä sinun konettasi, asetuksiasi tai nettiyhteyttäsi, jos Twitter ei toimi sinulla mutta muilla toimii. Tarkistin vielä ettei vaadi kirjautumistakaan tai muuta että tuo näkyy (jotkut on asetettu näkymään kuulemma vain kirjautuneille ja/tai tilaajille, tuo ei vaadi kumpaakaan)

Kun foorumi tekee sen upotuksen automaattisesti ja ne toimivat suurimmalla osalla, niin ei se kyllä helpointa ole olla käyttämättä niitä.

Ei mullakaan noi näy. Valittaa että tracking protection pitäisi laittaa pois, en ajatellu laittaa.

Aika nopeahan noista olis ottaa kuvakaappaus ja heittää tänne se. Silloin ei haittaisi sekään jos joku tweetti deletoidaan tms. Sitä tuntuu tapahtuvan etenkin vuoto/huhu tweeteissä..

 

[Mechanical Man]

Ei mullakaan noi näy. Valittaa että tracking protection pitäisi laittaa pois, en ajatellu laittaa.

Aika nopeahan noista olis ottaa kuvakaappaus ja heittää tänne se. Silloin ei haittaisi sekään jos joku tweetti deletoidaan tms. Sitä tuntuu tapahtuvan etenkin vuoto/huhu tweeteissä..

Sähän voit sen laittaa muille lukemalla siellä sandboxatussa virtuaalikoneessa foliohattu päässä.

Pikku juttu kuitenkin.

 

[JiiPee]

Ei mullakaan noi näy. Valittaa että tracking protection pitäisi laittaa pois, en ajatellu laittaa.

Aika nopeahan noista olis ottaa kuvakaappaus ja heittää tänne se. Silloin ei haittaisi sekään jos joku tweetti deletoidaan tms. Sitä tuntuu tapahtuvan etenkin vuoto/huhu tweeteissä..

Aika nopeeta siitä upotuksesta ottaa oikealla hiiren namiskalla "kopioi linkki" ja vetää sitten foliopipon korville, avaa uuden incognito ikkunan ja pastee sen linkin siihen.

 

[TheMeII]

Aika nopeeta siitä upotuksesta ottaa oikealla hiiren namiskalla "kopioi linkki" ja vetää sitten foliopipon korville, avaa uuden incognito ikkunan ja pastee sen linkin siihen.

avaa uuden incognito ikkunan virtuaalikoneessa pyörivään linuxiin jonka distro on valittu foliopipon vaatimusten mukaan ja pastee sen linkin siihen.

 

[Kaotik]

Eiköhän sitten lopeteta tuo täysin turha offtopic

 

[demu]

Mihinkähän prosessoriin viitataan tässä Micronin DDR5-pressissä?
Tokihan tässä on esitelty DDR5-ominaisuuksia vain erimerkinomaisesti, mutta esimerkin spekseistä päätellen voisi olla vaikka Zen4 EPYC kyseessä.
(Voihan tuo olla joku Intelinkin tuleva Xeon olla, mutta taitavatko kuitenkaan saada sellaisia siruja kovin nopeasti markkinoille).

Micron Drives DDR5 Adoption With Technology Enablement Program - VideoCardz.com

BOISE, Idaho, July 14, 2020 (GLOBE NEWSWIRE) — Micron Technology, Inc. (Nasdaq: MU), today announced a comprehensive enablement program which will provide early access to technical resources, products and ecosystem partners. The Technology Enablement Program will aid in the design, development...

videocardz.com

 

[Kaotik]

Mihinkähän prosessoriin viitataan tässä Micronin DDR5-pressissä?
Tokihan tässä on esitelty DDR5-ominaisuuksia vain erimerkinomaisesti, mutta esimerkin spekseistä päätellen voisi olla vaikka Zen4 EPYC kyseessä.
(Voihan tuo olla joku Intelinkin tuleva Xeon olla, mutta taitavatko kuitenkaan saada sellaisia siruja kovin nopeasti markkinoille).

Se on nimenomaan vain esimerkki. Toki epäilemättä Zen 4:stäkin tulee 64-ydin versio eli sikäli osuu varmasti siihen(kin), jos vain tukee DDR5-4800-nopeutta.
Intelin odotetaan julkaisevan Sapphire Rapidsin DDR5-tuella ennen kuin AMD julkaisee Zen 4:n, mutta siitä ei sen tarkempia tietoja juuri ole.

 

[JiiPee]

Se on nimenomaan vain esimerkki. Toki epäilemättä Zen 4:stäkin tulee 64-ydin versio eli sikäli osuu varmasti siihen(kin), jos vain tukee DDR5-4800-nopeutta.
Intelin odotetaan julkaisevan Sapphire Rapidsin DDR5-tuella ennen kuin AMD julkaisee Zen 4:n, mutta siitä ei sen tarkempia tietoja juuri ole.

AMD voi halutessaan tuoda DDR5 tuen melko helposti vaikka Zen 3. Eihän se vaadi kuin uuden IO-piirin ja sitten alkaa painaa DDR4 ja DDR5 SKU:ta rinnakkain ulos. Eiköhän se tuonne datacenter puolelle saada melko nopeasti tuotua jos asiakkaat sitä hinkuaa.

 

[El eks]

AMD voi halutessaan tuoda DDR5 tuen melko helposti vaikka Zen 3. Eihän se vaadi kuin uuden IO-piirin ja sitten alkaa painaa DDR4 ja DDR5 SKU:ta rinnakkain ulos. Eiköhän se tuonne datacenter puolelle saada melko nopeasti tuotua jos asiakkaat sitä hinkuaa.

Kuinka helppoa se todellisuudessa on ? Sieltä tuli Pro , miten jos tuohon vaihdetaan muistiohjaimet , ne on erillisinä palikoina > DDR5
Kestääkö nykyinen IO piiri vai meneekö täysin uusiksi , jos fiilaus riittää se on helppoa ja nopeaa ja voidaan odottaa jotain OEM prossua vielä ennen ZEN4 sarjaa.
Joka tapauksessas valmistajat joutuvat tekemään erillistestit muistivaihdon yhteydessä

Toinen juttu on tuo Lenovo ThinkStatio 620 emolevy
Se lienee yksittäiskappale jonka pitää sopia sarjan kaikille prossuille
Eli siellä on jumalattomat virransyötöt ja hirmuiset layer kerrokset johdotuksille

Muutama sivu takaperin veikattiin mitä tulee , tämä julkaisu tuskin tyydyttää kaikkia
Eli mitä vielä tulee
Eka DDR5 ihmevehje ?

 

[demu]

Kuinka helppoa se todellisuudessa on ? Sieltä tuli Pro , miten jos tuohon vaihdetaan muistiohjaimet , ne on erillisinä palikoina > DDR5
Kestääkö nykyinen IO piiri vai meneekö täysin uusiksi , jos fiilaus riittää se on helppoa ja nopeaa ja voidaan odottaa jotain OEM prossua vielä ennen ZEN4 sarjaa.
Joka tapauksessas valmistajat joutuvat tekemään erillistestit muistivaihdon yhteydessä

Toinen juttu on tuo Lenovo ThinkStatio 620 emolevy
Se lienee yksittäiskappale jonka pitää sopia sarjan kaikille prossuille
Eli siellä on jumalattomat virransyötöt ja hirmuiset layer kerrokset johdotuksille

Muutama sivu takaperin veikattiin mitä tulee , tämä julkaisu tuskin tyydyttää kaikkia
Eli mitä vielä tulee
Eka DDR5 ihmevehje ?

Nuo kaikki Threadripper PRO:t kuluttavat maksimissaan 280W, eli saman kuin perus TR:t.
Perus-TR-levyillä varaudutaan ylikellotuksiin, jonka vuoksi 64-coreisille on päivitetty virransyöttöboostattuja emoja aivan erikseen.
Pro-malleissa tuskin loppukäyttäjälle annetaan nestetyppimoodeja tarjolle, joten yksi ja sama emolevy riittää kaikille malleille.

 

[SatanTwister]

TDP ei ole edelleenkään sama kuin tehontarve.. TDP on laskettu jollain valmistajan höpöhöpö kaavalla.

 

[Sami Riitaoja]

Se on nimenomaan vain esimerkki. Toki epäilemättä Zen 4:stäkin tulee 64-ydin versio eli sikäli osuu varmasti siihen(kin), jos vain tukee DDR5-4800-nopeutta.
Intelin odotetaan julkaisevan Sapphire Rapidsin DDR5-tuella ennen kuin AMD julkaisee Zen 4:n, mutta siitä ei sen tarkempia tietoja juuri ole.

Esimerkissä on monoliittinen 64-ytiminen piiri, eli siis melko varmasti kyse jostain ARM-tuotteesta koska 64-ytimisiä monoliittisiä x86-piirejä ei ole tiettävästi tulossa sen puoleen Inteliltä kuin AMD:ltäkään vielä pitkään aikaan.

 

[Tepe]

Missä 20% on huhuttu?

Itse olen nähnyt lähinnä spekulaatioita ja ne asettuvat sinne 10% tietämille, siihen maltilliset kellonousut sitten vielä päälle.

En sano, etteikö sieltä jytkyä voi tulla, mutta pidän epätodennäköisenä.

AdoredTV on spekuloinut Zen3-suorituskyvyllä (kohdasta 12:50 alkaen).
"Hyvin luotetun lähteen" mukaan peräti +20% yhden säikeen kokonaislukusuorituskykyyn, mutta kaikki ytimet täysillä paahtaessa ero pienenee tasolle +10-15%.

Spekuloidaan nyt sillä, että sisäpiirin lähteet olisivat tällä kerralla oikeassa.

Ei oikein mitään muuta keinoa jää jäljelle toteuttaa noin isoa hyppäystä kuin alentaa usein käytettyjen käskyjen latensseja. Tämähän on jo kerran toteutettu Pentium 4:ssä tuplanopeus-ALUjen muodossa. Siitä on sopivasti 20 vuotta, eli patentit ovat umpeutuneet tai umpeutumassa. Tuolloin niiden suorituskykyetu jäi muiden hyvin kyseenalaisten arkkitehtuuriratkaisujen varjoon.

Transistorien suuri virrankulutus oli silloin ongelma ja niin epäilemättä nytkin. Intel ei nykyään ole tuota ottanut käyttöön, koska mobiili- ja serveripuolen on oltava energiatehokkaita. AMD:llä on kuitenkin erittäin hyvä dynaaminen tehonhallinta, joten se voisi ehkä tuosta jonkinlaisen rajatun toteutuksen ottaa käyttöön?

 

[Tembez91]

AMD vahvistanut, että Zen3 kuluttajaprosessorit tulevat tänä vuonna.

AMD varmisti Zen 3 -kuluttajaprosessorin julkaisun tapahtuvan tänä vuonna - io-tech.fi

Netissä on spekuloitu koskeeko AMD:n lupaukset Zen 3:n julkaisusta tänä vuonna vain itse arkkitehtuuria ja palvelinsiruja, mutta tuoreen lausunnon mukaan myös kuluttajaprosessori ehtii kuluvalle vuodelle.

www.io-tech.fi

 

[hkultala]

AdoredTV on spekuloinut Zen3-suorituskyvyllä (kohdasta 12:50 alkaen).
"Hyvin luotetun lähteen" mukaan peräti +20% yhden säikeen kokonaislukusuorituskykyyn, mutta kaikki ytimet täysillä paahtaessa ero pienenee tasolle +10-15%.

AdoredTV nyt höpisee aina mitä sattuu.

~20% nopeutus saadaan ehkä muutamalla sellaisella softalla, joiden aktiivinen datasetti osuu juuri 16 megan ja 32 megan välille siten että ne hyötyvät maksimaalisesti yhden ytimen käytössä olevan L3-välimuistin koon kasvattamisesta. Keskimääräinen nopeutus onkin sitten selvästi alempana.

Spekuloidaan nyt sillä, että sisäpiirin lähteet olisivat tällä kerralla oikeassa.
Ei oikein mitään muuta keinoa jää jäljelle toteuttaa noin isoa hyppäystä kuin alentaa usein käytettyjen käskyjen latensseja.

Ei. Se on nimenomaan keino, jolla sellaista ei saada aikaan, koska varaa tähän ei yksinkertaisesti ole (absoluuttisessa ajassa mitattuna).

Tämähän on jo kerran toteutettu Pentium 4:ssä tuplanopeus-ALUjen muodossa. Siitä on sopivasti 20 vuotta, eli patentit ovat umpeutuneet tai umpeutumassa. Tuolloin niiden suorituskykyetu jäi muiden hyvin kyseenalaisten arkkitehtuuriratkaisujen varjoon.

EI niitä ALUja voi vaan kellottaa nopeammiksi kuin mihin niiden viivet antaa myöten.

Willamette- ja Northwood-P4sten tuplanopeus-ALUt perustuivat ratkaisuun, jossa ylimmät bitit laskettiin puoli kellojaksoa myöhemmin kuin alimmat bitit, ja flagit vielä kokonaisen kellojakson myöhemmin kuin alimmat bitit. Mutta sitten kun pitäisikin tehdä vaikka shiftaus alaspäin, ei tämä toimi, kun alempien bittien laskemiseen tarvitaan ylempiä bittejä. Tämän takia Pentium 4ssa mm. shiftausta ei ollut toteutettu nopeissa ALUIssa vaan hitaissa ALUIssa, ja datansiirto hitaiden ja nopeiden ALUjen välillä maksoi pari kellojaksoa ylimääräistä (eli oli siis todella hidasta)

P4n nopeiden ALUjen tarkoitus oli lähinnä että data kiertää nopeasti esim. välillä:

1) meillä on pointteri
2) pointteriin lasketaan yhteen offsetti ja tämän tuloksen perusteella tehdään muistihaku.
3) ladattua arvoa voidaan käyttää uudestaan pointterina ja palata kohtaan 1.

Muistihaussa P4n hyvin yksinkertaisella L1D-välimuistilla alimmat bitit riittivät siihen, että tiedetään mistä kohtaa L1D-kakkua pitää indeksoida, joten nopeat ALUt sopivat tähän.

Mutta tosiaan, kun Willamettellä/Northwoodilla teki mitä tahansa muuta kuin ajoi koodia, joka pyöri pelkästään nopeilla ALUIlla, se kävi hyvin hitaaksi.

Intel luopui nopeista ALUista jo viimeisessä P4-versiossa Prescottissa, koska niistä oli enemmän haittaa kuin hyötyä, ja lisäksi ilmeisesti niiden totetuttaminen 64-bittisenä olisi syönyt kellotaajuutta.


Mutta jos mietitään miten nykyisistä prossuista voisi viiveitä järkesti pienentää,. niin:

Yhteenlasku, shiftaukset ja loogiset operaatiot suoritetaan yhdessä kellojaksossa, niissä ei ole järkevää parannettavaa( P4-tyyppiset nopeast ALUta vaan ei ole järkevä vaihtoehto)
L1-välimuistin viive on 4-5 kellojaksoa ja sen saaminen nopeammaksi (jos osumatarkkuus pysyisi samana) auttaisi kyllä saamana paremman IPCn, mutta sen nopeuttamiseen ei ole järkeviä edellytyksiä ilman että siitä samalla tehtäsiiin osumatarkkuudeltaan paljon huonompi.

Kokonaislukukertolaskulla on sitten n. 3 kellojakson viive ja jakolaskulla vielä paljon pidempi, mutta jakolaksu on hyvin harvinainen operaatio ja 64-bittistä kertolaskua on vaikea saada alle 3 kellojaksoon nykyisillä kellotaajuuksilla.


Suuria keskimääräisiä IPC-parannuksia ei enää saada millään yksittäisellä asialla vaan sillä, että tehdään suuri määrä erillisiä 0.5-2 % parannuksia.

Keksitään uusi haarautumisenennustusalgoritmi. Viilataan jotain ennen pullonkaulana ollutta puskuria n. 10% suuremmaksi. Mahdollistetaan jonkun ennen vain yhdessä ALUssa suoritetun käskun suorittaminen kahdessa eri ALUss . Mahdollistetaan useamman käskyn hakeminen yhtä aikaa micro-op-välimuistista ja useamman käskyn yhtäaikainen rekisterien uudelleennimeäminen. Kasvatetaan TLBtä sen osumatarkkuuden parantamiseksi. Lisätään uloimman tason välimuistin kokoa. Tehdään kunnollinen nopea rautaimplementaatio jostain harvoin käytetystä käskystä, joka aiemmin suoritettiin mikrokoodilla, tai korjataan joku rautabugi jonka mikrokoodilla toteutettu kierto hidasti jotain käskyä/joitain käskyjä. Viilataan muistin prefetcheriä. Optimoidaan välimuistien välisiä dataväyliä ja onnistutaan tällä tällä saamaan L2-välimuistin viiveestä kellojakso pois.

Toisaalta, voidaan myös pienentää jotain puskuria jos sen koko ei käytännössä koskaan ole pullonkaula ja tämän puskurin pienentäminen auttaa joko suurentamaan jotain muuta tai saavuttamaan 1% suuremman kellotaajuuden.

Jos yritetään tehdä mitä tahansa "yksittäistä suurta parannusta", sillä on aina tradeoffinsa; Laskentayksiköiden lisäämisestä hyödytään melko vähän koska softissa ei vaan riitä rinnakkaisuutta, mutta leveämpi ydin on haastavampi saada kellottumaan yhtä korkealle. Se, että yritetään pudottaa viiveitä sattuu vielä helpommin kellotaajuuteen. Välimuistin kasvattaminen taas helposti hidastaa sitä, jolloin pitää lisätä viiveitä tai hyväksyä alempi kellotaajuus.

Transistorien suuri virrankulutus oli silloin ongelma ja niin epäilemättä nytkin. Intel ei nykyään ole tuota ottanut käyttöön, koska mobiili- ja serveripuolen on oltava energiatehokkaita. AMD:llä on kuitenkin erittäin hyvä dynaaminen tehonhallinta, joten se voisi ehkä tuosta jonkinlaisen rajatun toteutuksen ottaa käyttöön?

Ei. P4n huono energiatehokkuus johtui pääasiassa muista asioista kuin nopeista ALUista; Se johtui mm. seuraavista asioista
1) sen liukuhihna oli niin pitkä, että sen käskyskedulerikin piti liukuhihnoittaa siten että se skeduloi käskyjä tietämättä, saako niitä vielä skeduloida, ja mikäli ei saanut (esim. koska käsky tarvi dataa joka tuli lataukselta jolla tulikin välimuistihuti), käsky suoritettiin sitten myöhemmin uudestaan => samojen käskyjen suorittaminen moneen kertaan haaskasi paljon sähköä
2a) sen L1D-kakku oli write-through-tyyppiä eli heti kun sinne kirjoitettiin mitä tahansa, se flushasi ne L2-kakkuun
2b) sen L1D-kakku oli muutenkin niin pieni, että dataa piti jatkuvasti hakea L2-kakusta asti
2=2a+2b) paljon lisää liikennettä välimuistien välillä, ja datansiirrot tuhlaa aina sähköä
3) P4ssa oli melko agressiivinen prefetcheri joka haki dataa L2-välimuistiin melko aggressiivisesti. Prefeetcheirn tekemät musitihaut kuluttivat huomattavasti virtaa.

 

[Tepe]

Intel luopui nopeista ALUista jo viimeisessä P4-versiossa Prescottissa, koska niistä oli enemmän haittaa kuin hyötyä, ja lisäksi ilmeisesti niiden totetuttaminen 64-bittisenä olisi syönyt kellotaajuutta.

No, yhtiön virallinen linja oli vielä Prescottia suunniteltaessa kilpajuoksu 10 GHz:iin, joten ehkä ominaisuus poistettiin jo ennen kuin sen rajat olisivat todella tulleet vastaan?

Yhteenlasku, shiftaukset ja loogiset operaatiot suoritetaan yhdessä kellojaksossa, niissä ei ole järkevää parannettavaa( P4-tyyppiset nopeast ALUta vaan ei ole järkevä vaihtoehto)

Kaupan hyllyllä on jo kerran ollut myynnissä 3,4 GHz taajuudella toimiva prosessori, joka suoritti yhteenlaskun puolessa kellojaksossa, tai tarkemmin, kaksi toisistaan riippuvaista yhteenlaskua yhdessä kellojaksossa. Suuri osa koodista ei enää hyödy rinnakkaistamisen lisäämisestä, joten on nopeutettava sarjamuotoisen koodin suorittamista.

Willamette- ja Northwood-P4sten tuplanopeus-ALUt perustuivat ratkaisuun, jossa ylimmät bitit laskettiin puoli kellojaksoa myöhemmin kuin alimmat bitit, ja flagit vielä kokonaisen kellojakson myöhemmin kuin alimmat bitit. Mutta sitten kun pitäisikin tehdä vaikka shiftaus alaspäin, ei tämä toimi, kun alempien bittien laskemiseen tarvitaan ylempiä bittejä.

Aina voidaan jakaa summain kahteen osaan, jossa ensin lasketaan alempi osa ja saadaan ulos carry-bitti, viedään se ylempään osaan ja lasketaan se.

Jos taas halutaan lisää nopeutta, niin sitten on laskettava kolme asiaa samaan aikaan; alempi osa, ylempi osa ilman carry-bittiä, ylempi osa carry-bitin kanssa. Lopuksi on vielä yhdistettävä tulokset.

Varmasti yhteenlasku on nykyisissä suorittimissa toteutettu optimaalisesti transistorien määrän ja virrankulutuksen suhteen, mutta jos se olisi toteutettu epäoptimaalisesti, kuinka paljon lisänopeutta saataisiin ulos? Sitähän tässä spekuloidaan.

 

[hkultala]

No, yhtiön virallinen linja oli vielä Prescottia suunniteltaessa kilpajuoksu 10 GHz:iin, joten ehkä ominaisuus poistettiin jo ennen kuin sen rajat olisivat todella tulleet vastaan?

Se aiheutti jo Willamettessä suuria suorituskykyongelmia siinä, että shiftaukset olivat hyvin hitaita. Se oli aina suorituskykyongelma.

Kaupan hyllyllä on jo kerran ollut myynnissä 3,4 GHz taajuudella toimiva prosessori, joka suoritti yhteenlaskun puolessa kellojaksossa, tai tarkemmin, kaksi toisistaan riippuvaista yhteenlaskua yhdessä kellojaksossa. Suuri osa koodista ei enää hyödy rinnakkaistamisen lisäämisestä, joten on nopeutettava sarjamuotoisen koodin suorittamista.

Tosimaailman koodi sisältää paljon muutakin kuin peräkkäisiä yhteenlaskuja ja loogisia operaatiota.

Se, että nopeutetaan pelkkiä yhteenlaskuja sekä loogisia operaatioita ja hidastetaan paljon suuremmalla kertoimella suurta osaa muista käskyistä muuta ei johda nopeampaan vaan hitaampaan prosessoriin.

Aina voidaan jakaa summain kahteen osaan, jossa ensin lasketaan alempi osa ja saadaan ulos carry-bitti, viedään se ylempään osaan ja lasketaan se.

Voidaan, muttei kannata, koska se hidastaa muita käskyjä liikaa. MInkä takia siitä luovuttiin jo Presscottissa.

Kun sitten ollaan ongelmissa kun niitä ylimpiä bittejä tarvitaan ennen tai yhtä aikaa kuin alimpia bittejä. Eli heti, kun tehdään mitään muuta kuin yhteen- ja vähennyslaskuja ja loogisia operaatiota.

Latausten suhteen tilanne on se, että P4n hyvin yksinkertaisella (ja todella huonon osumatarkkuuden omaavalla) L1D:llä niitä ylimpiä bittejä ei tarvittu heti välimuistin indeksointiin, joten yhteenlaskulta/osoitteenlaskulta saatiin osoite välimuistin indeksointiin nopeasti ilman ylimpiä bittejä, mutta jos L1D-kakusta halutaan suorituskyvyltään järkevä (hyvä osumatarkkuus ilman aivan järkyttävää virrankulutusta), se tarvii heti myös niitä ylimpiä bittejä (esim. Zen käyttää niitä way predictioniin, ja ilman way predictionia 8-way-L1D-välimuisti kuluttaisi järkyttävästi virtaa).

Ja kun niitä ylimpiä bittejä tarvitaan, siitä ei tule vain sitä puolen kellojakson viivettä vaan paljon enemmän, kun pitää parsia luku kokoon monesta osasta ja bypassaaminen käytännössä hajoaa tähän.

Käytännössä saadaan pari kellojaksoa ylimääräisiä viiveitä datan siirtelyyn paikasta toiseen.

Eli siis, sekin tilanne mihin P4n nopeat ALUt optimoitiin eli pointer -> yhteenlasku -> lataus -> pointer-looppikin vaan hidastuu niistä nopeista ALUista jos L1D-välimuisti on "kunnollinen".

Jos taas halutaan lisää nopeutta, niin sitten on laskettava kolme asiaa samaan aikaan; alempi osa, ylempi osa ilman carry-bittiä, ylempi osa carry-bitin kanssa. Lopuksi on vielä yhdistettävä tulokset.

Juuri näin P4 teki, ja se teki datansiirrosta prosessorin eri laskentayksiköiden välillä todella hidasta.

Varmasti yhteenlasku on nykyisissä suorittimissa toteutettu optimaalisesti transistorien määrän ja virrankulutuksen suhteen, mutta jos se olisi toteutettu epäoptimaalisesti, kuinka paljon lisänopeutta saataisiin ulos? Sitähän tässä spekuloidaan.

Kuten jo pariin kerttaan olen sanonut, tosimaailman ohjelmat eivät laske pelkkiä yhteenlaskuja ja loogisia operaatioita

Data pitää pystyä bypassaamaan ilman ylimääräisiä viiveitä käskyiltä toisille, ja pitää suorittaa ne käskysekvenssit mitä tosimaailman koodissa on mahdollisimman nopeasti.

 

[Tepe]

Se aiheutti jo Willamettessä suuria suorituskykyongelmia siinä, että shiftaukset olivat hyvin hitaita. Se oli aina suorituskykyongelma.

Se, että nopeutetaan pelkkiä yhteenlaskuja sekä loogisia operaatioita ja hidastetaan paljon suuremmalla kertoimella suurta osaa muista käskyistä muuta ei johda nopeampaan vaan hitaampaan prosessoriin.

Nopeiden ALU:jen ja hitaiden bitinsiirtojen yhdistelmä oli kyllä sikäli hankala, että montaakaan järkevää nopeaa algoritmia ei niistä saanut aikaiseksi. Mielestäni nämä kaksi asiaa eivät kuitenkaan liity yhteen. Muistan lukeneeni huhun, että Willametten transistoribudjetti paukkui kehitysvaiheessa ja erilliselle bitinsiirtoyksikölle ei jäänyt tilaa. Bitinsiirrot oli sitten toteutettava samassa yksikössä kuin SIMD-siirrot, mikä tietysti vei aikaa. Tätä ei korjattu prosessipäivityksen yhteydessä, koska liukuhihnaan ei haluttu kajota - "Nyt se toimii, ei kosketa".

Juuri näin P4 teki, ja se teki datansiirrosta prosessorin eri laskentayksiköiden välillä todella hidasta.

Ei kannata tehdä laskentayksikköä, joka on erittäin nopea, mutta josta ei saada dataa nopeasti ulos.

Perusajatuksenahan on, että tehtävän jakaminen kahteen osaan, suorittaminen yhtäaikaa ja tulosten yhdistäminen on nopeampaa kuin osien suorittaminen peräkkäin. Tätä voidaan sitten soveltaa rekursiivisesti niin kauan kuin se pitää paikkansa. Eli enemmän transistoreja -> nopeampi yksikkö. Jos mikään sen yksittäinen osa ei ole hitaampi kuin ennen, on vaikea nähdä, miten se hidastaisi muiden yksiköiden toimintaa.

Kuten jo pariin kerttaan olen sanonut, tosimaailman ohjelmat eivät laske pelkkiä yhteenlaskuja ja loogisia operaatioita

Totta kai Zen3:een voi tehdä monia parannuksia, mutta yllä olleisiin varsin niukkoihin vihjeisiin perustuen ehdottamani voisi hyvin olla yksi niistä. Vanhojen prosessorien virheitä ei ole pakko toistaa.

 

[hkultala]

Nopeiden ALU:jen ja hitaiden bitinsiirtojen yhdistelmä oli kyllä sikäli hankala, että montaakaan järkevää nopeaa algoritmia ei niistä saanut aikaiseksi. Mielestäni nämä kaksi asiaa eivät kuitenkaan liity yhteen. Muistan lukeneeni huhun, että Willametten transistoribudjetti paukkui kehitysvaiheessa ja erilliselle bitinsiirtoyksikölle ei jäänyt tilaa.

Bittien shiftaaminen alaspäin (oikealle) ei vaan absoluuttisesti millään onnistu jos niitä shiftattavia bittejä ei ole vielä laskettu. Sama pätee rotateen

Ei ole mitään keinoa toteuttaa shiftausta alaspäin eikä rotatea nopeissa ALUissa ilman aikakonetta

Shiftauksen ylöspäin (vasemmalle) tosiaan voisi nopeissa ALUissa teoriassa toteuttaa.

Bitinsiirrot oli sitten toteutettava samassa yksikössä kuin SIMD-siirrot, mikä tietysti vei aikaa. Tätä ei korjattu prosessipäivityksen yhteydessä, koska liukuhihnaan ei haluttu kajota - "Nyt se toimii, ei kosketa".

Ei, vaan se toteutettiin skalaaripuolen hitaassa ALUssa. Tällä ei ollut mitään tekemistä SIMDin kanssa.

Eikä tähän ollut mitään "yksinkertaista korjausta". Jos pelkät ylöspäinshiftaukset olisi siirretty nopeisiin ALUihin, sitten olisi tarvittu erilliset yksiköt rotatelle, ja toisaalta hyvin yleiset koodisekvenssit joissa nollataan/sign-extendataan bittejä kahdella peräkkäisellä eri suuntaan menevällä shiftillä olisi ollut hitaita.

Ei kannata tehdä laskentayksikköä, joka on erittäin nopea, mutta josta ei saada dataa nopeasti ulos.

Tätä olen yrittänyt sinulle koko ajan selittää!

Se, että voidaan pari yhteenlaskua nopeammin on täysin turhaa kun siinä vaiheessa kun niillä tuloksilla yritetään tehdä jotain tulee vaan suurempi hidastus.

Perusajatuksenahan on, että tehtävän jakaminen kahteen osaan, suorittaminen yhtäaikaa ja tulosten yhdistäminen on nopeampaa kuin osien suorittaminen peräkkäin. Tätä voidaan sitten soveltaa rekursiivisesti niin kauan kuin se pitää paikkansa. Eli enemmän transistoreja -> nopeampi yksikkö. Jos mikään sen yksittäinen osa ei ole hitaampi kuin ennen, on vaikea nähdä, miten se hidastaisi muiden yksiköiden toimintaa.

No shit, sherlock. Kaikki modernit ALUt tekevät tätä sisäisesti. Suosittelen tutustumaan siihen, miten ne laskentayksiköt on nykyään totetutettu. Siellä ei todellakaan ole mitään ripple-carry-adderiä laskemassa kaikkea täysin sekventiaalisesti peräkkäin.

Carry-lookahead adder - Wikipedia

en.wikipedia.org

Asia, mitä tässä ehdotat suurena parannuksena on ollut arkipäivää jo n. 30 vuotta.



Ja tunnut nyt olevan muutenkin melko pihalla siitä, miten prosessori on sisäisesti organisoitu.

Käskyille on määritelty, että niiden operandit tulee pääosin rekistereistä, jotka on hyvin nopeita tilapäismuistipaikkoja koneen sisällä. Lisäksi joku parametri voi tulla myös vakiona käskyssä, ja x86lla myös muistista(mutta tällöinkin muistiosoite luetaan rekisteristä).

Kun käsky on suoritettu, se tulos pitää tallettaa sinne kohderekisteriin. Ja seuraava käsky sitten lukee sen sieltä. Mutta tämä datan kierrättäminen aina sen rekisterin kautta olisi hidasta, joten viimeiset n. 35 vuotta prosessorit ovat tukeneet datan bypassaystä, eli että data välitetäänkin suoraan sen tuottavan yksikön tulokselta sitä käyttävälle käskylle. Tämän toteuttaminen vaatii 1) monimutkaisen logiikan joka analysoi käskyjen lähde- ja kohderekistereitä 2) paljon ylimääräisiä (hyvin nopeita) dataväyliä joilla tämä siirto voidaan tehdä.

Bypassays on helposti mahdollista vain, kun se tulos valmistuu tasan juuri ennen kun sitä tarvitaan, liian aikaisin valmistunut tulos ylikirjoittuu sitä seuraavan käskyn tuloksella.

Jos yritetään bypassata arvoa jonka ylimmät bitit valmistuu aiemmin kuin sen alimmat bitit käskylle, joka tarvitsee niitä ylimpiä bittejä ensin tai yhtä aikaa, meillä on ongelma: Jos bypassataan koko luku kerralla sitten kun ylimmät bitit on laskettu, seuraava käsky on voinut jo ylikirjoittaa ne alimmat bitit tuottamallaan arvolla.
ELi tarvittaisiin väliin joku rekisteri pitämään alimpien bittien arvon, ja logiikka jolla lasketaan, koska data on saatavilla ja mitä voidaan bypassata ja mitä ei, menee paljon monimutkaisemmaksi.

Ja lisäksi, sen datan pitää ehtiä valua sieltä tuottavalta laskentayksiköltä sitä käyttävälle. Käskyjen viiveessä ei ole kyse pelkästään sen itse ALUn viiveestä vaan myös niisät datansiirron viiveistä, joita pitää sen ALUn lisäksi tehdä sen datan saamiseksi tuottavalta operaatiolta kuluttavalle operaatiolle.

Pentium 4n nopeita ALUja oli vain 2 kpl, ja siellä oli bypassing toteutettu vain niiden sisäisesti sekä niiden ja latausyksikön välillä, eli tuplanopeudella tarvi toimia vain melko pieni määrä bypass-yhteyksiä; Ja jos nopean ALUn tuottamaa dataa käytti käsky joka suoritettiin hitaiden ALUjen puolella, sitten se ei saanut arvoaan bypassilla vaan lukien sen ihan sieltä rekisteristä.

Vaikka ALUt olisi kuinka nopeita, ei niiden välillekään saataisi leveämmällä prosessorilla sitä puolen kellojakson efektiivistä viivettä käytännössä millään kuin se puoli kellojaksoa kuluisi useamman laskentayksikön kanssa helposti melkein siihen pelkkään datan reititykseen laskentayksikössä toiselle.

Ja se, että siellä olisi samassa bypass-verkossa dataa josta osassa ylimmät bitit on samassa vaiheessa alimpien bittein kanssa ja osasssa ylimmät bitit on eri vaiheessa vaan monimutkaistaisi tilannetta paljon ja tekisi bupass-verkosta paljon ongelmallisemman.

Pentium 4 pystyi toteuttamaan ne "nopeat ALUt" juuri sen takia, että ne teki niin vähän. Mitä enemmän kamaa sinne "nopeisiin ALuihin" yritettäisiin laittaa, sitä mahdottomammaksi ne menee.

Totta kai Zen3:een voi tehdä monia parannuksia, mutta yllä olleisiin varsin niukkoihin vihjeisiin perustuen ehdottamani voisi hyvin olla yksi niistä. Vanhojen prosessorien virheitä ei ole pakko toistaa.

"Tuplanopeat ALUt" ei ole mikään irrallinen asia jonka voi vaan bullet pointtina liimata johonkin kylkeen, vaan se oli syvällä P4ssa oleva asia, jonka hyödyt olivat hyvin pienet mutta joka pakotti sen olemaan hidas monella muulla tavalla. Ja ei, näihin ei ole mitään maagisia "tehdään vaan vähän paremmin"-ratkaisuita.

Yhteenlaskun yhden kellojakson viive on käytännössä nimenomaan juuri se asia, minkä yrittämisessä parantaa on kaikkein vähiten järkeä nykyaikaisessa CPUssa.

 

[Tepe]

Bittien shiftaaminen alaspäin (oikealle) ei vaan absoluuttisesti millään onnistu jos niitä shiftattavia bittejä ei ole vielä laskettu. Sama pätee rotateen

Ei ole mitään keinoa toteuttaa shiftausta alaspäin eikä rotatea nopeissa ALUissa ilman aikakonetta

Olen pyrkinyt pitämään asiat yksinkertaisina, enkä ehdottamaan mitään sellaista, jota alkuperäisessä toteutuksessakaan ei ollut, kuten bitinsiirtoja. Minulle riittäisi saavutettavaksi parannukseksi se, että saadaan laskettua a+b+c yhden kellojakson latenssilla. Pienikin matalan tason parannus nopeuttaisi käytännössä kaikkea koodia.

No shit, sherlock. Kaikki modernit ALUt tekevät tätä sisäisesti. Suosittelen tutustumaan siihen, miten ne laskentayksiköt on nykyään totetutettu. Siellä ei todellakaan ole mitään ripple-carry-adderiä laskemassa kaikkea täysin sekventiaalisesti peräkkäin.

Totta kai käytännön nopeissa toteutuksissa on käytössä kaikki yhteenlaskun nopeutuskeinot - aina siihen pisteeseen saakka että lasku pystytään tekemään yhden kellojakson aikana ja sen jälkeen vain säästellään transistoreita/sähköä. Mutta riittävätkö käyttöön otettavissa olevat keinot siihen, että pystytään tekemään kaksi laskua?

 

[hkultala]

Olen pyrkinyt pitämään asiat yksinkertaisina, enkä ehdottamaan mitään sellaista, jota alkuperäisessä toteutuksessakaan ei ollut, kuten bitinsiirtoja. Minulle riittäisi saavutettavaksi parannukseksi se, että saadaan laskettua a+b+c yhden kellojakson latenssilla.

Ehdottamallasi P4-tyyppilsillä nopeilla ALUIlla ei saada tehtyä tätä. Sillä saadaan laskettua ainoastaan a+b+c:n alimmat bitit yhden kellojakson latenssilla.

Ja ne alimmat bitit yksinään on käyttökelpoisia ainoastaan jos ne jälleen menee kolmannelle yhteen-/vähennyslaskulle, vertailulle tai loogiselle operaatiolle (tai teoriassa myös vasemmalle shiftaukselle). Tai todella huonon L1D-kakun indeksointiin.

Jos sitä dataa tarvitaan mihinkään muuhun, sillä on vähintään kahden kellojakson viive koska joudutaan odottelemaan niitä ylimpiä bittejä.
Ja käytännössä se viive on vielä suurempi kuin kaksi kellojaksoa koska ei sitä ei voida järkevästi bypassatä vaan kuluu vähintään kellojakso lisää sen kiertämiseen rekisterifileen kautta.

Pienikin matalan tason parannus nopeuttaisi käytännössä kaikkea koodia.

Ei, jos se tarkoittaa että sen takia muita asioita pitää hidastaa paljon enemmän.


Ja takaisin tuohon esimerkkiisi ohjelmasta joka laskee vain a+b+c mutta ei tee mitään muuta:

Mikäli yksikin näistä a:sta, b:stä tai c:stä on pienehkö vakio, sen voi jo nyky-zenillä laskea LEA-käskyllä yhden kellojakson viiveellä.

Ja LEA-käskytllä nyky-zen pystyy laskemaan sen kaikki bitit sillä yhden kellojakson viiveellä. Siten että se on oikeasti käytettävissä kaikentyyppisille kokonaislukukäskyille seuraavalla kellojaksolla.


Jos taas kaikki tulee muuttujista, käytännössä melkein aina joku niistä on kriittisellä polulla, ne eivät kaikki valmistu yhtä aikaa.

Jos kääntäjällä on yhtään hajua siitä, mikä näistä todennäköisesti valmistuu viimeisenä, se järjestelee kodin siten, että ne kaksi aiemmin valmistunutta summataan ensin ja viimeisenä tuleva viimeisenä.

Eli jos C todennäköisesti valmistuu viimeisen, se tekee koodin (A+B) + C.
Jos taas A todennäköisesti valmistuu viimeisenä, se tekee koodin A + (B+C).

Ja tällöin viive sen viimeisenä valmistuvan parametrin suhteen on edelleen yksi kellojakso.

Mutta siten, että sen kaikki bitit on valmiina kellojakso sen viimeisen inputin valmistumisen jälkeen.

Totta kai käytännön nopeissa toteutuksissa on käytössä kaikki yhteenlaskun nopeutuskeinot - aina siihen pisteeseen saakka että lasku pystytään tekemään yhden kellojakson aikana ja sen jälkeen vain säästellään transistoreita/sähköä. Mutta riittävätkö käyttöön otettavissa olevat keinot siihen, että pystytään tekemään kaksi laskua?

Pystytään tekemään kolmen numeron yhteenlasku kellojaksossa kun niitä ei tehdä turhaan peräkkäin vaan natiivilla 3-inputtisella adderillä. Ja tämä pystytään tekemään myös suuremmalla kellotaajuudella kuin P4-tyyppisellä ratkaisulla ja kaikille biteille kun siihen ei tule datan ylimääräisestä bypassaamisesta tulevia viiveitä, kuten kahden erillisen "tuplanopean" käskyn tapauksessa tulee.

Mutta tämä vaatii oman käskynsä joka ottaa ne 3 inputtia sisään. X86ssa LEA-käskyllä voidaan tehdä tämä, kun yksi input on pienehkö vakio.


Edelleenkään et ole esittänyt mitään sellaista tosimaailman koodia joissa niistä P4-tyyppisistä nopeista ALUista olisi mitään hyötyä - kolmen rekistereistä löytyvän numeron yhteenlasku ignoraten täysin mitä sen tulokselle tehdään ei ole tosimaailman koodi, ja kun tässä käytännössä heti se seuraava käsky korkeita bittejä odotellessaan tyypillisesti hidastuu niin paljon että kokonaisuus onkin yleensä hitaampi.

Itse esitin sen P4ssa päteneen linkitetyn listan läpikäymisen, mutta se vaatii hyvin yksinkertaisen ja huonon L1D-välimuistin (jollainen P4ssa oli) että se toimii nopeasti. Se, että nykyprosessoreissa vaihdettaisiin L1D-kakku P4-tyyliseen että sen accessointiin ei tarvita osoitteen korkeita bittejä tarkoittaisi vaan suurta hidastusta sekä virrankulutuksen kasvua.


Olisiko nyt vaan aika myöntää, että "ideasi" perustui totaalisen puutteelliseen tietämykseen siitä, miten P4n "nopeat ALUt toimivat" ja mitä kaikkea vaikutusta niillä oli kaikkeeen muuhun prosessorilla, ja luopua sen tuputtamisesta?

 

[Tepe]

Ja ne alimmat bitit yksinään on käyttökelpoisia ainoastaan jos ne jälleen menee kolmannelle yhteen-/vähennyslaskulle, vertailulle tai loogiselle operaatiolle (tai teoriassa myös vasemmalle shiftaukselle). Tai todella huonon L1D-kakun indeksointiin.

Jos kääntäjällä on yhtään hajua siitä, mikä näistä todennäköisesti valmistuu viimeisenä, se järjestelee kodin siten, että ne kaksi aiemmin valmistunutta summataan ensin ja viimeisenä tuleva viimeisenä.

Tulkitset nyt turhan vastakohtaisesti näitä esimerkkejä. Ihan hyvin voit laittaa +-merkin paikalle jonkin muun merkin (&|^). Tuossa oli plus, koska rautatoteutuksen kannalta kaksi yhteenlaskua peräkkäin on haastavin. Käytännön koodissa joku noista on yleensä looginen operaatio. Tällöin ei voida myöskään suoritusjärjestystä vaihtaa.

Edelleenkään et ole esittänyt mitään sellaista tosimaailman koodia joissa niistä P4-tyyppisistä nopeista ALUista olisi mitään hyötyä - kolmen rekistereistä löytyvän numeron yhteenlasku ignoraten täysin mitä sen tulokselle tehdään ei ole tosimaailman koodi, ja kun tässä käytännössä heti se seuraava käsky korkeita bittejä odotellessaan tyypillisesti hidastuu niin paljon että kokonaisuus onkin yleensä hitaampi.

Tämä on spekulaatioketju, uskon että tässä ei tarvitse todistella että koodi toimii optimaalisella tavalla 20 vuotta vanhassa arkkitehtuurissa. Uudesta arkkitehtuurista emme sitten tiedäkään vielä paljon mitään, joten on hyvin vaikeaa osoittaa tietyn ratkaisun toimivuus/toimimattomuus siinä. Todennäköisesti siinä olisi kuitenkin vähemmän viiveitä kuin P4:ssä, mutta se olikin fyysisesti jättiläinen verrattuna nykyisiin ytimiin.

 

[hkultala]

Tulkitset nyt turhan vastakohtaisesti näitä esimerkkejä. Ihan hyvin voit laittaa +-merkin paikalle jonkin muun merkin (&|^). Tuossa oli plus, koska rautatoteutuksen kannalta kaksi yhteenlaskua peräkkäin on haastavin. Käytännön koodissa joku noista on yleensä looginen operaatio. Tällöin ei voida myöskään suoritusjärjestystä vaihtaa.

Vaikka kuinka vaihdetaan toinen loogiseksi operaatioksi, se koodi ei silti edelleenkään tee vielä yhtään mitään järkevää. Heti kun siihen otetaan mukaan se, minne se data niiden kahden operaation laskemisen jälkeen menee(että sillä saadaan tehtyä jotain järkevää), käytännössä aina tarvitaan ne ylimmät bitit ja se sinun väittämäsi etu katoaa (tai siis muuttuu haitaksi, koska se ylimpien bittien kanssa häsläys eri vaiheessa käytännössä estää bypassaamisen eli saadaan yksi kellojakso lisää siihen viiveeseen)

Softien suorituskyvyn pullonkaulat on aivan muualla kuin käskysekvensseissä jotka koostuvat pelkästään yhteen- ja vähennyslaskuista ja loogisista operaatiosta vaikka nämä ovatkin eniten suoritettuja käskyjä.

Tämä on spekulaatioketju, uskon että tässä ei tarvitse todistella että koodi toimii optimaalisella tavalla 20 vuotta vanhassa arkkitehtuurissa. Uudesta arkkitehtuurista emme sitten tiedäkään vielä paljon mitään, joten on hyvin vaikeaa osoittaa tietyn ratkaisun toimivuus/toimimattomuus siinä. Todennäköisesti siinä olisi kuitenkin vähemmän viiveitä kuin P4:ssä, mutta se olikin fyysisesti jättiläinen verrattuna nykyisiin ytimiin.

Se, mitä yksinkertaiset perusoperaatiot tarkoittavat ja mitä bittejä niiden laskemiseen tarvitaan ei ole muuttunut yhtään mihinkään.

Tässä on nyt käynyt hyvin selväksi, että hypettäessäsi P4-tyyppisiä nopeita ALUja et tiennyt, miten ne toimivat, ja mitkä niiden ongelmat olivat(vaan kuvittelit ongelmien olevan aivan muualla kuin missä ne todellisuudessa olivat). Nämä olen sinulle tämän jälkeen selittänyt. Sen sijaan että olisit ottanut opiksesi, jatkat jankuttamistasi ja ignoraat täysin ne ongelmat. Koska ihminen ei vaan voi myöntää olevansa väärässä.

Zen3n arkkitehtuurista tiedämme hyvin paljon hyvin suurella varmuudella:

Se tulee edelleen jossain määrin perustumaan zeniin, vaikka prosessorin CPUIDn perhenumeroa vaihdettiinkin, mutta muutokset tulevat olemaan suurempia kuin zen->zen2-välillä (samaa luokkaa kuin K8->Phenom-välillä, jolloin CPUIDn perhenumeroa myös vaihdettiin). Siinä tulee olemaan 32kiB-64 kiB kokoluokkaa (todennäköisemmin 32 kiB) oleva WB-tyyppinen L1D-kakku jossa jokaisen wayn koko on tasan 4 kiB, ja käytössä on virran säästämiseksi way prediction, joka todennäköisesti toimii virtuaaliosoitteilla. Siinä tulee olemaan vähintään neljä kokonaisluku-ALUa, vähintään kaksi latausyksikköä ja vähintään yksi tallennusyksikkö. Se perustuu PRF-tyyppiselle OoOE-enginelle. Siinä tulee olemaan L0I-mikrokoodivälimuisti, jonka koosta ei ole tietoa. Se tulee tukemaan ainakin kahden säikeen SMTtä. Jokaisella ytimellä on oma L2-välimuistinsa, ja (maksimissaan) kahdeksan ydintä jakaa keskenään L3-välimuistin.

se päätarkoitus miksi P4n nopeista ALUista oli edes jossain tilanteessa jotain hyötyä P4ssa ei toimi zen3lla johtuen täysin erilaisesta L1D-välimuistista.

Ja ei, AMD ei tule muuttamaan L1D-kakkuaan osumatarkkuudeltaan paljon huonommaksi ja/tai virtasyöpömmäksi (ja kärsimään paljon hidastumista L1D-hutien takia) vain jotta sellainen rakenne jonka tekemisessä ei muutenkaan ole mitään järkeä muuttuisi vähän vähemmän huonoksi.

 

[El eks]

Renoir julkaistiin virallisesti
Nyt ensimmäiset nettikaupat on ilmoittaneet 4x50G Pro/tray prossuille suolaisia hintoja
niistä voidaan vetää spekulaatiota ettei nyt tullut halvalla hyvää
Tuleeko 4800/4900 versiot desktoppeihin ja jos niin millä GPUlla jäi arvailujen varaan
Kun refresh ryzenit eli XT mallit on hinnoiteltu pihalle ja kauppa ei käy , seuraa aprikointi
käykö apujen kanssa samoin ja valmistajaa kiinnostaa vain GE 35w OEM valmistus

Onko AMDn valmistuskapasiteetti loppu , black friday tulossa , silloin pitäis konsoleja olla tarjouksissa tuhansia , eli nyt on julkaistu muutama pienten sarjojen tuote , mutta se riittääkö
TSMC kapasiteetti Vermeerien massatuotantoon lienee kotinikkarien epäilys nyt

 

[vemkki]

Onko AMDn valmistuskapasiteetti loppu , black friday tulossa , silloin pitäis konsoleja olla tarjouksissa tuhansia , eli nyt on julkaistu muutama pienten sarjojen tuote , mutta se riittääkö
TSMC kapasiteetti Vermeerien massatuotantoon lienee kotinikkarien epäilys nyt

En usko hetkeäkään, että Vermeerin kohdalla olisi mitään valmistuskapasiteettiongelmaa. AMD on voinut varata kapasiteettia hyvissä ajoin ja Apple on jo siirtymässä TSMC:n pienempään valmistusprosessiin.

 

[ratkakapu]

Renoir julkaistiin virallisesti
Nyt ensimmäiset nettikaupat on ilmoittaneet 4x50G Pro/tray prossuille suolaisia hintoja

No varmaan ilmoittavat, koska nuo eivät ole vielä virallisissa jakelukanavissa vaan julkaistu pelkästään OEM markkinoille

 

[Sami Riitaoja]

Latausten suhteen tilanne on se, että P4n hyvin yksinkertaisella (ja todella huonon osumatarkkuuden omaavalla) L1D:llä niitä ylimpiä bittejä ei tarvittu heti välimuistin indeksointiin, joten yhteenlaskulta/osoitteenlaskulta saatiin osoite välimuistin indeksointiin nopeasti ilman ylimpiä bittejä, mutta jos L1D-kakusta halutaan suorituskyvyltään järkevä (hyvä osumatarkkuus ilman aivan järkyttävää virrankulutusta), se tarvii heti myös niitä ylimpiä bittejä (esim. Zen käyttää niitä way predictioniin, ja ilman way predictionia 8-way-L1D-välimuisti kuluttaisi järkyttävästi virtaa).

Eikä käytä, bitti 27 on ylin jota Zen ja Dozerit käyttävät uTagiinsa. Eli alempi puolikas piisaisi hyvin jos moiseen ratkaisuun haluttaisiin lähteä. Ja onko haluttu lähteä - ei varmaan ihan sattumalta ole justiinsa puolet toteutusta muistiavaruudesta - luultavasi ainakin AGU:t hyödyntää.

Ja luulisin että alut splittaa operaationsa osiin nykytoteutuksissa jokatapauksessa, eli kaikki mikä voidaan kannattaa laskea pienemmissä palasissa useammalle kellojaksolle sen sijaan että tehtäisiin pidempiä toiminnallisia ketjuja, P4:n tapauksessa sillä lähdettiin hakemaan nopeusetua nykyään ko. rakenteella tähdätään logiikan mahdollisimman pieneen virrankulutukseen, ja siellä puolella on kaikki käytössä mitä pystytään tekemään.

 

[knz0]

Report: AMD Ryzen 9 4950X/5950X engineering sample boosts up to 4.8 GHz - VideoCardz.com

New information on the Vermeer engineering sample has been published by Igor’sLAB. AMD Ryzen 9 4950X/5950X? Igor Wallossek has new information AMD’s upcoming Vermeer processor series based on Zen3 architecture. AMD has repeatedly confirmed that the series will indeed launch this year, including...

videocardz.com

Igor's Labin mukaan Zen 4:n Zen 3:n varhaiset engineering samplet yltävät 4.8GHz boostkelloihin. (alkuperäinen lähde saksaksi)

edit: numerot menneet väärin

 

[Cirrus]

Report: AMD Ryzen 9 4950X/5950X engineering sample boosts up to 4.8 GHz - VideoCardz.com

New information on the Vermeer engineering sample has been published by Igor’sLAB. AMD Ryzen 9 4950X/5950X? Igor Wallossek has new information AMD’s upcoming Vermeer processor series based on Zen3 architecture. AMD has repeatedly confirmed that the series will indeed launch this year, including...

videocardz.com

Igor's Labin mukaan Zen 4:n varhaiset engineering samplet yltävät 4.8GHz boostkelloihin. (alkuperäinen lähde saksaksi)

Sivuhuomiona artikkelissa kyllä puhutaan kohta tulevasta zen3:sta. Ei zen4:sta.

 

[mv. jussi]

Ei tämä ole minulle ongelma vaan tahtotila.
En halua nähdä Twitteriä, Facebookia jne. enkä samalla luovuttaa tietoani itsestäni heille.

ei tarvitse antaa mitään tietoja, itsellä toimii kahdella klikkauksella--ensin antaa cannot load tweeet

 

[Halpuuttaja]

Igorin sivuilta löytyy nyt myös havainto 4,9ghz buustaavasta 16-ytimisestä ES:sta.

AMD:n patentteja tonkiva Underfox hypettää Zen3:sta aika rajusti:

 

[AAtte]

En tiedä miten Zen 2 tulee obsolete, jos kaikki pelit suunnitellaan seuraavaksi 5 vuodeksi Zen 2 prossu npäälle konsoleiden takia.

 

[pomk]

En tiedä miten Zen 2 tulee obsolete, jos kaikki pelit suunnitellaan seuraavaksi 5 vuodeksi Zen 2 prossu npäälle konsoleiden takia.

Konsolipelit rullailee suurimmalta osin 30-60fps. Tarvitset nopeamman prossun jos haluat enemmän ruutuja ja mikäli peli on cpu rajoitteinen.

 

[vemkki]

En tiedä miten Zen 2 tulee obsolete, jos kaikki pelit suunnitellaan seuraavaksi 5 vuodeksi Zen 2 prossu npäälle konsoleiden takia.

Voihan se tarkoittaa sitä, että Zen 2:ta ei enää kannata ostaa muuten kuin ulosheittohintaan. Sinänsä tässä ei olisi mitään uutta. Kyllähän jonkun Ryzen 2700X:nkin hinta puolittui muutamassa kuukaudessa 3000-sarjan julkaisun myötä.

 

[pomk]

Eikös uudet konsolit tue 4k resoluutiota jolla ainakin oman ymmärryksen mukaan cpu:n merkitys pienenee?

Voi olla että riippuu siitä että mitä sillä cpu:lla lasketaan siinä pelissä.

 

[Tembez91]

Millonkahan lie AMD julkistaa Zen3 prossut? Voisivat pikkuhiljaa alkaa edes tiedottaa niistä jotain.

 

[JiiPee]

Millonkahan lie AMD julkistaa Zen3 prossut? Voisivat pikkuhiljaa alkaa edes tiedottaa niistä jotain.

Veikkaan että Zen 3 ja RDNA2 julkaistaan samaan aikaan aivan kuten reilu vuosi sitten Ryzen 3000 sarja ja Navi. AMD on ollut varsin hiljaa noista, veikkaan että siellä odotellaan toi Nvidian julkkari ja sitten alkaa AMD:n taholta tihkumaan myös infoa. Eli Veikkaan että hyvin pian ollaan jo viisaampia.

 

[JiiPee]

Hmmh Vermeeriä kahdella revisiolla ilmeisesti tulossa.

Reddit - Dive into anything

www.reddit.com

 

[leffo]

Eikö noi reversiot ole emojen variantteja? Siis tarkemmin piirisarjan tms.

Eiku ilmeisesti siis sama kuin stepping/spec Intelillä, prossumallin tietty sarja.

 

[Eksuu]

Pikku hiljaa tarttisi Zen 3 prossujenkin alkaa ilmestymään. Nvidialta ainakin saatiin jo melko hyvät näyttikset ja prossu vielä kokoonpanosta puuttuu. Alkaa jo sormet syyhyämään että pääsisi hiplaamaan uutta rautaa. Ei varmaan mitään vuotoja tms. ole vielä näkynyt?

 

[JiiPee]

Pikku hiljaa tarttisi Zen 3 prossujenkin alkaa ilmestymään. Nvidialta ainakin saatiin jo melko hyvät näyttikset ja prossu vielä kokoonpanosta puuttuu. Alkaa jo sormet syyhyämään että pääsisi hiplaamaan uutta rautaa. Ei varmaan mitään vuotoja tms. ole vielä näkynyt?

On kai niitä jotain epämääräisiä ollu tyyliin 20% IPC parannusta ja tais jotain kelloja olla jotain 4,8GHz jos en väärin muista.

 

[Eksuu]

On kai niitä jotain epämääräisiä ollu tyyliin 20% IPC parannusta ja tais jotain kelloja olla jotain 4,8GHz jos en väärin muista.

Tarkoitin lähinnä koska julkaistaisiin. Sori, kirjoitin eri tavalla kuin ajattelin