Z recenzí Ryzenu: přetaktování, SMT a herní výkon, potřeba optimalizací a podpora ECC

63
CEO AMD sleduje demonstraci architektury Zen (Zdroj: AMD)

Od čtvrtečního vydání Ryzenu jste si možná slibovali, že konečně utichne mediální shon, kdy v posledních týdnech byly zprávy o těchto CPU na denním pořádku. Zatím to nicméně vypadá, že klid od nich ještě nebude, jelikož s prvními recenzemi se vynořuje řada nových věcí. Ostatně jde o zcela novou architekturu a platformu základních desek, takže přicházejí větší změny než bývají u nových platforem Intelu.

Pokud chcete procházet zahraniční recenze, bude se vám hodit „rozcestník“ odkazů, které shromáždil web VideoCardz.com. Procesory otestoval například AnandTech, PC Perspective, Tom’s Hardware, The Tech Report, případně pro francouzštináře a němčináře Hardware.fr a ComputerBase. Pro uživatele Linuxu by mohl být zajímavý pohled Phoronixu na Ryzen 7 1700. Recenze víceméně potvrzují, že síla Ryzenu je v aplikačním softwaru, který škáluje na více jader. Hodně silné je třeba komprimování videa, kde je R7 1800X plnohodnotným konkurentem dvakrát dražšího Core i7-6900K.

Ve hrách naopak téměř všude vycházejí horší průměrné FPS proti Core i7-7700K, které je čistě na hry CPU výhodnější, i když má hrubého (mnohovláknového) výkonu méně. A tento rozdíl je větší, než kolik vycházelo čistě z benchmarků prezentovaných AMD. Ty byly zejména ve vysokých rozlišeních, kde je dominantní limitace grafickou kartou, na nižších frekvencích, kde je brzdou procesor, ale Ryzen proti Kaby Lake a v menší míře Broadwellu-E ztratí.

Procesor Ryzen v desce (Zdroj: Ars Technica)
Procesor Ryzen v desce (Zdroj: Ars Technica)

Ve hrách evidentně zatím vítězí vysoká frekvence a jednovláknový výkon. Nicméně situace zdaleka není tak špatná jako u procesorů FX. V normálním hraní by procesor problematický být neměl. Ovšem jak již bylo řečeno, volbou pro hraná zůstávají nadále vrcholová čtyřjádra Intelu (kterým také pomůže přetaktování).

SMT

V části recenzí byl objeven poměrně razantní (okolo 10 %) propad herního výkonu při aktivním SMT. Viz například toto testování webu Hardware.fr (ovšem je třeba říci, že podle tohoto webu je s HT ve hrách horší také Broadwell-E). To by znamenalo, že použití SMT ve hrách škodí, místo aby pomáhalo. Nicméně tento výsledek nepotvrdily úplně všechny recenze, některé zhoršení nenaměřily. Krátkodobé řešení pro hry tak může být vypnutí SMT v BIOSu, což ale uškodí výkonu v aplikacích.

Propady herního výákonu na CPU Ryzen po zapnutí SMT, změřené webem Hardware.fr
Propady herního výákonu na CPU Ryzen po zapnutí SMT, změřené webem Hardware.fr

Částečným zdrojem těchto problémů by prý mohlo být to, že současné BIOSy údajně trpí různými chybami a na Ryzen není připraveno řízení spotřeby ve Windows. To se projevuje tím, že výkonu pomáhá nastavení schématu maximální výkon a také vypnutí HPET (což AMD doporučuje v manuálu k recenzím). Aktualizace BIOSů by snad část problémů měly odstranit a AMD údajně připravuje nový ovladač, který zajistí optimální výkon i na normálním profilu („Rovnováha“). Tím by se snad nevyrovnanosti v herním výkonu měly aspoň z části zmírnit.

Ryzen bude potřebovat optimalizace

