AMD Ryzen -prosessori (Summit Ridge)

  • Keskustelun aloittaja Keskustelun aloittaja Sampsa
  • Aloitettu Aloitettu
Tästä näkee kuinka hommat hoidetaan oikeaoppisesti!!:rofl::rofl:

Probsit koko Io-Techin jengille, Keep up the good work :tup::tup::tup::tup::tup:
 
Kiima nousee! Salaa toivon että tuo 1700x on vain marginaalisesti hitaampi kuin 1800x niin säästyy karkkirahaa kun ei tarvitse ostaa sitä kalleinta. :hungry:
 
Tulee varmaa aika paljon bios updateja emolevyille seuraavien parin kuukauden aikana.
 
Mielenkiintoinen poiminta Lisa Su:n haastattelusta:

Q4: With Bulldozer, AMD had to work with Microsoft due to the way threads were dispatched to cores to ensure proper performance. Even though Zen doesn't have that issue, was there any significant back-and-forth with Microsoft to enable performance in Windows (e.g. XFR?)

LS: Zen is a pretty traditional x86 architecture as an overall machine, but there is optimization work to do. What makes this a bit different is that most of our optimization work is more on the developer side – we work with them to really understanding the bottlenecks in their code on our microarchitecture. I see many apps being tuned and getting better going on as we work forward on this.
Napsauta laajentaaksesi...

Making AMD Tick: A Very Zen Interview with Dr. Lisa Su, CEO

Eli kehittäjät joutuvat myös optimoimaan koodiaan Zenille. The Stilt tai hkultala voivat varmaan avata että mistä on kyse. Onko kyseessä ihan normaali operaatio eri prosessorien välillä, vai onko tässä jotain uutta jota pitää optimoida?
 
Dygaza sanoi:
Mielenkiintoinen poiminta Lisa Su:n haastattelusta:

Making AMD Tick: A Very Zen Interview with Dr. Lisa Su, CEO

Eli kehittäjät joutuvat myös optimoimaan koodiaan Zenille. The Stilt tai hkultala voivat varmaan avata että mistä on kyse. Onko kyseessä ihan normaali operaatio eri prosessorien välillä, vai onko tässä jotain uutta jota pitää optimoida?
Napsauta laajentaaksesi...

Nykyisillä käskyjä uudelleenjärjestelevillä prossuilla käskyskedulointia ei tarvi tehdä samalla tavalla kuten peruspenan aikana, jos koodin optimoi mille tahansa samantyyliselle prossulle, eli K6lle, P6lle, K7-K10lle, bobcat-johdannaille, Core2lle tai Core i7lle, se ajautuu myös Zenillä hyvin, ja tarkasti prossumalllikohtaisilla käskyskedulerioptimoinneilla saadaan skalaarikoodille vaan luokkaa muutamien prosenttien vaikutuksia suorituskykyyn. Tyypillisesti nämä eri prosessorien liukuhihnojen rakenteet on kuitenkin kääntäjiin mallinnettu vaikka hyöty tästä jääkin tuohon pariin prosenttiin; juuri näistä kääntäjien malleistahan oleelliset tiedot Zenin laskentayksiköistä tuli julkisuuteen.

Se, missä optimoidessa yleensä nykyaikaan tulee erot prosessorien välillä on välimuistin ominaisuudet, mutta datavälimuistien osalta niissäkin Zen on hyvin lähellä Intelin nykyprossuja; Kaikissa on sama lohkokoko (64 tavua, oikeastaan vain P4ssa tämän vuosituhannen x86sta on ollut jotain muuta), kirjoituspolitiikka(WB), ja assosiatiivisuuskin on kaikissa vähintään 4 (K7-johdannaisten L1D:n vain kahden assosiatiivisuus oli joillain yleisillä koorirakenteilla ongelma) ja assosiatiivisuus on tarpeeksi suuri suhteessa L1D:n kokoon että aliasoitumisongelmia ei L1D:ssä tule.

L1I:n osalta tilanne sentään on vähän erilainen; Intelillä on 32-kibitavua 8-tie-joukkoassosiatiivista eli 4kiB/"tie", mikä tarkoittaa että alisoitumista ei voi tapahtua, kun taas bulldozerin 64-kibitavua 4-tie-joukkoassosiatiivisena eli 16kiB/"tie" tarkoittaa että aliasoitumista voi esiintyä(virtuaalimuistin sivukoko on 4 kiB, aliasoitumista voi tapahtua jos välimuistin "tie" on tätä isompi). Pahimpiin L1I-kakun aliasoitumiseen liittyviin suorituskykyongelmiin tosin tuli Linuxin ja Windowsin kerneliin korjaukset Bulldozerin kärsittyä niistä aikoinaan, mutta tämä erilainen L1I-kakku voi joka tapauksessa hiukan vaikuttaa siihen, miten koodi kannattaa sijoitella muistiin. Tosin yleensä tämän tekee kuitenkin kääntäjä/linkkeri, eikä koodaaja itse.

Eri prossuilla on kuitenkin selvästi eroja sen suhteen, mitä kannattaa rinnakkaistaa milläkin tavalla, lähinnä noiden SIMD-käskykantojen osalta; Sandy Bridgestä lähtien intelillä on ollut 8*32-bittinen SIMD-datapolku liukuluvuille, kun taas Bulldozer ja Zen sisäisesti pilkkovat AVX-käskyt kahteen 4*32-bittiseen osaan. (tosin sama koodi rinnakkaistettu 8*32-bittisiksi AVX-käskyiksi todennäköisesti Zenilläkin ajautuu nopeammin kun 4*32-bittisiksi SSE-käskyiksi rinnakkaistettuna). Toisaalta sitten Summit Ridgessä on enemmän ytimiä kuin useimmissa intelin piireissä, joten monisäikeistys nousee tärkeämpään asemaan.

