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!
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.
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.
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
Tak prvni optimalizace pro hry je tady:
AOTS dostal Ryzen optimalizacni patch na verzi 26118. narust vykonu dle nastaveni a pameti od 17-31%. Vykon skoro na urovni Intel 6900 :)
https://www.pcper.com/reviews/Processors/Ashes-Singularity-Gets-Ryzen-Performance-Update
To ze Ryzen podporuje ECC UDIMM je skvela zprava, to, ze to nikdo zatim nevalidoval je zprava spatna. Z tohoto pohledu to tedy vypada, ze zatim zadna deska neni tridy pracovni stanice (zadna oficialne nepodporuje ECC), ale vsechny jsou tridy nadseny hrac. Z pohledu uzivatelu prac. stanic tedy cekani jeste neskoncilo...
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...
vypadá to, že tenhle negativní impact SMT způsobují Windows 10
https://forums.anandtech.com/threads/ryzen-strictly-technical.2500572/page-8
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 ;)
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.
Parada! Ale jen na prvni pohled. Pak se clovek koukne na desku a je tam skutecne ECC ale s *, coz je poznamka ktera rika "*Please refer to Memory Support List on ASRock's website for more information." skvele, takze se clovek koukne do "Support" sekce a tam je jen "CPU Support List". Tak si to da clovek vyhledat (http://www.asrock.com/support/index.us.asp?Model=memory+support+list) a ono to vyplivne "Sorry, no data." -- tolik tedy k ECC podpore na Asrocku. -- testovano na desce Asrock X370 Taichi. -- dle meho to chce proste trosku casu na usazeni....
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.
Ani současný build Windows 10 (1607 14393.693) nedisponuje optimalizacemi architektury Ryzen, tak jak může být testování férové.
http://pctforum.tyden.cz/viewtopic.php?p=9244281#p9244281
@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.
MicroCenter je zatím vyjímka, kterou citují všechny AMD fan weby, nicméně zatím nic moc nenasvědčuje, že by mělo dojít k nějakým oficiálním větším slevám. Prozatím jen obchody zlevnily o pár procent, ale to může být i třeba již určitou nasyceností trhu, či uvolnování skladů jednotlivých obchodů.
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 :D
"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 "
:D
@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.
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.
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!
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.