Možnosti ke zlepšení ale asi budou spíš v rukou vývojářů her. To údajně sdělilo některým recenzentům (například Tom’s Hardware) i AMD. To uvádí, že by problémy s rozdělováním práce mezi vlákna (a tedy potíže SMT ve hrách) neměly být primárně na straně operačního systému, ale spíše programů. V některých případech (například Oxide Games, Bethesda) jsou už údajně optimalizace přislíbeny. AMD podle svých slov kvůli testování a odladění rozeslalo různým firmám tři stovky sestav s těmito CPU. Během letoška by údajně mělo být poskytnuto až tisíc zkušebních strojů.

Potřeba optimalizací pro plný výkon existuje i u procesorů Intelu. Jenže pro ty je vývojáři provádějí automaticky, jelikož na těchto CPU hru obvykle vyvíjejí a ladí. Součástí toho je i profilování výkonu, takže vyladění pro architekturu Intelu hry (ale i jiné programy) dostanou takříkajíc automaticky. Pokud vývojáři začnou kontrolovat chování programu i na jádru Zen, pak by se situace mohla zlepšit, otázka ale samozřejmě je, zda tak skutečně budou činit. Snazší do bude u open source softwaru (zaznamenal jsem třeba, že nějaké prověřování je přislíbeno u x265).

Rezerva pro přetaktování je zanedbatelná

Přetaktování Ryzenu vypadá jako poměrně problematická záležitost. Firma na jednu stranu poskytne utilitu Ryzen Master, která vše učiní záležitostí pár kliknutí, se samotným křemíkem je ale pořízení naopak hodně těžké. Zdá se, že minimálně u Ryzenu 7 1800X je frekvenční potenciál v podstatě úplně vyčerpán jeho nejvyšším turbem v režimu XFR (4,1 GHz). Je možné, že stabilita se bude lepšit časem a pomohou zralejší BIOSy desek, ale zatím se výrazně výš snadno dostat nedá (míněno na všech jádrech). Recenzenti uvádějí, že se jim s osmijádry podařilo dostat jen na stabilních 4,0–4,05 GHz, někde skončili i pod touto hranicí.

Svým způsobem je toto i pozoruhodné. Nevím, jestli se už nějaký křemík podařilo vyšťavit tak maximálně, aby v něm nebyla prakticky žádná další rezerva. Řízení spotřeby a související autoregulační mechanismy musí být hodně pokročilé, když CPU dokáže běžet takto blízko limitům. Ovšem pro nás to má ten negativní dopad, že se laděním nelze s frekvencí dostat dál.

To, že mají vyšší modely strop prakticky hned nad hlavou a stěží se dostanou výš, než je frekvence jejich maximálního stavu v XFR, má jeden nepříjemný důsledek. Pokud začnete taktovat (pohnete jakkoli frekvencemi), CPU automaticky vypíná turbo i XFR. To znamená, že musíte nastavit takt všech jader alespoň tak vysoko, kolik byla maximální XFR frekvence vašeho CPU v běžném stavu. Jinak ztrácíte výkon v jednom vlákně. Určitý výkon navíc se tedy dá nahnat jen ve vícevláknovém výkonu (zejména třeba s R7 1700, jenž má základ na 3,0 GHz).

Ryzen 7 1700 přetaktovaný na 3,9 GHz v testu webu ComputerBase
Ryzen 7 1700 přetaktovaný na 3,9 GHz v testu webu ComputerBase

Jak vysoko můžete jít s napětím?

Jako maximální doporučené napětí se objevila hodnota 1,45 V, zatím ale jde jen o provizorní doporučení. Konzervativní napětí, je podle AMD spíše 1,35–1,40 V (oněch 1,45 V už prý podle modelování může čipu zkrátit život). Na takto vysokém napětí ale bude mít CPU velmi vysokou spotřebu. Spotřeba vám také stoupne tím, že spolu s turbem při přetaktování přicházíte také o automatické snižování napětí, které řízení spotřeby provádí (v běžném provozu je díky tomu reálné napětí nižší, že se zdá z viditelného nastavení).