Lisäksi esim. AVX2n Gather load on ominaisuus, joka teoriassa mahdollistaa monen sellaisen loopin vektoroinnin, jota muuten ei pystyisi vektoroimaan, mutta ainakin Haswellilla ja Broadwellillä sen toteutus oli niin hidas että vektoroimaton tai "softaemuloitu gather" tuotti käytännössä yleensä nopeamman koodin kuin gatherin käyttö näillä prosessoreilla. Se, kannattaako gatheria Zenillä käyttää on ainakin hyödyllinen tieto softien optimointiin.
 
Hienoa, että artikkeli ei tule myöhästymään viime hetken muutosten/lisäysten takia. :tup:
"Ei voi muuta sanoa, kuin hattua nostaa."
 
hkultala sanoi:
L1I:n osalta tilanne sentään on vähän erilainen; Intelillä on 32-kibitavua 8-tie-joukkoassosiatiivista eli 4kiB/"tie", mikä tarkoittaa että alisoitumista ei voi tapahtua, kun taas bulldozerin 64-kibitavua 4-tie-joukkoassosiatiivisena eli 16kiB/"tie" tarkoittaa että aliasoitumista voi esiintyä(virtuaalimuistin sivukoko on 4 kiB, aliasoitumista voi tapahtua jos välimuistin "tie" on tätä isompi). Pahimpiin L1I-kakun aliasoitumiseen liittyviin suorituskykyongelmiin tosin tuli Linuxin ja Windowsin kerneliin korjaukset Bulldozerin kärsittyä niistä aikoinaan, mutta tämä erilainen L1I-kakku voi joka tapauksessa hiukan vaikuttaa siihen, miten koodi kannattaa sijoitella muistiin. Tosin yleensä tämän tekee kuitenkin kääntäjä/linkkeri, eikä koodaaja itse.
Napsauta laajentaaksesi...

Zen:issä L1i aliasointi ei voi olla ongelma koska osoitetranslaatio virtuaalisesta fyysiseen tehdään samaan aikaan haarautumisenennustuksen kanssa, ja haku välimuistista tehdään suoraan fyysisellä osoitteella. Tähän on monta syytä, tärkeimpänä se että se L0 välimuisti on myös fyysisesti mapattu, ja että prosessorilla olisi lyhyempi liukuhihna sieltä ajettaessa niin TLB-haut pitää tehdä aikaisemmin.

Tuon mahdollistamisen lisäksi tämän valinnan suurin etu on juuri että L1i-kakun kokoa ja assosiatiivisuutta ei rajoita muu kuin latenssi. Uskon että jos se L0 toimii hyvin niin Zen+:n ja sen seuraajien L1i:n koko saattaa kasvaa.

Haittana on se että TLB-hakuja tehdään kai jonkin verran enemmän kuin oikesti on tarve, mikä maksaa tehoa. Tämän vuoksi AMD:lla on myös se L0/L1 TLB jako jossa molemmat ovat tarpeeksi nopeita vastaamaan ajoissa ilman kuplia, mutta jos osoite löytyy siitä (hyvin pienestä) L0 TLB:stä, ei tarvi polttaa virtaa L1:sen avaamiseen. Jos L1 TLB:stä tulee huti, niin sitten pitää odottaa hetki lisää kun paljon hitaammasta L2 TLB:stä haetaan.
 
Jännä että osalla sivustoilta on jo artikkelit, pcper ja anandtech esim. Varastivat tunnilla?
 
Hyvältä vaikuttaa testien perusteella. Ainut, että ei taida juuri yhtään ylikellottua >4 Ghz. Mutta hinta/teho -suhde näissä on todella hyvä.
 
Peli testeissä jostain syystä ei näytä oikein irtoavan (ainakaan guru3d, anand tai pcper).
 
Eipä taida vielä olla tarvetta päivittää e3-1231v3:sta. Uutena maksoin vuonna 2014 239e, joten mikä näissä nykyisin maksaa. Toki tekniikka kehittyy ja nopeutuu. Mutta katsellaan nyt tuloksia.
 
Toiset noudatti näköjään 9 EST NDA liftiä ja toiset 9 CT NDA liftiä.
 
Sanpin kellokin jäljessä. Ei ollut artikkelia 17:00,1 ladatulla sivulla.
 
@Sampsa Voitko avata näitä viime hetken tapahtumia maailmalta? SMT disabloituna parempia tuloksia? AMD:n viime hetken ohjeita tms? En nähnyt artikkelissa mitään.
 
Apua.. Mikä tää hitaus näissä peleissä on!?

Softapuolella pärjätään hyvin, mutta pienoinen pettymys on tuo pelikäyttäytyminen.
 
Kyllä! Ihan ei pyyhitä Intelillä lattiaa tehoissa mutta tehosuhde hintaan nähden on kyllä perhanan kova! :cigar:
 
Joo, peleissä olisi saanut olla vähän nopeampi. Mutta ihan jees paluu AMD:ltä.
 
"Käytännössä Ryzen 1800X- ja 1700X-prosessorit voi toimia voivat toimi 1-2 ytimen rasituksessa ilmoitettu Boost-taajuutta 100 MHz korkeammalla XFR-taajuudella, jos prosessorin lämpötila- ja tehonkulutus sallivat."
Tuolla huomasin pienen virheen :)

Tjoo peleissä ei ihan intelin huippuja vastaan pärjätä, mutta kuulostellaas lisää...
Hintaansa nähden toki mahtava paluu AMD:lta :)
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
258 402
Viestejä
4 489 882
Jäsenet
74 154
Uusin jäsen
Almedin

Hinta.fi

Back
Ylös Bottom