io-tech vieraili viime viikolla San Franciscon kupeessa järjestetyssä AMD:n Tech Summit -tapahtumassa, jossa se antoi esimakua ensi vuonna julkaistavasta Ryzen-työpöytäprosessorista.
AMD:n uuteen Zen-arkkitehtuuriin perustuva Summit Ridge tullaan julkaisemaan virallisesti Ryzen-nimellä. 8-ytiminen ja 16 säiettä tukeva prosessori toimii 3,4 GHz:n perustaajuudella ja rasituksessa kellotaajuus nousee Precision Boost -ominaisuudella.
A #NewHorizon for AMD is coming. Introducing Ryzen, the next generation of AMD processors. pic.twitter.com/myQOSFYalj
— AMDRyzen (@AMDRyzen) December 13, 2016
Kuvasimme videolle suorituskyky- ja tehonkulutustestit, joissa vastakkain olivat AMD:n Ryzen-prosessori 3,4 GHz:n kellotaajuudella (ilman Boost-taajuutta) ja Intelin Core i7-6900K -prosessori.
io-techin ennakko: AMD Ryzen -prosessori (Summit Ridge)
Viimeisimmät prosessori/muisti settini ovat:
AMD 3700+ 2Gb DDR1 400 (1-ydin) => Q6600K 4Gb DDR2 800 (4-ydintä) => 2600K 16Gb DDR3 1600 (nykyisin käytössä, 4-ydin/8-säie)
Joten kyllä, ainakin itse ostan koska asennan, rakennan ja päivitän koneeni itse. Miksi hankkisin jotain mikä kestäisi esim. vain 1-2 vuotta kun voisin samalla hankkia jotain joka esim. nyt on kestänyt 6 vuotta emo+muistit+prosessori osalta?
3800+ raskaasti kellotettuna -> i7-920 (->930 D0) raskaasti kellotettuna -> Ryzen?
Eli kyllä. Päivitän konetta pitkällä aikavälillä ja otan mieluummin sellaista jonka tietää kestävän aikaa.
Loistava julkaisu, meni odotetusti ja lopultakin saatiin Intelin ryöstöhinnoittelulle stoppi.
Melkosta bäng for buckia tarjolla, kun laittaa 1700X:n B350-lankkuun. Kivasti saa matx-settiin ja jäähtyykin ilman kuranpyörittimiä. Jokohan malttais luopua tästä Sandysta:hungry:
Ja kyllä, koneella tullaan tekemään muutakin kuin pellailua…
Pelaajille tue ei kyllä ole tuollaisenaan vielä kovin hohdokas. Ellei AMD saa korjattua tuota SMT bugia biosilla tai muilla päivityksillä. Itelle seuraava prossu on kyllä joko Intelin 6 tai 8 core. Noh, onneksi en ennakkotilannut. Annan uudelle platformille aikaa korjauta suurimmat bugit. Kukaan ei vissiin vielä pelejä testannut nopeammilla muisteilla? Guru3d testasi muistiväylän vain, jossa AMD:n hyötysuhde on kyllä kova. 3600 muistella kahdella kanavalla Intelin 4 kanavaisten joukossa.
AMD Ryzen 7 1800X Review
Tässä olisi 3.9GHz 1700 vs 5GHz 7700K. Molemmilla 3000MHz muistit
AMD Ryzen 7 1700 vs Intel i7-7700k CPU – Best Gaming Processor Around $300?
Outoa miten ihan järjettömän suuria eroja tulee eri testaajien välillä, johtuisikohan biosin bugeista / emolevyistä / muistin nopeuksista?
Paitsi että parin vuoden päästä Ryzenin voi päivittää kun Intelillä on taas uusi hieno prosessorikanta, jotta saa myytyä uudet piirisarjat…
Väittäisin biosien olevan vielä todella bugisia ja muistin nopeus luultavasti vaikuttaa aika paljon.
Prossu/emo ois hyvä sen 3-5 vuotta kestää ainakin omasta mielestä.
2600k:lla menty 5 vuotta, ja näyttis on kyllä vaihtunut vuosittainkin, joskus parikin kertaa. Elikäs itse ainakin haluan taas seuraavankin prossun 3-5 vuoden käyttöön.
Vähän liian paljon poikkeavat muitten tuloksista, haiskahtaa nämä Toptengamerin testaukset. Toivon toki että ovat oikeassa ja kyse on jostain korjattavissa olevista bugeista.
Voisko olla eri testausmetodit kyseessä?
![[IMG]](http://i.imgur.com/uGD8xC5.jpg)
Mitkähän nyt on ne oikeat tulokset? Todella vaikea arpoa noista. Pitäs saada varmaa tietoa, että päivittääkö tässä nyt oman prossun 7700k:n vai johonkin R7:aan. BF1 testitkin heittää kaikilla revikoiden tekijöillä.
Ei tähän saada selkoa ennen kuin tuo SMT-hässäkkä selviää ja korjataan (jos onnistuu, toivottavasti!). Sitten ajettava uudet testit. Ikävä tahra muuten hyvään launchiin 🙁
No ei varmasti kannata tuota tehdä ainakaan vielä.
Joo, pakko tässä on vielä odotella, jos tulis joku järkevä selitys noille benchmarkki eroille.
SMT bugi toki voi olla olemassa, mutta ilman SMT:tä Ryzenit eivät myöskään pärjänneet, vaikka vähän paremman suorituskyvyn saivatkin. Hyötyohjelmissa todella hyvä, mutta jostain syystä suorituskyky ei vain siirry peleihin.
Nyt kun AMD:ltä tuli nämä ryzenit, niin onkohan ne tuomassa myös kunnollisia läppäriprossuja jossain vaiheessa?
Näin voisi olettaa. Ryzen on todella virtapihi matalilla 2ghz kellotaajuuksilla.
Varmaan 3GHz+ malleja tulee myös, kun luulisi neliytimisen taipuvan helpohkosti 30-40w haarukkaan, kun 1700 on 65w. Eli ihan pelikelpoisiakin läppäreit vois tulla integroidulla vegalla.
Mielenkiintoista nähdä, että milloin niitä läppäriprosuja tulee. AMD:n resurssit eivät ole tällä hetkellä erityisen mittavat, joten todennäköisesti kaikkea mahdollista ei pystytä pukkaamaan ulos samaan aikaan.
Kyllähän ne niitä vielä tälle vuotta lupaili. Eiköhän ne yritä syksyyn saada ne pihalle, jolloin kysyntäkin suurinta.
uusin hwinfo, cpuz kaikki näyttää 1.55v kokoajan rytsönilleni, Mestari seilailee 1.1-1.325v välillä :joy: 🙁
Senttejä heittelen, mutta voisiko noilla Neural Net Predictionilla tai Smart Prefetchillä olla mitään tekoa pelitulosten heittelyssä?
Miten nää tekniikat edes toimii ja minne nuo algoritmit tallentuu? Jos nämä eivät oo ihan pelkkää sanahelinää ja peeärrää niin jollain tasolla lienee mahdollista että näillä olisi jopa vaikutusta…?
Ne ovat vain komeampia nimiä tekniikoille joita on käytetty prosessoreissa iät ja ajat. Toki niitä on hiukan hiottu, mutta silti.
Algoritmit ovat prossun sisäisiä, suljetusti ajettavaa toimintalogiikkaa, ei siis ulkoisia ohjelmia.
Tässä muuten aika hanakka näkemys ja puolustelu, että Ryzenit voisivat olla tulevaisuuden peliprossujakin: AdoredTV Youtubessa.
Aiemmin tätä on kutsuttu nimellä "perseptronipohjainen haarautumisennustin".
Toimintaperiaate on selitetty paperissa joka on vuodelta 2001:
https://www.cs.utexas.edu/~lin/papers/hpca01.pdf
Haarautumisenennustushistoria/siihen liittyvä data tallettuu prosessorin haarautumisyksiköllä oleviin muistisoluihin(sram-soluja tai rekistereitä). Nykyaikaisilla ytimillä tuo haarautumisennustusyksikkö alkaa olla kooltaan jo suurempi kun esim. kokonaislukulaskentayksiköt yhteensä.
Tuossa näkyy että vasen yläkulma on haaratumisennustinta, ja noista kuviosta huomaa että n. puolet siitä on käytännössä SRAM-muistia, jonne siis haarautumishistoriaa ja ennustimen kertoimia tallennetaan.
Ja Tuollainen samanlainen perseptronipohjainen haarautumisenennustin on AMD:llä ollut ainakin jo Jaguarissa ja Pumassa, eli siis PS4n ja Xbox Onen prossussa.
Ja on myös muutamassa muussa prosessorissa muilla valmistajilla, esim. Samsungin uuden Exynoksen M1:ssä(jonka pääarkkitehti on muuten sama tyyppi kuin bobcatin/jaguarin/puman pääarkkitehti, vaihtoi AMDltä samsungille)
Jaguardin ja Puman julkaisun yhtedessä vaan hypejuna ei ollut niin kovassa vauhdissa että tuota perseptronihaarautumisennustinta ei hypetetty "neuroverkkohaarautumisenennustimena" kunte ryzenin kanssa 😉
Miksi tää 14nm prosessi vaatii näin kovia jänöjä suhteessa 32nm Bulldozeriin tai Sandy Bridgeen tai vaikkapa 22nm Haswelliin?
Koska Ryzeneissa käytettävissä kellotaajuuksissa 14nm LPP toimii jo reilusti sen optimitaajuusalueen ulkopuolella (~2-3.1GHz), jolloin jännitettä tarvitaan enemmän vakaan kellotaajuuden saavuttamiseen. Bulldozerin 32nm SOI, ja Sandyssä ja Hasswellissa käytetyt prosessit olivat HP (High Performance) prosesseja, eli niiden optimitaajuusalue oli huomattavasti korkeampi. Tietysti sopassa on mukana vielä arkkitehtuuri, ja mutuna heittäisin, että osasyy Ryzenin huonohkoon ylikellottumiseen on L3 tason välimuistin ajaminen ytimen taajuudella kaikissa tilanteissa.
Valmistusprosessilla ei ole mitään "optimitaajuusaluetta". Se on aina täysin arkkitehtuurikohtaista.
Saavutettu kellotaajuus on kolmen asian yhteisvaikutus(lähinnä kerto-/jakolasku)
1) Arkkitehtuuri, käytännössä liukuhinnan pituus, pitkä liukuhinna(lyhyemmät liukuhihnavaiheet) kellottuu paremmin (esim. P4). Tarkemmin ottaen pisimmän liukuhihnavaiheen pisimmän kriittisen polun pituus on se mikä kelloa rajoittaa.
2) Valmistusprosessi
3) Olosuhteet (lähinnä jännite, lämpötila)
Zen ja Polaris valmistetaan samalla valmistustekniikalla, mutta Zenin liukuhihnavaiheet ovat selvästi lyhyempiä kuin Polariksen liukuhihnavaiheet, ja tämä on ylivoimaisesti suurin syy miksi Zenissä puhutaan yli 3 GHz taajuuksista ja polariksessa n. 1.5 Ghz taajuuksista.
Jos vaikka jonkun K5:n valmistaisi tuolla samalla "14nm" prosssoilla, kellottuisi se hädin tuskin 1.2 GHz:aan, koska sen liukuhihnavaiheet ovat niin pitkiä.
Toisaalta, jos vaikka jonkun P4n valmistaisi tuolla samalla "14nm" prosessilla, kellottuisi se helpolla "normaaliolosuhteissa" jonnekin >5.5 GHz luokkaan, koska sen liukuhihnavaiheet ovat niin lyhyitä.
Tiedän kyllä, olisi pitänyt laittaa että Zen-arkkitehtuuri optimikellotaajusalue 14nm LPP prosessilla. :smoke:
Jotain on kyllä todella pahasti pielessä:
AMD Ryzen CPU Core Scaling Performance – Phoronix
Varsinkin toi Dota2 vulkan testi.
Onko jossain selitetty, mitä tuo downcore tarkoittaa? Kahden eri CCX:n ytimiä vai SMT:tä?
edit:
ilmeisesti ytimiä, 1+1 tarkoittaa että molemmista CCX:stä yksi ydin?
ja 2+0 tarkoittaa että toinen CCX pois päältä ja toisesta 2 ydintä päällä?
Sitähän sillä haetaan, mutta noissa tuloksissa ei oo mitää järkeä. Miksi opengl:llä 2+2 /4/0 eroaa vulkanin vastaavista. Jos ongelmana pidetään että säikeet hyppivät CCX:ltä toiselle vaikka optimi olisi pitää ne yhdellä ccx:llä oman L2 ja L3 kakkunsa lämpimässä syleilyssä, niin mistä moiset erot johtuvat.
Jotenkin vaan tuntuu että olettamus että Affinityt 0-7 (CCX1) ja 8-15 (CCX2) ovat väärin. CCX 1 corethan voivat olla vaikka 0,1,6,7 ja CCX2 3,4,5,6. Tai vastaavasti vielä 0,1,4,5 ja 2,3,6,7.
Tuossa olisi parempi vertailukohta AMD Ryzen 7 1800X vs. Intel Core i7 7700K Linux Gaming Performance Review – Phoronix
Huomioitavaa on tuo muutos OpenGl versiosta Vulcaniin ja kun tuota muutosta vertailee noiden prossujen kesken. Tietysti pitää myös muistaa mahdollinen testaajan kädetys.
Mää mutuilen jotain pcie väylän kommunikointi ongelmaa/hidastelua.
tuossa on biosissa kytketty ytimiä päälle kummastakin ccx:stä. Eli eiköhän noi ole ihan oikein, tuskin se bios ihan mitä sattuu ytimiä disabloi.
Näissä tuloksissahan isoja ongelmia on selvästi vain tuossa vulcanissa. Harmi ettei ole laajempia tuloksia/testejä useilla peleillä.
Miten siinä biosissa disabloidaan ytimiä? Jos siinä on vaan että coret 1-8 erillisillä rivillä, niin ei se kerro vielä välttämättä niiden fyysistä sijaintia.
Vaikuttaisi vähän siltä, että siellä on todella paljon jotain ylimääräistä synkronointia, tai cachen false sharingia, ja kaikki aika menee ping-pong-liikenteeseen kakkujen välillä, kun kunkin ytimen välimuisti yrittää aina ottaa kilpaa samaan osoitteeseen osoittavaa välimuistilinjaa omakseen kirjoittaakseen siihen.
Kun käytössä on vain yhden CCX:n ytimiä, tämä liikenne on saman CCX:n L2- ja L1-kakkujen välillä, ja tämä on nopeampaa, ja hidastaa vähemmän.
Kun käytössä on kahden CCX:n ytimiä, tulee tätä ping pong-liikennettä myös kahden eri CCX:n kakkujn välillä, ja tämä liikenne hitaampaa.
Perimmäinen syy: Dota2n vulkan-implementaation koodi Linuxilla siis vaikuttaisi sukkaavan pahasti.
Tuon artikkelin edellisellä sivulla näytetään miltä se BIOSin valintaoptio ytimien disabloinniksi näyttää.
Vaikka coreja ja CCX:iä onkin disabloitu, niin SMT on vielä päällä. Osaako toi Dota2 erottaa nopeat ytimet noista virtuaaliytimistä oikein? Ja voiko pelin koodi valita missä ytimessä sitä ajetaan vai määrääkö käyttis sen? Tuossa olisi tarvinnut olla jokin ydinkohtainen kuormitus lisäksi näytettävänä.
No niinpä näyttää. Luulisi olevan kunnossa.
Jotenkin nää tulokset on niin randomia kun on keskisuurimäärä säikeitä käytössä että ei oikeasti tiedä mitä tapahtuu. Loadit jossa oikeasti 16 säiettä käytössä että säikeet eivät pompi toimivat hyvin. Muut eivät. Harmittaa kun ei löydy mitään custom affinity testejä jossa eri threadeja pakotetaan eri ytimille. Tekisi mieli hakea kaupasta lankku ja prossu ja testata.
Saman ytimen kahden virtuaaliytimen välillä false sharing ei ole ongelma, koska niille kaikki välimuistit on yhteisiä.
Käyttis määrää missä säikeitä ajetaan.
Tosin useimmilla käyttiksillä säie voi myös yrittää esittää toivomuksen siitä, millä ytimellä sitä ajetaan. Tämä on kuitenkin vain toivomus, ja luulisin, että pelit eivät näitä toivomuksia esitä, koska sen laskeminen, mikä "toivomus" on se oikea ja hyödyllinen on hyvin vaikeaa ja riippuu hyvin paljon siitä millä raudalla softaa ajetaan, ja mitä muuta koneella on samaan aikaan pyörimässä, ja näiden laskeminen siten että siitä olisi useammin hyötyä kuin haittaa olisi ihan hirveää nysväämistä ja silti osutaan liian helpolla pahasti pieleen.
No eikös tämä juuri ole se ongelma jos käyttis ei erota virtuaaliytimiä oikeista. Esim pelissä vaikka pelin maithread ja näyttiksen ajurithreadi samalle ytimelle, vaikka molemmat käytännössä vaativat oman dedikoidun ytimen.
Ihan nyt vois tietty testata Windowsillakin samat testit niin jäisi pois tuo "pieni" olettamus että noi AMD:n Linux driverit on Vulkan(inkin) osalta vaiheessa.
Yleensä käyttis erottaa, lähinnä bulldozerin tapauksessa heti julkaisun jälkeen käyttikset eivät erottaneet.
Ja ainakin käyttis tietää sen paljon paremmin kuin peli itse, minkä takia peli helposti antaisi käyttikselle vääränlaisia vihjeitä, jos se yrittäisi alkaa samomaan millä ytimellä se haluaa pyöriä.
Zenin kanssa ongelma on se, että käyttikset eivät osaa mallintaa/laskea tuota hitaampaa/kalliimpaa kommunikaatiohintaa kahden eri CCXn ydinten välillä. Mutta tämähän on oikeastaan päinvastainen ongelma, Zenillä haluttaisin sijoitella (keskenään kommunikoivat) säikeet samalle CCX:lle eikä hajauttaa niitä useammalle, kun taas SMT-ongelmissa on kyse siitä että haluttaisiin hajauttaa useammalle fyysiselle ytimelle eikä ajaa saman fyysisen ytimen virutaaliytimissä
Käytännössä järkevä skeduli Zenille 4-säikeiselle pelille olisi yleensä sijoittaa pelin 4 säiettä yhden CCX:n kaikille ytimille, ja lukita ne sinne, eikä sallia mitään muuta ajoon niillä, vaikka pelin säikeet nukkuisivat(jottei välimuisteista heitetä pois mitään pelin dataa), ja jättää toinen CCX kaikille taustaprosesseille. Mutta sitten kuin pelillä on enemmän kuin 4 säiettä, tämä ratkaisu ei enää toimi.
Avoimen lähdekoodin ajuri AMD grafiikka kortilla. Samalla ajurilla myös i7-7700K:n framerate putoaa kun siirrytään vulkan rajapintaan. Pudotus on vain paljon pienempi.
Voisi kuvitella että jos ongelma olisi Windows drivereissä niin vastaava ongelma esiintyisi myös hyötyohjelmissa ja CPU benchmarkeissa?
Varmasti niissä on parannettavaa sitä en sano, mutta näin mutuna näkisin että ongelma on enemmän pelien tavassa käyttää ytimiä. Kuten aiemmin sanoin, niin ongelma ei pelien suhteen välttämättä ole se että niitä pitäisi optimoida tajuttomasti, mutta ennemminkin se että ne käyttää Ryzeniä samalla tapaa kuin Inteliä ja niille tehdyillä optimoinneilla.
Niin toisaalta, jos taas sitä kommunikaatiota ei ole paljoa on parempi kun ne säikeet on eri CCX:llä ja kaikilla on nopea oma cache. Eli jotenkin se pitäisi sitten saada tuohon skedulointiin mukaan, jos halutaan että se toimii aina optimaalisesti.
Vulkan on hyvin matalan tason rajapinta joten veikkaisin, että tuo ongelma on ihan pelin koodin eikä ajurin koodin puolella; Vulkanilla pelin koodi joutuu tekemään asioita jotka aiemmilla rajapinnoilla oli ajurin vastuulla.
AMD Ryzen Performance Negatively Affected by Windows 10 Scheduler Bug
AMD Ryzen Performance Negatively Affected by Windows 10 Scheduler Bug
Peleihin 5-10% lisää kun bugi on korjattu?