Interní technické podrobnosti

Pokud vás zajímají technické podrobnosti Ryzenu (a čipu Summit Ridge alias také „Zeppelin“), doporučuji pojednání, které o něm napsal The Stilt na fóru AnandTech. Přináší rozbor IPC jádra a také toho, jak funguje řízení spotřeby (a jaký je jeho vztah k přetatkování). Jeho autor má přístup k mnoha interním informacím a nástrojům, takže mohl provést i experimenty jako snížení TDP. To mimochodem ukazuje, že Zen je mnohem efektivnější co do spotřeby na nižších taktech, než jaké mají desktopové Ryzeny. To by ještě mohlo být zajímavé u mobilních a serverových verzí.

Autor jinak také uvádí, že Ryzen úspěšně používá s Windows 7. Ovladače jsou funkční, problémem je jen instalace. Výchozí obraz systému nemá podporu pro řadiče USB 3.0 platformy AM4. Ty tedy musíte do instalátoru manuálně přidat, nebo instalovat z optického disku s mechanikou připojenou k rozhraní SATA.

Výkon v benchmarku Cinebench R15 (16 vláken) v závislosti na TDP čipu, autor: The Stilt
Výkon v benchmarku Cinebench R15 (16 vláken) v závislosti na TDP čipu, autor: The Stilt

Potvrzeno: Ryzen umí paměti s ECC

Častá otázka před vydáním byla, zda bude Ryzen podporovat paměti s ECC. To mnoho lidí nevyužije, ale pro někoho jde o zajímavou vlastnost a něco, čím byla platforma AM3/AM3+ unikátní. Procesory Core od Intelu totiž ECC neumožňují, je zapnuté jen u Xeonů. Dobrá zpráva je, že ECC je již údajně potvrzeno přímo od AMD. Tato možnost není oficiálně „validována“, ale všechna CPU Ryzen mají podporu ECC RAM aktivní.

Socket AM4 tedy ECC paměti podporuje také, což je důležitá druhá podmínka (je třeba 72bitový kanál paměťového řadiče místo 64 bitů). Třetí podmínkou, pokud ECC budete chtít používat, je pak podpora ze strany desky. V minulosti ji mívaly zejména desky Asusu, který ve specifikacích minimálně některých modelů platformy AM4 podporu skutečně uvádí. Ryzen jinak umí jen běžné, neregistrované moduly s ECC, nikoliv speciálnější serverové paměti typu buffered/registered (které se občas objevují třeba na aukčních serverech). Na to je tedy třeba dát při koupi pozor, nicméně pro levnou pracovní stanici či server neregistrové ECC moduly bohatě stačí.

Z recenzí Ryzenu: přetaktování, SMT a herní výkon, potřeba optimalizací a podpora ECC

Ohodnoťte tento článek!

