- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
Googlen käyttö liian vaikeaa?
AMD CPU-spekulaatio (Zen6/Zen7 ...)
Googlen käyttö liian vaikeaa?
- Liittynyt
- 12.12.2016
- Viestejä
- 4 470
Low power versio DDR4 muistista, X-versio on nopeampaa kuin ilman X:ää
Juottamalla asennetaan, mobiililaitteisiin suunnattu
- Liittynyt
- 13.11.2016
- Viestejä
- 7 139
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)
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?
Viimeksi muokattu:
- Liittynyt
- 14.10.2016
- Viestejä
- 22 518
Sen verran kun noista kammoista mainitsit, että LPDDR4X on poikkeuksetta juotettu emolle, eli työpöytä-Renoireilla tuskin pääsee moisista nauttimaan.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?
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).
- Liittynyt
- 20.10.2016
- Viestejä
- 4 547
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)
videocardz.com
www.techpowerup.com
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...
Mitä lisää tämä toisi?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...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...
enemmän kelloja ja muistikanavia?
kaksinkertaisen muistikaistan, lisäksi mahdollisesti tuplamäärän pcie väyliä.
- Liittynyt
- 18.10.2016
- Viestejä
- 2 907
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ä..
- Liittynyt
- 17.10.2016
- Viestejä
- 1 954
Sähän voit sen laittaa muille lukemalla siellä sandboxatussa virtuaalikoneessa foliohattu päässä.
Pikku juttu kuitenkin.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
Aika nopeeta siitä upotuksesta ottaa oikealla hiiren namiskalla "kopioi linkki" ja vetää sitten foliopipon korville, avaa uuden incognito ikkunan ja pastee sen linkin siihen.
- Liittynyt
- 13.11.2016
- Viestejä
- 7 139
avaa uuden incognito ikkunan virtuaalikoneessa pyörivään linuxiin jonka distro on valittu foliopipon vaatimusten mukaan ja pastee sen linkin siihen.
- Liittynyt
- 20.10.2016
- Viestejä
- 4 547
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).
videocardz.com
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
- Liittynyt
- 14.10.2016
- Viestejä
- 22 518
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
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 ?
- Liittynyt
- 20.10.2016
- Viestejä
- 4 547
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.
- Liittynyt
- 17.10.2016
- Viestejä
- 1 105
TDP ei ole edelleenkään sama kuin tehontarve.. TDP on laskettu jollain valmistajan höpöhöpö kaavalla.
- Liittynyt
- 03.01.2018
- Viestejä
- 576
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.
- Liittynyt
- 27.12.2016
- Viestejä
- 785
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?
AMD vahvistanut, että Zen3 kuluttajaprosessorit tulevat tänä vuonna.
www.io-tech.fi
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
- Liittynyt
- 22.10.2016
- Viestejä
- 11 772
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.
Ei. Se on nimenomaan keino, jolla sellaista ei saada aikaan, koska varaa tähän ei yksinkertaisesti ole (absoluuttisessa ajassa mitattuna).
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.
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.
Viimeksi muokattu:
- Liittynyt
- 27.12.2016
- Viestejä
- 785
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?
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.
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.
- Liittynyt
- 22.10.2016
- Viestejä
- 11 772
Se aiheutti jo Willamettessä suuria suorituskykyongelmia siinä, että shiftaukset olivat hyvin hitaita. Se oli aina suorituskykyongelma.
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.
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".
Juuri näin P4 teki, ja se teki datansiirrosta prosessorin eri laskentayksiköiden välillä todella hidasta.
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.
- Liittynyt
- 27.12.2016
- Viestejä
- 785
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".
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.
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.
- Liittynyt
- 22.10.2016
- Viestejä
- 11 772
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.
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.
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.
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
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.
"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.
Viimeksi muokattu:
- Liittynyt
- 27.12.2016
- Viestejä
- 785
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.
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?
- Liittynyt
- 22.10.2016
- Viestejä
- 11 772
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.
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.
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?
Viimeksi muokattu:
- Liittynyt
- 27.12.2016
- Viestejä
- 785
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.
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.
- Liittynyt
- 22.10.2016
- Viestejä
- 11 772
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ä.
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.
Viimeksi muokattu:
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
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
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.
- Liittynyt
- 12.12.2016
- Viestejä
- 4 470
No varmaan ilmoittavat, koska nuo eivät ole vielä virallisissa jakelukanavissa vaan julkaistu pelkästään OEM markkinoille
- Liittynyt
- 03.01.2018
- Viestejä
- 576
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.
Viimeksi muokattu:
knz0
300 yard drive
- Liittynyt
- 02.11.2016
- Viestejä
- 1 353
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
edit: numerot menneet väärin
Viimeksi muokattu:
Cirrus
Miksei maailma toimi asmilla?
- Liittynyt
- 16.10.2016
- Viestejä
- 3 240
Sivuhuomiona artikkelissa kyllä puhutaan kohta tulevasta zen3:sta. Ei zen4:sta.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...
Igor's Labin mukaan Zen 4:n varhaiset engineering samplet yltävät 4.8GHz boostkelloihin. (alkuperäinen lähde saksaksi)
ei tarvitse antaa mitään tietoja, itsellä toimii kahdella klikkauksella--ensin antaa cannot load tweeetEi tämä ole minulle ongelma vaan tahtotila.
En halua nähdä Twitteriä, Facebookia jne. enkä samalla luovuttaa tietoani itsestäni heille.
- Liittynyt
- 21.02.2017
- Viestejä
- 5 355
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:
AMD:n patentteja tonkiva Underfox hypettää Zen3:sta aika rajusti:
Konsolipelit rullailee suurimmalta osin 30-60fps. Tarvitset nopeamman prossun jos haluat enemmän ruutuja ja mikäli peli on cpu rajoitteinen.
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ä.
Voi olla että riippuu siitä että mitä sillä cpu:lla lasketaan siinä pelissä.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
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.
- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
- Liittynyt
- 15.04.2018
- Viestejä
- 2 343
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?
- Liittynyt
- 21.06.2017
- Viestejä
- 7 245
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.
- Liittynyt
- 15.04.2018
- Viestejä
- 2 343
Tarkoitin lähinnä koska julkaistaisiin. Sori, kirjoitin eri tavalla kuin ajattelin
Uutiset
-
Uusi artikkeli: Testissä Samsung Galaxy S24 FE
22.11.2024 20:48
-
Live: io-techin Tekniikkapodcast (47/2024)
22.11.2024 13:35
-
DeepCool julkaisi uudet LP240- ja LP360-AIO-coolerit matriisinäytöllä
22.11.2024 02:58
-
Google julkaisi Android 16:n ensimmäisen kehittäjäversion
22.11.2024 02:39
-
NVIDIA saavutti päättyneellä neljänneksellään jälleen uuden ennätystuloksen
22.11.2024 02:17
Uutisia lyhyesti
-
Gigabyte julkaisi uudet 4K- ja 1440p-tarkkuuksien QD-OLED-näytöt- Kaotik
- Vastauksia: 0
-
Chiefteciltä kaksikammioinen Visio-kotelo kahtena eri versiona- Juha Kokkonen
- Vastauksia: 2
-
