Antros kartos „Ryzen“ tikrai pasirodys balandį

Praėjusią savaitę pamatėme ne vieną skaidrę su įvairia informacija apie antros kartos „Ryzen“ procesorius. Vienoje iš tų skaidrių buvo pažymėta, kad patobulinti „Ryzen“ bus išleidžiami tik antroje 2018 metų pusėje. Jau tada tokia informacija atrodo mažai tikėtina, nes balandį pasirodys naujos AM4 pagrindinės plokštės, o jų pristatymas be naujų procesorių neturėtų prasmės.

HardOCP“ paviešino skaidres, kurias gavo tiesiogiai iš AMD. Jose puikiai matome, kad antros kartos „Ryzen“, pagaminti naudojant 12 nm litografiją, debiutuos balandį. Tie, kas laukia atnaujintų „Threadripper“ turės kentėti iki antros 2018 metų pusės. Konkretesnės datos skaidrė nenurodo.

15 Komentarai

  1. Minde parašė:

    Idomu, ar kiek pageres situacija, kai darbas permetejimas is vieno bloko i kita?

    • Mindaugas Klumbis parašė:

      Ale visi kalba, kad atsakas sumažės, tuo pačiu ir situacija turi pagerėti kai bendrauja skirtingi blokai. Kaip bus iš tikro, kas ten dabar žino.

    • kernel_panikuoja parašė:

      Speciau sumazins keliom ns, kas is praktines puses nelabai tures itakos. Velinimas yra MCM tradeoff’as ir tiek, o turint omenyje, kad Zen core vistiek yra „server first“ produktas, tai jis net ne tradeoff’as, o chuinia, nes cloud’e vyrauja ne multithread’inis load’as, o multitask’inis. Arba multithreadinis su minimalia inter-thread komunikacija.

      Sakyciau maksimum ko galime tiketis, tai stabilesnio 4000+ atminties supporto, bet matysim, kaip bus is tikro.

      Apskritai tas delay’u klausimas nera gerai apibreztas, nes dar neaisku, pavyzdziui, kiek tiksliai Ryzen’ai atsilieka tik del delay’u, o kiek del IPC, dazniu ar siaip visokiu optimizaciju Intel’iui.

      • Minde parašė:

        tai multitaskinimas tai tas pats multihreadinimas. Ten procui jokio skirtumo, is kur ten tas threadas ateina. Nebent multitaskinime gal kazkiek turetu buti pastovesni threadai, ir juos reciau permetineti reiktu.

        • kernel_panikuoja parašė:

          Proco atzvilgiu skirtumo nera, bet OS ir application’u atzvilgiu tai yra.

          Multitasking’as paprastai reiskia, kad kalba eina apie atskirus savarankiskus OS procesus, kurie arba visiskai tarpusavyje nekomunikuoja, arba komunikuoja minimaliai, o ju komunikavimas dazniausiai buna abstrahuotas kazkokia network’o forma – soketu, virtualiu interfeisu. Kartais kazkokia message queue forma ar shared atmintim. Siuo atveju inter-CCX ir inter-CHIP velinimas beveik neturi reiksmes. Toks load’as labai daznas buna cloud’o fermose, kur fizinej masinoj buna paleista bare metal virtualke, kuri suka N +-nepriklausomu VM’u, kurie savo ruoztu suka kazkokius +-nepriklausomus servisus, o kiekvienas servisas apdoroja +-nepriklausomus requestus. Is esmes AMD Zen’a kure butent tam, arba didele dalimi tam, kad cloud’e konkuruotu su Intel pagal kaina, nes cia esme yra daug branduoliu ir geras energetinis efektyvumas.

          Multithreading’e paprastai kalba eina apie viena procesa kuris spawn’ina kelis working thread’us. Vat cia ir prasideda nesamones, jeigu to proceso bendras nasumas didele dalimi remiasi i tai, kaip greitai komunikuoja thread’ai. Atitinkamai vienais atvejais velinimas itakos turi minimaliai, kitais nemazai. Kokiam cinebench’ui ar bet kam kitam, kas padalina po dideli gabala duomenu kiekvienam thread’ui ir jie sukasi daugiau maziau autonomiskai skirtumo daug nera, nes thread’ams nereikia pastoviai greitai komunikuoti tapusavyje tarp skirtingu branduoliu. O tarkim zaidimuose ar kazkokiam kitam IPC-heavy distributed-like event-based briede priesingai – thread’ai yra stipriai susije, todel velinimai mazina bendra nasuma. Bet kaip jau rasiau, sunku pasakyt kiek tiksliai, nes yra nemazai ir kitu kintamuju.

          • Minde parašė:

            tai kiek surpantu procas nieko nezino apie ta threadu komunikacija tarpusavyje. Cia softo/programu reikalas, kaip sharina resursus, pvz atminti (nors gal tas resursu share’inimas gal ir gudriau eina). Ir kiek suprantu, sita problema yra ne del shareinimo, o del threadu permetimo ant kito branduolio nepriklausomai, ar tas ten komunikuoja ar ne. Reiktu man pasiskaityti, kaip ten vyksta su resursu shareinimais.

            • kernel_panikuoja parašė:

              Taip. Procesorius realiai tik vykdo instrukcijas ir nieko daugiau nezino. Jis gali savo viduje kazka optimizuoti ar perstatineti (out-of-order speculative execution ar multiple issue metodai), taciau RAM atzvilgiu tu jam pasakai, kad pradek vykdyt nuo adreso X, ir jis bukai vykdys masinini koda to adreso. Jeigu, tarkim, CPU yra 4C/4T (be SMT), tai jis atitinkamai vienu metu gali lygiagreciai vykdyti 4 loginius instrukciju stream’us (hardware thread’us) nuo 4 skirtingu RAM vietu, tapatu tam, kas butu 4 skirtingi CPU prie to pacio RAM prijungti. Grynai softo atsakomybe pasirupinti, kad tie hw threadai butu sinchronizuoti ir visom kitom prasmem veiktu korektiskai, nes CPU tik gauna adresa ir varo nuo to vietos.

              SMT atveju viskas yra panasiai, tik skirtumas tas, kad vienas fizinis branduolys gali vienu metu vykdyti daugiau nei viena hw threada. Intel/AMD atveju ju buna 2, bet tarkim buna IBM’iniu CPU su 8. Skirtumas cia tas, kad to pacio fizinio branduolio hw thread’ai tampa ‘oportiunistiniai’ ir kiekvieno is ju gautas branduolio realus laikas priklauso nuo to, kokio itensyvumo yra kitas to pacio branduolio thread’as: jeigu vienas thread’as generuoja dideli load’a, tai ant to pacio core esantis kitas thread’as retai kada gali gauti daugiau 30% laiko, nes jie abu dalinasi dali fiziniu ALU/FPU ir kt. bloku.

              HW Thread’ai duomenis paprastai share’inasi per RAM’a, taciau kadangi L1-L3 cache mechanizmas veikia permatomai programeriui, CPU kartu su OS asistavimu dali dalinimuisi skirtu duomenu gali ikelti i cache. Vat cia ir prasideda visi Ryzen (siaip ir kitiem galioja, bet su juo geriau pasimato) CCX ir MCM niuansai. Pas Ryzen’a delay isauga, jeigu nori pasiekti cache’a kitame CCX’e, ir dar daugiau isauga, jeigu nori pasiekti kito CHIP’o cache.

              Cia yra grynai OS scheduler’io atsakomybe taip valdyti procesus ir thread’us, kad jie kuo maziau migruotu tarp atskiru fiziniu branduoliu, kai OS atlieka multitask’inga. Taip pat sched turi suziureti, kad jeigu load’as mazas, butu naudojamas 1/2 branduoliai, o kiti miegotu ir taupytu elektra, arba jeigu yra keli thread’ai su dideliu IPC, kad butu paschedulinti ant to pacio CCX’o, kad minimizuotusi delay’us. Zodziu visas menas kur ka execute’inti, kad CPU veiktu optimaliai yra OS ir programerio atsakomybe.

              Programeriai buvo pripratinti prie asimetriniu delay’u, uztai buvo „px nx viskas“ bus gerai. Dabar turi labiau ziuret kaip kodina, nes gali nusibausti tam tikrais atvejais. Bet ir laimet gali.

              • IFeelYou parašė:

                Suprasčiau ką jis pasakė – įsižeisčiau 🙂

                • kernel_panikuoja parašė:

                  Tiesiog lietuviskai kad parasyt reikia daug daugiazodziaut, o as dar ir siaip neaiskiai destau mintis, uztai per lietuviu kalba kuolus gaudavau 🙂

                  Konceptualiai cia viskas kaip sakoma ‘straightforward’ suprasti yra, bet va specifines implementacijos tai jau sudetingiau, nes daug detaliu viskokiu.

                • IFeelYou parašė:

                  Aš juokauju žmogau 😉 Viską čia normaliai išdėstei. Tiesiog didelės žinios iš tavęs sklinda. Pagarba.

                • kernel_panikuoja parašė:

                  I darbo gala kartais ne is karto pagaunu kampa 🙂 Is manes sklinda tik megejiskos blevyzgos. Yra lietuviu, kurie dirba NVIDIA’ioj ir kitose respektabiliose kontorose, bei knygas apie GPGPU raso. Va tie tai tikrai kazka ismano, ne diletantai kaip as 🙂

              • Minde parašė:

                tai grubiai supratau, didziausia beda yra cache’as, kuris prisirisa prie proceso skaiciavimo ar jo optimizaciju. Permetant threada reikia arba permesti cache’a arba ji pasiekti is toli. Bet man vat klausimas, o tai multitaskinime nera to cache’o? Pats threadu bendravimas savaime nera super greitas daiktas, bet kiek suprantu, pas AMD problema, kad izoliuota tarp bloku spartinancioji atmintis? Jei atmintis is visur vienodai pasiekiama butu, tai dalis problemos nukristu. Ir nuojauta kuzda, kad multitaskinime irgi tai turi skaudeti, tiesiog jei ten daug mazu tasku, tai vienus uzdarai, kitus atidarai ir nieko ten daug permetineti nereikia. O kokiuose zaidimuose tai ten kruviai vieno threado sokineja nuo 10% loaudo iki 60%, tai juos ir optimizuoti reikia perskirstant didziaja dali.

                • kernel_panikuoja parašė:

                  Principe taip. L3 share’inamas tarp visko, todel Ryzen beda ta, kad L3 pasiekimo laikas skiriasi priklausomai nuo to, kuriame CCX’e ir chip’e yra yra padetas reikalingas cache line’as. Multitaskingo atveju dazniausiai yra vieno thread’o procesas, kuris dirba su RAM’u, todel viskas saugoma tam paciam Chip’e ir CCX’e. Multithread atveju, kai yra stipri komunikacija tarp thread’u, gali ispulti tokiu atveju, kai vienam thread’ui reikia duomenu, kurie yra kito Chip’o/CCX’o cache’e, atitinkamai prisideda velinimas. Arba gal AMD flush’ina cache’us tokiais atvejais – nezinau tiek giliai jau, bet esme mazdaug tokia.

                • Minde parašė:

                  OK, dekui, bendra vaizda turiu 🙂

  2. mafo parašė:

    Jėzau šventasai, na tai jūs čia konkretūs akiniuoti ityšnikai pasirodo 🙂

Parašykite komentarą

This site uses Akismet to reduce spam. Learn how your comment data is processed.