63 KOMENTÁŘE

        • Ne, nevypada. Ve skutecnosti to ma dva duvody. Prvni je jsna chyba AMD, kdy neimplementuji korektne NUMA detekci (takze Win 10 muze nekdy spatne alokovat dve vlakna pristupujici k jednem datum na dva ruzne Zen bloky). Druha vec je negativni vliv SMT ve hrach, ktery je ale opet chybou Ryzenu, resp. velkeho poctu jader se SMT. Vetsina her tolik jader nevyuzije (ani nemuze, protoze tolik procesu se tam nedeje – to je iluze sirena AMD), a implementace SMT v Ryzenu zpusobuje zbytecne zatizeni jiz tak pomalych cache bloku. K tomu se AMD vyjadrilo, ze hodlaji rychlost zlepsit updatem BIOS/UEFI, ale moc tomu neverim. To je podle me chyba designu.

          • ale já mluvím pouze o SMT ne po threadech obecně.

            optimalizace AMD znamená, že hry musí být NUMA optimized a podle toho nakládat s thready, protože samotná windows přehazují thready mezi oběma CCX a to zpusobuje propady obecně ( bez ohledu jestli se SMT nebo bez )

          • chyba designu to určitě není protože na vícejádrových Intelech se to ve hrách pod WIN 10 chová úplně stejně jako u Ryzenu, bez ohledu na nějakou detekci NUMA. Nakonec kdyby ses aspoň kouknul na ty odkazy co jsem postnul výš, tak bys to zjistil sám.

          • Nacetl jsem nejake diskuse k NUMA a prijde mi, ze si to pletes. Pises „chyba AMD, kdy neimplementuji korektne NUMA detekci „. Pridelaovani threadu na zaklade nejakych priorit je ale preci otazka scheduleru OS. Pokud je nekde bota, tak ve Widlich.
            Druha vec co pises, mi pride absurdni “ Druha vec je negativni vliv SMT ve hrach, ktery je ale opet chybou Ryzenu“. Jestli ma SMT kladny nebo zaporny vliv, se muzeme hadat klidne do rana. Jeji prinos je ale obecne povazovan za lepsi vyuziti CPU kapacity, nez bez ni a spousta SW to vyuziva. Podle mne by OS mel spise rozhazovat zatez tak, aby dochazelo k vyuzit SMT, jen kdyz to ma smysl.

          • Ano, pridelovani thready je prace OS. Jenze ten OS potrebuje vedet, na jaka jadra ma thready alokovat, aby byla vyuzita cache co nejvice – tzn. davat thready pracujici se stejnymi daty na jadra vyuzivajici stejnou cache. U Ryzenu jsou tyhle informace systemu predavany spatne.

          • K SMT – jadra v Ryzenu vyuzivaji spolecnou cache se SMT i bez ni, ale vzhledem k tomu, ze dve logicka jadra jsou soucasti jednoho fyzickeho, tak pridelovani vypoctu temto dvema znamena, ze se navzajem ovlivnuji. A jde prave hlavne o cache – kdyz mas na jednom fyzickem jadre dve ruzne ulohy, museji vyuzivat stejnou cache. De facto se tak musi do jednoho prostoru vejit data pro dve ruzne veci (oproti tomu, kdyby tam byly data jen pro jednu). A vzhledem k pomale cachi na Ryzenu je ten efekt mnohem silnejsi u AMD, nez u Intelu (i kdyz ani ten se tomu logicky nemuze vyhnout).

          • Panove, je hezke jak probihaji diskuze a co by kdyby. Ale neodpustim si jedno rypnuti do AMD. Pokud to co slibuji pujde opravdu opravit v BIOSech a OS, tak proc to sakra neudelali pred vydanim. Minimalne ty upravy v OS. Hned by ty recenze vypadaly daleko lepe nez ted, kdy jsou kolem toho tyto otazniky.

            P.S. na redakci: Proc jako nejde pridavat odpovedi na diskuzni prispevky od urciteho zanoreni? No ale i ostatni veci v novem layoutu stranek jsou ne krokem, ale nekolik kroku zpet.

          • Maudite, mne to ale porad prijde, ze je to spis problem OS. Muzeme se prit o to, jestli ten design Ryzenu ala „slepenec“ 2 x4jader je optimalni nebo ne. A asi dojdem k zaveru, ze pro urcite ulohy tam bude nejaka limitace. Na druhou stranu, se mi nechce verit, ze interface CPU by nebyl schopny sdelit, co je zatizeni konkretniho fyzickeho jadra, kolik dalsich fyzickych jader je volncyh, tak aby to scheduler OS mohl vyuzit. Pripadne si to nejaka vnitrni logika toho CPU neridila. To stejne plati pro ty 2 slepence. Je mozne ze to „nejde“,ale verit se mi tomu fakt nechce.

          • to tombomino: MS? No nevim. Naopak si myslim, ze to mohli pouzit jako velkou reklamu na W10 oproti W7, pro ktere AMD prohlasilo, ze nebudou delat podporu nekterych features. Pokud by na W10 to bylo odladeno a bezelo treba o 20% lepe nez na W7, tak to by byl padny argument na prechod. Tady bych na MS nic nehazel, sel by sam proti sobe.

          • @Maudit : „K SMT – jadra v Ryzenu vyuzivaji spolecnou cache se SMT i bez ni, ale vzhledem k tomu, ze dve logicka jadra jsou soucasti jednoho fyzickeho, tak pridelovani vypoctu temto dvema znamena, ze se navzajem ovlivnuji. A jde prave hlavne o cache – kdyz mas na jednom fyzickem jadre dve ruzne ulohy, museji vyuzivat stejnou cache“

            Ryzen používá WCC (podobně jako Bulldozer), která se stará o to, aby nedocházelo k dvojitým zápisům či zasahování threadů do cache.

          • @del42sa

            To s tim ale nema nic spolecneho. Fyzicky jsou ty dve logicka jadra zapojena do stejne cache. Kdyz je SMT deaktivovane, tak ma to jedno aktivni jadro dvakrat vetsi kapacitu (nemusi se delit se sousedem). A je jedno, jestli je cache chranena nebo ne.

            Uprimne me tohle zacina trochu unavovat. Obhajujete neobhajitelne a prijde mi jako ztrata casu vysvetlovat zakladni principy, ktere si snadno najdete kdekoliv na internetu (nebo z trochu praxe).

          • Ja nic neobhajuju. O to se snazis ty a ja tvrdim, ze marne. Tady existuji jaksi urcite principy, pres ktere tak trochu „nejede vlak“. A o to hur, kdyz to jako laik neznas, presto se do toho pletes. Tvoje iluze a iluze Stacha a podobnych individui je, ze vse lze skalovat. Jenze nelze. Existuje neco jako Universal Scalability Law, ktere popisuje limity a momenty, kdy uz dal scalovat nejde:

            http://www.perfdynamics.com/Manifesto/USLscalability.html#tth_sEc1.1
            (ktere stavi na a rozsiruje Amdahlovo zakonu https://en.wikipedia.org/wiki/Amdahl's_law )

            Precti si to a pak se bavme dal. A dej to i Stahovi, at vidi jaky je to sasek.

          • Kdyby existoval „univerzální zákon škálování“ a fungoval pro všechny programy, tak by byl svět o hodně jednodušší, než je…
            Každej kód se v tomhle chová trochu jinak.

            BTW, když vidím ty debaty o škálování výkonu s hodně jádrama, o schedulerech v OS a tak podobně, tak jsem si vzpomněl na tohle: http://www.redditmirror.cc/cache/websites/x264dev.multimedia.cx_dbuko/x264dev.multimedia.cx/indexf427.html

            Bohužel ty posty na Doom10.org a linky na ty benchmarky umřely, ale byla to reálná věc (pamatuju si, když se to aktuálně řešilo). Scheduler v Linux se snažil být moc chytrej nebo měl nějaký jiný problémy a zabíjelo to výkon x264 s více jádry pod Linuxem (a to se bavíme o roku 2009, takže míň vláken, než dneska) prakticky násobně.

          • @JanOlsan

            Ale to je presne moje pointa. A je to pointa i tech zakonu. Vsechno nemuze skalovat do nekonecna. Zalezi na druhu ukolu, kdy se skalovani prestane projevovat nebo dokonce zacne brzdit.

            Zatimco Stach a ta cela jeho banda vcetne tady mileho del42sa tvrdi opak, ktery nemaji nicim podlozeny. Snazi se svym ovcim vsugerovat, ze to je chybejicimi optimalizacemi pro vice jader. Jenze takhle to nefunguje. V dnesnich programovacich modelech je vicevlaknovy software automaticky. A vyvojari nejsou imbecilove, ale naopak velmi chytri lide, takze asynchronne programuji standartne vsude tam, kde to ma smysl. U vyvoje hernich enginu to plati dvojnasob. Staci si vzit C++ a moderni Win32 a UWP aplikace – pomoci async a await se asynchroni kod resi temer bez prace a delaji to vsichni. Nebo Java a vsechny JVM jazyky, kde se defaultni threadpool nastavuje na pocet threadu automaticky podle poctu jader v systemu (4 jadra – 4 thready v threadpoolu, 8 jader – 8 threadu v threadpoolu, atd.). Pak jsou tu ruzne concurrency frameworky, ktere delaji tuhle praci uplne samy diky jejich navrhu – treba actor-based concurrency (Akka Toolkit).

            Troufam si tvrdit, ze naprosta vetsina software je takhle jiz napsana, s plnou podporou multi-threadingu, nehlede na pocet jader. Jenze nektere typy uloh narazeji na strop skalovani proste pomerne rychle.

            Stach a ty jeho slepicky, to je proste skupina laiku, kteri se vrtaji do veci, o kterych maji nulove znalosti. Pak se do toho prida Soucek, kterej se tvari, ze neco vi (a ma na jeho obranu i dost nacteno), ale principum vubec nerozumi. Oni jsou jak maly deti, chapes? Nejdriv je Ryzen ta nejdokonalejsi vec. Kdyz jim to ostatni omlati o cumak, tak najednou je chyba vsude jinde, nez u AMD – v systemu, v softwaru, v testech, lidi to blbe pouzivaj (zrejme maji pri hrani her vsichni konvertovat video a kdo za jednu hru CS: GO nezkonvertuje aspon dve videa, jako by nezil) .. to je tak smesny az je to smutny 😀

          • nevím kdo a kde něco takového tvrdí ? A kde jsem napsal něco o nekonečném škálování ? A kde vidíš obhajování Ryzenu ? Zase akorát učelově překrucuješ význam abys vypadal chytře, ale řeknu ti, že to nezabírá :-)))

          • „del42sa 6.3.2017 at 14:33
            Ani současný build Windows 10 (1607 14393.693) nedisponuje optimalizacemi architektury Ryzen, tak jak může být testování férové.“

            „del42sa 5.3.2017 at 19:43
            chyba designu to určitě není“

            „del42sa 5.3.2017 at 11:41
            ale já mluvím pouze o SMT ne po threadech obecně.
            optimalizace AMD znamená, že hry musí být NUMA optimized a podle toho nakládat s thready“

            „del42sa 5.3.2017 at 8:42
            vypadá to, že tenhle negativní impact SMT způsobují Windows 10 “

            😀

          • @Maudit
            No, jestli se bavíme o optimalizacích specificky pro Ryzen, tak ty nebudou o tom, že se software přepíše, aby běžel ve víc vláknech. To by byly obecně optimalizace i pro více jádra Intel a HT. Tam, kde mají smysl, se dělají, a poznají to všecka větší CPU, tj. i konkurence Ryzenů (BW-E, Skylake-X).

            Specificky pro Ryzen by mohly být úpravy scheduleru v OS, spravení problémů v tom řízení spotřeby (na straně OS), jestli tam fakt jsou (to, že je větší rozdíl ve výkonu pod „rovnováha“ a pod „vysoký výkon“).

            A pak to, že programátoři aplikací udělají profiling svého kódu, zjistí, že některé parametry/předpoklady třeba na Ryzenu nevyhovujou, změní je, nebo přidají workaround. Někdy to ani nedá moc práce, akorát se k tomu ten programátor musí dostat.

          • a ještě neumíš číst nebo chápat psaný text :-)) děkuji za pobavení !

            1. ta první zpráva ani nebyla ode mě ale je naprosto pravdivá.
            2. mluvil jsem o SMT, kde má Intel pod WIN 10 ve hrách stejně negativní škálování jako Ryzen a které naměřili Hardware.fr
            3. opět jsem mluvil čistě o implementaci SMT a ty do toho naprosto účelově pleteš NUMA a CCX
            4. The Stilt naměřil pod WIN 7 jiné chování SMT než pod WIN10
            https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-8#post-38775732

            Obecně bych řekl, že neustálé návštěvy DDworldu a nutkavá potřeba číst cokoliv Stach napíše ti zatemnily mozek a zdravý úsudek, o kterém jsem měl stejně v tvém případě pochybnosti už dříve. Tímhle jsi potvrdil jsi akorát svoji pověst trolla!

          • Dnes se nepise kod specificky pro procesor. To je totalni nesmysl. Pochopte to uz.

            O CPU-specificke veci se staraji kompilatory (klasicke – C/C++ – i just-in-time u managed jazyku – Java, C#, atd.) a to v dnesni dobe jeste navic nemusi byt vubec specificke pro architekturu. Na urovni procesoru, ale treba i v JVM, se deje spousta veci – hlavne reordering a inlining, branch predikce. Tohle vse je pro programatory zcela umyslne schovano za abstrakce jazyka a deje se to automaticky.

          • Myslím, že se stále píše. Jsou samozřejmě různé druhy softwaru, ale třeba takový FFmpeg, x265, x264 (tj. páteř multimediálních aplikací dneška na serverech i doma) se na míru procesorům ladí.

            Někdy má program fakt víc různejch variant kódu pro různý CPU, např. x264 – MMX(2), SSE2, SSSE3,SSE4, AVX2 (pár funkcí je tam i pro XOP, ale je to minimum). Když se používá ruční asemblér přes YASM, NASM, tak to není až tak komplikovaný. Třeba u toho x264/x265 mají programátoři nástroj, kterej sjede všechny varianty a řekne, kolik cyklů pro tu danou funkci to CPU pro jednotlivé větve potřebuje. Program má detekci CPU, a navolí pak cesty pro jednotlivá CPU podle nějakých pravidel. Obvykle je to jen o tom, že starší CPU používají nižší generace SIMD a novější automaticky i ty vyšší, ale jde tam dát i nějaké výjimky, typu že Core 1 nemá používat SSE2 protože ho má pomalejší než SSE2.

            Pochybuju, že by Ryzen dostával vlastní větve kódu, protože nemá jako Bulldozer nějaké vlastní unikátní instrukce. Ale můžou udělat věci jako zakázat na něm AVX/AVX2, pokud nepomáhá (to se zjistí změřením výkonu s a bez). Případně se dají identifikovat funkce, které se mu nelíbí třeba proto, že některé instrukce trvají dýl nebo mají horší throughput. V takovým případě se ten asemblér může trošku pozměnit, aby chutnal jak AMD, tak i Intelu.

            Tam, kde na tom výkonu záleží jako v těch multimédiích, se tohle myslím docela praktikuje. Rozhodně ne všude, ale určitě není pravda, že se všude nechává všecko na kompilátorech.

          • To je asi tak 0.1% aplikaci, nejspis min. Pouzivat assembler jsem za poslednich deset let snad nevidel. Ma to smysl jen u nekterych uloh, treba in-memory cache (redis, memcache), kde se delaji jen 4 operace (takze kazda z nich ma velky vliv na vykon a odezvu), nebo treba IoT (ale tam to neni o tom, dostat super vykon z naslapanyho cpu, ale dostat aspon nejaky rozumny vykon z totalne anemickyho hardware).

            „Někdy má program fakt víc různejch variant kódu pro různý CPU, např. x264 – MMX(2), SSE2, SSSE3,SSE4, AVX2 (pár funkcí je tam i pro XOP, ale je to minimum).“ Tohle prave dela compiler. Delat to rucne ma smysl jen za velmi velmi specifickych situaci, ktere ale v kontextu Ryzenu vubec neplati. Plati to napr. v momente, kdy nejake CPU prinese zcela novou instrukcni sadu.

  1. Konečně tu ECC někdo zmínil! Už bych dneska nechtěl kupovat nic bez ECC, tím jak se rychlosti pamětí zvyšují a technologie zmenšuje je šance na to že dojde k chybě stále vyšší a protože SSD úložiště jsou celkem stabilní je teď asi největší průser právě operační paměť, u grafické paměti je to fuk, tam vám nemůžou chybná data způsobit chybu při kopírování dat!

  2. Podľa toho Stiltovho merania IPC to nevyzerá na žiadne terno ani v aplikačnom výkone. Výkon v rámci IPC nižší než Haswell ? OMG… Potom ten herný ja na úrovni čoho ? Nehalemu ?

  3. Vypadá to zajímavě, bohužel oc prakticky nula. Uvažuji do budoucna o 1700X nebo 6800K ale počkám až ČNB ukončí intervence a také až slevy Intelu prokapou k nám což také zabere nějaký čas. Nyní moc vhodná doba na nákupy není.

  4. Nevím co se tady vůbec řeší. Ryzen je naprosto ultimativní procesor, který trhá jakýkoliv Intel na kousíčky. A to i ve hrách. Takové i7 7700k se vůbec nechytá. Protože celý svět to měří naprosto blbě, je potřeba mít zároveň s hrou spuštěn nějaký převod videa, browser a ideálně ještě nějakou komprimaci souborů. A okamžitě je Ryzen daleko nejvýkonnější procesor na hry. A další zásadní věci je, že hry a jejich výkon a herní výkon procesoru jsou dvě zcela odlišné věci. Pokud někde 4jádro Intelu překonává 8jádro Ryzen, tak je to jen a jen mizernou optimalizací dané hry.

    • cenově určitě. Nicméně článek na který je naráženo vyznívá opravdu křečovitě. Ryzen je spíš pracovní cpu a ani ve hrách nějak moc nezaostává. Nechápu tyhle vášně – vždyť stejné to bylo s vysocetaktovanými dvoujádry vs pomalejší čtyřjádra. Je jasné že když spousta her je díky konzolím pořád stavěna na starých byť různě aktualizovaných enginech které hlavně vytěžují jedno-dvě vlákna a zbytek jen doplňkově (čest vyjímkám hlavně strategie) takže povede cpu co má vyšší takty. Ale do budoucna to není dobrá investice. ALe každé zboží má své kupce tak proč pomlouvat jak to dělá autor dotčeného pamfletu…

      • Ja musim priznat, ze Ryzen 1700, byt stoji skoro desitku, tak co se tyce nabizeneho pomeru vykon/cena a platforma vykon/cena, tak opravdu nema konkurenci. Jak by mne normalne ani nenapadlo dat za CPU se 4 jadrama 10k, tak tady to tam, protoze ta hodnota a vyuziti vzhledem k tomu, co tady posledni par let, je uplne nekde jinde.
        Specialne pro Maudita.. to se budou delat konverze videi 😉

  5. Je to jednoduché – kdo pracuje s editací videí, či v nějaké pracovní věci potřebuje velký výkon tak Ryzen R7 je skvělou konkurencí vůči předražené platformě Intel 2011. Stačí deska za 2,5 tisíce a CPU 10-15tisíc a je výkon stejný jako u Intel 5tisíc za desku + 13-30 tisíc za cpu.
    Co se týče her nemá smysl vůbec R7 AMD řešit – na hry teprve bude mít smysl 4-6jádrové R5, které budou velkou konkurencí k nejprodávanějším I5.

  6. https://community.amd.com/community/gaming/blog/2017/03/13/amd-ryzen-community-update?sf62107357=1

    shrnutí od AMD:

    -win 10 scheduller je v pořádku, změny oproti WIN 7 jsou dány architektonickými odlištnostmi obou systémů
    -AMD SMT implementace je v pořádku
    -je doporučeno mít zapnuto ve nastavení profilů napájení „power performance“ protože je vypnutý core parking a dochází k rychlejším změnám frekvencí u CPU
    -negativní impact v některých hrách se zapnutým SMT bude AMD řešit „patchem“ her/API