Ar verta atsinaujinti į AGESA 1.0.0.4 ir ar „ASUS ROG Crosshair VIII Impact“ yra inžinerinis šedevras?
Spartos testai (įjungta PBO funkcija)
Įjungus PBO + AutoOC 200 MHz funkcijų kombinaciją PPT, TDC ir EDC vertės automatiškai padidėja iki 395 W, 255 A ir 255 A. Identiškas vertes turi ir „Formula“ pagrindinė plokštė, o „ASRock X570 Steel Legend“ pasižymi dar didesnėmis, atitinkamai, 1000 W, 300 A ir 500 A vertėmis.
„ASRock“ priklausančioje grafoje nematome nei vieno paryškinto langelio. Visus geriausius testų vidurkius išsidalino „Formula“ su „Impact“, kuri tarp dviejų ASUS pagrindinių plokščių surinko daugiau pergalių. Buvo nusileista tik modeliuojant „POV-Ray“ (single core) ir skaičiuojant „Winrar“ pralaidumą. Daugelyje scenarijų skirtumai vėl labai nedideli, tačiau yra ir keletas išimčių. Viena jų „Cinebench r20“ (multicore). „Impact“ vienintelei paskutinio bandymo metu pavyksta perkopti 5000 taškų žymą, susikraunant 35 taškų pranašumą prieš „Formula“ skaičiuojant vidurkį. Tiesa, „Impact“ antrą kartą iš eilės pora fps nusileidžia konkurentams „Far Cry 5“ šaudyklėje. Energijos sąnaudos labai panašios su „Steel Legend“, dažniausiai prieš „Formula“ turint bent 10 W efektyvumo pranašumą.
ASUS ROG Crosshair VIII Formula (BIOS 1001/ 1.0.0.3ABBA) PBO enabled +AutoOC 200 MHz | ASRock X570 Steel Legend (BIOS 1.90/ 1.0.0.3ABBA) PBO enabled | ASUS ROG Crosshair VIII Impact (BIOS 1001/ 1.0.0.3ABBA) PBO enabled +AutoOC 200 MHz | |||||||
Maksimalus UCLK:FCLK santykis | 1800:1800 MHz | 1733:1733 MHz | 1800:1800 MHz | ||||||
Testas |
1-as bandymas | 2-as bandymas | 3-ias bandymas | 1-as bandymas | 2-as bandymas | 3-ias bandymas | 1-as bandymas | 2-as bandymas | 3-ias bandymas |
Cinebench r20 (single core) | 511 | 511 | 511 | 509 | 502 | 501 | 511 | 512 | 513 |
Vidurkis | 511 | 504 | 512 | ||||||
Tipinės el. sąnaudos |
~104 W | ~97 W | ~95 W | ||||||
Cinebench r20 (multicore) | 4967 | 4962 | 4944 | 4924 | 4906 | 4906 | 4992 | 4984 | 5004 |
Vidurkis | 4958 | 4912 | 4993 | ||||||
Tipinės el. sąnaudos |
~210 W | ~190 W | ~195 W | ||||||
Corona rendering (multicore) | 01:45 | 01:45 | 01:45 | 01:46 | 01:46 | 01:46 | 01:45 | 01:45 | 01:45 |
Vidurkis | 01:45 |
01:46 |
01:45 |
||||||
Gooseberry rendering (multicore) | 29:21 | 29:19 | 29:16 | 29:36 | 29:40 | 29:40 | 29:19 | 29:16 | 29:16 |
Vidurkis | 29:22 |
29:39 |
29:17 |
||||||
wPrime 32M (4 threads) | 7,641 sec | 7,579 sec | 7,614 sec | 7,64 sec | 7,66 sec | 7,532 sec | 7,531 sec | 7,679 sec | 7,608 sec |
Vidurkis | 7,611 sec |
7,611 sec |
7,606 sec |
||||||
POV-Ray (single core) | 545,24 sec | 543,02 sec | 542,50 sec | 545,54 sec | 545,15 sec | 545,63 sec | 549,06 sec | 544,13 sec | 544,19 sec |
Vidurkis | 543,59 | 545,44 | 545,79 | ||||||
Tipinės el. sąnaudos |
~107 W | ~97 W | ~95 W | ||||||
POV-Ray (multicore) | 59,54 sec | 59,35 sec | 59,65 sec | 59,48 sec | 59,64 sec | 59,49 sec | 59,39 sec | 59,32 sec | 59,38 sec |
Vidurkis | 59,51 | 59,54 | 59,36 | ||||||
Tipinės el. sąnaudos |
~205 W | ~187 W | ~190 W | ||||||
Winrar 5.71 x64 | 23 681 MB/s | 24 031 MB/s | 23 865 MB/s | 23 527 MB/s | 23 943 MB/s | 23 554 MB/s | 23 867 MB/s | 23 728 MB/s | 23 582 MB/s |
Vidurkis | 23 859 MB/s |
23 675 MB/s |
23 726 MB/s |
||||||
7-Zip 19.00 x64 | 77 794 MIPS | 77 897 MIPS | 78 095 MIPS | 77 394 MIPS | 77 119 MIPS | 77 119 MIPS | 77 794 MIPS | 77 995 MIPS | 78 497 MIPS |
Vidurkis | 77 929 MIPS |
77 211 MIPS |
78 095 MIPS |
||||||
Far Cry 5 (1080p/+ GTX 1080 Ti) |
avg 105 fps
1 % 76 fps 0,1 % 62 fps |
avg 103 fps
1 % 78 fps 0,1 % 44 fps |
avg 103 fps
1 % 77 fps 0,1 % 45 fps |
avg 104 fps
1 % 77 fps 0,1 % 62 fps |
avg 104 fps
1 % 77 fps 0,1 % 48 fps |
avg 103 fps
1 % 76 fps 0,1 % 48 fps |
avg 103 fps
1 % 76 fps 0,1 % 61 fps |
avg 101 fps
1 % 75 fps 0,1 % 47 fps |
avg 100 fps
1 % 75 fps 0,1 % 45 fps |
Vidurkis |
avg 103,7 fps
avg 1 % 77 fps avg 0,1 % 50,3 fps |
avg 103,7 fps
avg 1 % 76,7 fps avg 0,1 % 52,7 fps |
avg 101,3 fps
avg 1 % 75,3 fps avg 0,1 % 51 fps |
Tai norint kuo greitesnio užsikrovimo geriau naujesnis mikrokodas, bet minimaliai sparta didesnė su senesniu mikrokodu. Visko negali turėti iš karto 😀
Man regis, kad atvejai, kuomet naujinti UEFI neverta, yra tokie reti, jog galima sakyti, kad visada verta 🙂
Siaip jeigu jau labai gilintis i detales, tai AGESA nera mikrokodas, bent jau ne toks mikrokodas, kuri visi suvokia istoriskai. AGESA yra AMD binariku package’as, reikalingas paupdeitint integruotus mikrokontrolerius. Turbut ne visi zinot, kad visi Ryzen AMD CPU eina dar su atskiru ARM’u integruotu – auksciausios privilegijos CPU. Jis irgi turi tureti savo „OS“.
Tas „tikras“ mikrokodas tai yra tik dalis, kuri atsigula jau grynai i CPU core’us, ir paupdeitina ta layer’i, kuris interpretuoja x86-64 instrukcijas ir skaldo jas i mikrooperacijas. Tai va sitas tiny miniatiurinis layer’iukas is tiesu yra tas klasikinis mikrokodas.
Ai, dar verta pamineti, kad modernios OS (Linux, Windows 10) uzsikrovimo metu visada pasitikrina, koks yra esamas mikrokodas, ir jeigu jos savyke su updeitais turi naujesni, run-time’e uzkrauna naujesni. Bet jis buna tik run-time, iki sekancio reboot. Jeigu yra du PC, su skirtingais AGESA, tai teoriskai imanoma, kad uzsikrovus PC iki galo su Win/Linux, jie naudos ta pati CPU mikrokoda, kuris pareis is OS updeitu konteinerio (bet reikia patikrint praktiskai, niekad to neziurejau pats).
As asmeniskai visad viskam surasau naujausius firmware’us, per daug nesuku galvos. Absoliuciai daugumoj atveju jie pataiso daugiau, nei sulauzo. Pavasari, ties LTS ubuntu-base isleidimu, pasidarau viena „inventorizacijos diena“, kai atnaujinu UEFI, SSD FW ir pan. Jeigu buna aisku updeitai 🙂 Is kitos puses, jeigu viskas veikia stabiliai, tai atnaujint prasme nebent del security fix’u tik lieka.
Kaip visada labai gera šviečiamoji informacija, bet visko nesuprantu 😀 ir tuos AGESA atnaujinimus vis tiek vadinsiu mikrokodais, nes geriau net nelabai ką ir sugalvoju.
Tai viskas OK su tuo vadinimu. Jis nera neteisingas, nes mikrokodu paprastai vadinamas software layer’is, kuris kazkieno atzvilgiu veikia kaip HW. Paprasciausiai seniau, tai buvo tik ta mazyte dalis. Dabar tas layeris isaugo smarkiai, nes modernus CPU is tiesu jau ne CPU, o SoC, su daug integruotu dalyku, kam reikia binary firmware’u.
As cia ka rasau, tai daugiau del idomumo, ar niuanso kokio tai mazo.
Kaip jau seniau esu sakę, paskaitai tavo postą ir protingesnis pasidarai nepaisant jei visko ir nesupranti 🙂
As esu tik casual’as kas del tu visu low level dalyku… Jei norit tikrai protingu minciu, rekomenduoju LINUX arba Coreboot mailing listus paskaityti 🙂 Jeigu labiau is mainstream, tai HotChips konfos turinys kartais neblogas buna. As tai tik komentuoju i tema kas man ant liezuvio tuo metu buna 😀
O kalbant apie mail listus, neseniai ten buvo idomus Torvaldso pasisakymas apie threadu sinchronizacija ir OS schedulerius. Vienas gamedev’as bande irodyt, kad linux blogai veikia, bet paaiskejo, kad jo spinlock’ai blogai padaryti is tiesu. Kalba eina apie Rage 2 koda.
Tai ka jus norit, kad ant Ryzen gerai tie zaidimai varytu, jeigu ten net sinchrozinacija gaidine buna softe, mazdaug ant i7 2600K patestavo, veikia ir davai 😀
Anyway, cia nukrypau jau nuo temos…
Įdomu pasidarė apie ta gaidinę sinchronizaciją. Moar pls.
Ten daug detaliu, tai tik saltinius imesiu, kam idomu.
Originalus gamedev’o post’as:
https://probablydance.com/2019/12/30/measuring-mutexes-spinlocks-and-how-bad-the-linux-scheduler-really-is/
Torvalds’o laisku pradzia:
https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723
TL;DR: gamedev’as nelabai suprato, kaip veikia scheduler’is, jo bench’inimas buvo netikslus, o spinlock’o implementacija prasta.
O mes ka galim pasiimti is visos sios istorijos, kad softo optimizacijos yra labai svarbu. Tiksliau net neoptimizacijos, o teisingai parasytas kodas. Ypac AMD atveju, kai yra daug thread’u ir didesnis nei Intel RAM latency.
Dėkui. Įdomus pasiskaitymas
kaip suprantu kuo daugiau thread’u iš „suklijuotų“ AMD lustų, tuo sunkiau tie thriedai susikalba ir nepasidalina tarpusavy, kas kokį Taską atliks
Blogai supranti. Bet netgi daug sunkiau susikalbanciu threadu butu geriau, nei jokiu threadu Intel atveju 😀