Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Neni, ne, neni, neni neni.
Tak asi takto se tu se mnou fanousci AMD hadali a vztekali se, kdyz jsem napsal, ze R5 1500X a R5 1400 nejsou nijak zvlast vyhodne procesry a u AMD se jednoznacne vyplati predevsim R5 1600 a R5 1600X.
Pravdu jsem jako vzdy podle fanousku AMD nemel, az na to, ze druhy den zverejni no-X graf, ktery jasne ukazuje, ze nejvyhodnejsi procesory (nejlepsi pomer cena/vykon) jsou R5 1600 a R5 1600X.
:-)
jenom redmarx je schopnej napsat dva posty po sobe, co si odporujou.. ((: v jednom vyvracis vyhodnost r5 1500x na zaklade multithread testu a hned potom ve druhym tvrdis ze pro lidi je dulezitej pomer cena/vykon v singlethreadu.. kdyby ses pritom aspon zvladnul zamyslet, tak pochopis, ze prave r5 1500x lidi kupujou kvuli nejlepsinu pomeru cena/singlethread vykon mezi ctyrjadrama (:
Opatrně, nebo ti rupne cévka... :)
Vubec ne, ja se narozdil od priznivcu AMD nevztekam, me ta situace co ted je spis bavi. :-)
Kolem čtu celkem rozumný argumenty, ale pokud tě to baví...
Mě se tedy jeví situace nadmíru příznivá, nechápu, proč bych se měl vztekat v takto dobře se vyvíjející situaci. Vztekat se můžou jen ti co nedávno nakoupili i7 za původní šílené ceny a musí si teď nějak zdůvodnit, že s pár jádry za vydřidušskou cenu udělali kauf. :-D
Příspěvky tohoto exota je nejlépe ignorovat :)
Jinak samozrejme jeden test nedela vykon procesoru a napriklad u her (prumeru z vyrezu ruznych her) je stale nejlepsi i7-7700K, ktery je nejlepsi jak absolutne, tak i v pomeru cena/vykon.
Nijak samozrejme nesnizuju vykon a vyhodnost koupe TRipperu pro aplikace, ktere vyzaduji multithread. Tam neni moc co resit, jiste to ale nebudou nejake domaci herni PC.
4-jadro je dnes pre hry ideal, ale to dlho platit nebude, viacvlaknova podpora je dnes najschodnejsia cesta, takze za 2 roky bude 4-jadro aj pri hrach brzdiaci low-end a s Ci7 7700K sa mozes ist dat vypchat, pokial nepojde na 6-7-8 GHz aby dohnal 8-jadrak
Pred rokem mi fanousci AMD tvrdili, ze za rok bude svet plny DX12/Vulkan her a zatimco jim bude zrat Polaris jak vino, tak GTX1060/1070 budou nepouzitelne.
Jak to dopadlo vime, DX12/Vulkan hry nikde a Polarisy skoncily ve strojich tezaru.
Tady to bude podobne. Myslim, ze ten potrebny vicevlaknovy vykon prijde tak za 4-5 let a tou dobou budou i majitele i7-7700K zvazovat upgrade.
Fakt ale je, ze majitelum i7 Ivy Bridge, Haswell, Skylake se upgrade vubec nevyplati a klidne mohou jeste ty 4 roky zustat na stavajicim a az potom nasadit mnohojadrovy RyZen, TRipper nebo neco od Intelu, co tou dobou bude. Urcite bych nekupoval Skylake-X, ten moc povedeny neni, to uz radeji urcite AMD procesor.
hele, prober se.. tohle je diskuse o threadripperu, ne o tvejch nazorech na polaris.. (:
diskuze je sice o něčem jiném, ale obhájci AMD stále tvrdí +- to samé a o tm byl řeč. 16c/32t využje jen pár lidí, to je prostý fakt. Víc než 4 jádra také není nic co by většina uživatelů PC potřebovala. Až tady bude doba kdy hry využijí víc než 4 plnohodnotná jádra a čtyři thready, tak tady budou dávno jiné CPU
tema: threadripper za 799 je v multithreadu rychlejsi nez hedt za 999
Redmarx: ale polaris blablabla
JirkaK: ale ctyrjadra stacej blablabla..
proberte se..
'' obhájci AMD stále tvrdí ''
no realne jsi jedinej, kdo tu o tom mluvi.. (((:
zvlastne, ze ja vyuzivam pri WH total WAR 8 jadier, hmm(btw, vacsina pouzivatelov, co to je? skor sa bavme o vacsine hracov )
„16c/32t využje jen pár lidí, to je prostý fakt.“
On procesor s cenovkou 999 dolarů asi nebude produkt pro masy :-)
Ano, dopadlo to tak, ze dnes je RX480 o 10% vykonejsi nez GTX1060 i pres nizsi porizovaci naklady. Na zacatku byla RX480 o ~5% pomalejsi az stejne. RX580 jeste par procent navic pridalo, ale za cenu vyssi spotreby. Co se tyka tezeni, tak je to jen dusledek toho, ze AMD grafiky jsou vykonejsi v tehle oblasti.
Pokud nekdo chce na veky veku zustat u 1080p, tak 4C/8T muze stacit, ale bude to kompromis i tam. Prohlasuju, ze lidi se presunou na 1440p a nebo UHD a pak uz to stacit nebude (ja uz na UHD).
Ako súvisí výkon CPU alebo počet jadier/threadov s rozlíšením? Prechod na vyššie rozlíšenie je na bedrách GPU. Na CPU to mať vplyv nebude. Výhoda je ale taká, že s vyšším rozlíšením si môžeš kúpiť výkonnejšiu GPU aj k doterajšiemu CPU s tým, že ho bude CPU stíhať kŕmiť, keďže GPU s vyšším rozlíšením dostane viac zabrať.
„Ako súvisí výkon CPU alebo počet jadier/threadov s rozlíšením?“
S prostým nastavením vyššího rozlišení nesouvisí, ale pokud chce někdo adekvátně rozlišení zvýšit detaily, může dojít k nárůstu draw-calls, což už na procesoru záviset může. Teoreticky se zvýšením detailů mohou přibýt i objekty, které mají nějakou fyziku (řekněme vegetace), což jsou další nároky na CPU. Případně můžu přidat oblíbený argument AMD - pokud někdo streamuje, tak mu s rozlišením obrazu stoupnou nároky na kompresi :-).
JJ. Toto všetko viem. Ale to už súvisí s nastavením detailov, nie s navýšením rozlíšenia. Príspevok, na ktorý som reagoval hovoril, že 4C/8T nebude stačiť na prechod na vyššie rozlíšenia. Citujem:
"Pokud nekdo chce na veky veku zustat u 1080p, tak 4C/8T muze stacit, ale bude to kompromis i tam. Prohlasuju, ze lidi se presunou na 1440p a nebo UHD a pak uz to stacit nebude"
O zmenách detailov nepíše. Tak som predpokladal, že tie zostávajú rovnaké.
Streamovanie je kapitola sama o sebe, ktorá priamo nesúvisí so samotnou hrou, ale s nárokmi daného používateľa. Ak niekto streamuje, musí počítať s väčším zaťažením CPU, ak streamuje väčší objem dát súviasiaci s vyšším rozlíšením.
Tys úplně zcrhovatěl. :-(
Tak zním lidi co upgradovali z 6700k na 7700k a změnu si nemohou vynachváli. Další člověk v minulém týdnu postavil mašinu s 7900X které nahradilo obstarožní 5960X a v klíčové oblasti se mu výkon zvedl o 85%... 10c/20t na stabilních 4.8GHz (běželo mu to i na 5GHz ale chtěl teploty do 80°) dělá svoje.
Tak zním lidi co upgradovali z 6700k na 7700k a změnu si nemohou vynachváli.
a co mali povedat? ze urobili kktinu? :)
divne, ze tym ludom nevadia teploty ku 90stupnov, vsak
Někdo upgradoval CPU na novější, výkonnější a je spokojený. Panebože to je mi ale překvapení...
Jinak tvoje nadužívání slova "klíčové" už začíná být trochu otravné.
přesně, proto používám slovo kruciální a je klid )))
Jenže jsme naprosto v jiné situaci
Do konce roku nás čeká:
1) Threadripper
2) Skylake - X
3) 6jádrové Coffee Lake v mainstreamu, a to nejen i7, ale i relativně levné i5! A dokonce pro výkonné notebooky
4) 4jádrové ULV i5 a 4c/8t i7 pro ultrabooky
5) 4jádrové (8t?) Ryzen APU pro ultrabooky
6) možná i nové 6jádrové Cannon Lake pro notebooky
Tohle prostě vývojáři nemohou ignorovat.
Psát parallelně je relativně snadné delší dobu (klíčové slovo thread), poslední dobou hodně snadné. U herních enginů online-ovek nevím (myslím herní logiku, ne grafický engine), tam to asi bude trošku horší, aby se to potkalo vše ve správný okamžik (client-server-client.extN-obrazovka). DX12 je na Scorpiu, stejně jako Vega, stejně jako je Vega v iMac Pro atd. Vulkan je pravda trošku pozadu oproti předpokladům. Taky scénář adopce je 1. DX12/Vulkan 2. Herní engine builder (Unreal, Source, blabla nevim co ted je aktuální) 3. Hra samotná. Takže ty dva roky minimálně sucho, ale pak to bude průtrž mračen (rozuměj každou chvíli).
Paralelizovat nějaký task je otázka jednoho "odstavce":
https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/da...
"Paralelizovat nějaký task je otázka jednoho "odstavce""
Zatiaľ som neprogramoval kód využívajúci viac threade-ov, ale také ľahké to podľa mňa celkovo nebude. Samotná implementácia zrejme naozaj dnes náročná nie je. Ale analýza toho, čo môže byť paralelizovateľné a ako a následne premyslenie konštrukcie kódu predtým ako sa niečo napíše, nebude jednoduché. Plus otestovanie samotnej implementácie a jej odladenie býva tiež kapitola sama o sebe. Niektoré chyby nie je žiadna sranda hľadať v klasickom kóde a nie ešte v multithtreade-ovom. Ono v učebnicových príkladoch, na aké je uvedený odkaz, to vyzerá jednoducho. Programátor si vytvorí sieť s určitým počtom thread-ov, určí funkciu či metódu triedy, ktorú majú vykonávať. Na konci zavolá Join a je to. Lenže takéto príklady neriešia niečo ako prístup k zdielaným dátam, cache misses a podobne. Proste aby celý príklad fungoval efektívne a mal naozajstnú výhodu oproti sekvenčnému spracovaniu. Bolo by fajn, keby niekto, kto toto riešil napísal stručne akú náročnosť toto všetko predstavuje.
Co takhle neplacat o cem nic nevim a proste to zkusit? :)
Vicemene jedinej rozdil mezi single a multi-thread aplikaci z pohledu programovani je prave synchronizace dat mezi jednotlivejma threadama a ta se da resit velmi jednodusse pres IPC prostredky dostupny v danym jazyce. Ja multi-threadove programuju pres deset let a je to tak jednoduchy, ze se to da delat pohodlne i v skriptovacich jazycich, klidne i v bashi. Co se tyce navrhu neni nic jednodussiho. Kdyz vim co ma konkretni program delat, tak i vim jaka cast bude casove narocna at uz z duvodu vykonu procesoru nebo treba synchronich I/O operaci. Pokud nevim, tak to zjistim pri prvnim testu a konkretni cast rozdelim do vic threadu.
Fakt se neni ceho bat. Zkus to.
Ja sa toho nebojím. Raz som to aj vyskúšal a nie s dobrým výsledkom, takže to beriem ako keby som neurobil nič. Popíšem ten prípad. Predstav si polygónovú sieť, ktorá reprezentuje hladinu vody. Nad ňou máš jednoduchý algoritmus, ktorý simuluje pohyb hladiny (prepočítava pozíciu jedného vertexu aj v závislosti na jeho susedoch a spúšťa sa pre každý vertex polygónu). Takže vstupom bola polygónová sieť s dvojrozmerným polom vertexov. V aplikácii, kde som to mal, som si do jej konfigurácie doplnil počet threadov. Na základe neho som rozdelil vstupné pole vertexov tak, aby každý thread spracovával rovnakú časť tohto pola. Dané thready potom spúšťali funkciu so spomínaným algoritmom, pričom jeho vstupom bol aj interval, v rámci ktorého sa mohli po polygónovej sieti hýbať (ako som písal, každý thread mal svoju časť). Na konci somm si počkal kým všetky thready ukončia prácu (cez join) a ich konečný výstup som nechal zobraziť. Takto nastavené som to otestoval s jednym, dvomi, štyrmi a ôsmymi threadami (mám 8 threadový Core i7). Výsledok bol taký, že multithread mi poskytol o niečo slabší výkon ako single thread a bolo jedno či išlo o 2 alebo 8 threadov (čím vyšší bol počet threadov, tým horší bol výsledok). Veľkosť polygónovej siete som vyskúšal od 500x500 do 2 000 000x2 000 000. Problém vidím v tom, že všetky thready potrebovali prístup do určitej časti poľa, ktoré sa ale nemohlo celé načítať do cache pamäte a doplácal som na cache misses. Ale to len tipujem. V tomto som iba začiatočník a skôr nadšenec. Neživým sa tým, takže moje skúsenosti sú minimálne. V podstate som neprišiel na to, kde je problém. A už som sa k tomu nevrátil, pretože som na to využil akceleráciu cez GPU, ktorá mala vynikajúce výsledky. Z tejto skúsenosti sa mi to proste také jednoduché nezdá. Ale možno keby mi niekto poradil a posunul som sa ďalej, hovoril by som inak.
A psal si to multrithreadove nebo multiprocesove? To je dost podstatnej rozdil. Multithreadova aplikace je porad jen jeden process a tim padem vyuziva porad jen jedno jadro. Cim vic threadu tim vetsi overhead takze i tim pomalejsi beh. Multithread aplikace tak pomahaj jen v pripade synchronich I/O (typicky treba browser stahujici nekolik obrazku na strance najednou). Pokud chces vyuzivat vic jader potrebujes to napsat multiprocesove. Pak samozrejme nemas moznost delat nakej join. Musis vyuzit systemovy IPC na synchronizaci dat.
Písal som to multithreadovo (teda podľa toho čo som využíval aspoň myslím) presne podobne podľa príkladu ako uviedol vyššie Hrdina. Využil som túto konštrukciu (toto je príklad z update-u všetkých objektov, na vlnu som použil rovnaký postup, iba som zmenil main funkciu threadov za inú):
-----------------------------------------------------------------
vector<std::thread> threads(muiNumberofThreads - 1); //muiNumberofThreads je konfigurovateľný počet threadov, ktoré je možné použiť
for (UINT i = 0; i < threads.size(); i++)
{
if (uiStartVertexIndex >= objects.mObjects.size())
uiStartVertexIndex = static_cast<UINT>(objects.mObjects.size()) - 1;
threads[i] = std::thread{ &CObjectFactory::UpdateObjects, &objects, dt, game_time, objects.mObjects.begin() + uiStartVertexIndex, objects.mObjects.begin() + uiStartVertexIndex + uiThreadVertexCount, &objects.mUpdateCounts[i] };
uiStartVertexIndex += uiThreadVertexCount;
}
objects.UpdateObjects(dt, game_time, objects.mObjects.begin() + uiStartVertexIndex, objects.mObjects.end(), &objects.mUpdateCounts[objects.mUpdateCounts.size()-1]);
Join(threads);
-----------------------------------------------------------------
Pričom metóda Join(threads) je definovaná nasledovne:
void CThreadFactory::Join(vector<std::thread>& threads)
{
for (auto& it : threads)
{
if (it.joinable())
it.join();
}
}
Pre overenie či to funguje som sledoval zaťaženie threadov v aplikácii Task Manager. Tam som videl vyťaženie toľkých threadov, koľko som si navolil v konfigurácii aplikácie. Tak som predpokladal, že to funguje tak ako má. Ak je môj postup nesprávny z dôsledku neporozumenia toho ako multithreading funguje, rád sa nechám poučiť. Toto bol iba prvý pokus na základe rýchleho prečítania literatúry s jednoduchými príkladmi.
Asi myslis vyuziti virtualnich jader. Tam je samozrejme jeste problem v tom, ze virtualni jadra (kterych je u desktopovyho i7 8) temer nikdy nedokazou zpracovat 8 threadu(instrukci) najednou. V extremim pripade muzou byt i pomalejsi nez 4 jadro bez hyperthreadindu.
Podle popisu http://en.cppreference.com/w/cpp/thread je to spis multithread knihovna ktera umi multiprocessing, coz neni uplne standard v jinych jazycich (napriklad v pythonu je multithreading a multiprocessing resen uplne jinak).
Kazdopadne z takovyhleho kusu kodu tezko posuzovat, kde si udelal chybu. Pro testovani rychlosti je treba si udelat timery na ruzny casti kodu nebo pustit profiler, kterej ti rekne, kde je ten bottleneck kterej to brzdi. Ale to je stejny u singlethread aplikace.
Nikdy som profiler nepoužíval, ale viem o čo ide. Keď budem mať čas, skúsim sa s tým ešte pohrať. Čo sa týka kúskov kódu, myslel som si, že kostra toho ako som vytvoril samotné thready bude stačiť na to, aby sa vedelo posúdiť či používam bežnú alebo nie práve šťastnú cestu. Každopádne vďaka za rady.
Ja v C++ neprogramuju (krome Arduina, ktery vicemene objekty nepouziva, resit tam multithreading nema smysl), ale ta samotna kontrukce vypada v poradku. Ostatne ono tam neni moc co zkazit.
Ja osobne nikdy thready nespojuju. Pokud je resim v GUI, tak je nastartuju pri startu aplikace a oni pak komunikujou pres queue. Pokud resim treba script kterej se pripojuje na stovku serveru soucasne, tak je nechavam psal primo na terminal. Ale nevidim duvod, proc by to nemelo fungovat.
Spis je otazka co presne delaj ty thready. Kazdopadne vidim jen dve moznosti co by to mohlo zpomalovat. Overhead nebo nakej bottleneck. Pokud problem vyresila GPU akcelerace (kde to bezi paralelne vzdy), tak to to bottleneck asi nebude.
Jeste me napada, ze ty posilas do extra threadu ne data ale objekty, coz je otazka co presne s tim ta knihovna udela. Je taky mozny, ze knihovna se snazi udrzet data konsistentni ve vsech threadech a automaticky synchronizovat ty objekty, coz by samozrejme zpusobovalo obrovskej overhead navic. Ono obecne u zpracovanani velkyho mnozstvi dat je overhead objektovyho programovani hodne znat.
Konkrétne z prípadu o ktorom som zo začiatku hovoril išlo o dvojrozmerné pole vertexov, ktoré bolo definované ako vector<vector<TVertex>>. Kde TVertex je štruktúra, ktorá obsahovala niekoľko atribútov ako pozícia, normálový vektor, dotykový vektor, súradnice textúr a pod. Toto pole som si podľa počtu threadov rozdelil na X častí. Do funkcie, ktorú spracovávali thready som potom poslal iterátory začiatku a konca časti z daného pola vertexov, ktorú mal tento thread pracovať. Takže oni reálne pracovali nad tým istým objektom, ale každý thread aktualizovala jednu jeho časť. Keďže sa interpolovala nasledujúca pozícia jedného vertexu aj na základe jeho susedov, tak sa v prístupe niektorých vertexoch ktoré ležali na hranici oblasti, ktorú thread aktualizoval, mohli tieto thready prípadne biť o prístup k rovnakému vertexu. Tu by mohol byť problém. Alebo ma ešte napadlo, že mohlo dochádzať často ku cache misses problému, kedy bolo treba časti poľa vertexov nahrávať a uvolňovať z cache, keďže celý objekt sa tam nemusel zmestiť a to proces spomalovalo.
Jediné, co mě v tuhle chvíli napadá, jsou problémy s pamětí. Špatná organizace dat a paměťových přístupů může program zabít. Pak vám vlákna navíc skutečně nepomůžou. Jak Intel, tak AMD ale poskytují software, který takovéto problémy detekuje. Linux zase poskytuje nástroj perf, který podobné problémy může o něco méně komfortněji najít také. Asi jediná možnost je zde skutečně měřit, nikoli hádat, protože hádat zpravidla stojí zbytečný čas a problém bude pravděpodobně někde jinde.
Skúsim niečo ohľadom toho nájsť. Takéto nástroje som ale nikdy nepoužíval. S profi programovaním som skončil niekedy pred 9 či 10 rokmi. Teraz to mám iba ako hobby a aktuálne sa skôr venujem Unreal Engine-u. Ale aj tak ma to zaujíma, aby som si to zapamätal pre budúcnosť. Dík za radu.
Pokud máte AMD, CodeAnalyst a CodeXL je zdarma. Pokud máte Intel, připravte si peněženku. :)
Mám práve ten Intel. :-)
Musim souhlasit s RedMarxem. Pokud clovek porizuje nejakou techniku, tak by mel vedet k cemu to predevsim bude slouzit.
Jsou testy kde Ryzen opravdu velmi dobre "jede" - jako CineBench, ale jsou testy na kterych mu to vylozene "nejede" - kuprikladu "Office: Chromium Compile (v56) Time" na AnandTechu. A neda se rict, ze jeden z nich by byl synteticky benchmark ktery ma pramalo co do cineni s relalitou.
Cisla:
Office: Chromium Compile (v56) Time:
Core i7 7820X (140W, $599): 3251 sekund
Ryzen 7 1800X (95W, $499): 5295 sekund
To je proste nezanedbatelny rozdil, na Ryzenu dany benchmark bezi 1.6x dele.. Pak je tady vetsi OC potencial Intel procesoru, ktere se opravdu daji docela dobre tlacit >4.5GHz i pres pastu sedivku. Pokud se odvickuje, prepastuje, hodi se tam nejaky solidni chladic a-la Noctua, tak ~5GHz neni vubec nerealna hodnota a to je dalsich 10-20% vykonu navic.
Moc drzim palce AMD, ale pokud Adobe neprekope od zakladu Lightroom, tak zatim, bohuzel - upgrade nebude: https://www.pugetsystems.com/labs/articles/Adobe-Lightroom-CC-2015-8-AMD...
"Jsou testy kde Ryzen opravdu velmi dobre "jede" - jako CineBench, ale jsou testy na kterych mu to vylozene "nejede" - kuprikladu "Office: Chromium Compile (v56) Time" na AnandTechu."
A samozřejmě to testovali na Windows a v MSVC, že? Kolik by to bylo s GCC a v Linuxu? Viz třeba https://www.servethehome.com/amd-ryzen-7-1800x-linux-benchmarks-paying-f... , kde se 1800X dotahuje na duální systémy s 2x8 jádry od Intelu.
------------------ ------------------ ------------------
inak nic prekvapujuce:
A) IPC ma AMD stale o 10% nizsie (ale furt lepsie jak o 50% nizsie)
B) mierne nizsie IPC je parcialne kompenzovane mierne vyssimi frekvenciami AMD CPU, takze rozdiel vykonu na jadro sa este stiera
A+B) z toho potom vychadza ze 10-jadro Intelu ma vykon asi ako hypoteticke 11-jadro AMD, resp. opacne 12-jadro AMD asi ako hypoteticke 11-jadro Intelu, takze logicky 12-jadro AMD symbolicky poraza 10-jadro Intelu
teda tomu najvykonnesjiemu 16-jadrovemu TrhacuVlakien bude vyrovnany super az cca 14-jadrovy Intel, ktory bude mozno troska symbolicky menej vykonny ...... to tu pisem uz cely kvartal - Intel si v HEDT udrzi vykonove prvenstvo jedine s 16- a 18-jadrovym modelom, pretoze vsetko ostatne bude slabsie jak 16-jadrovy AMD Trhac Vlakien
------------------ ------------------ ------------------
mírně vyšší takty CPU? Jen u těch nejvyšších modelů Ryzenu jsou 4GHz a jak víme 4GHz je maximum co ani někteří nedosáhnou pomocí OC. Současné Skylake jde tlačit k 5GHz. ano chce to pořádné chlazení - to stejně všichni mají - včetně vodou chlazené kaskády a ideálně dvěma okruhy - CPU a GPU zvlášť. Nicméně to pro sestavy tohohle typu bývá poměrně běžné.
Jinak naprosto souhlasím s tím že výkonově jsou/budou nové HEDT intely daleko před Ryzeny, jediné co je na ryzenech dobré je cena
Otázkou zůstává, jak daleko bude HEDT před Threadrippery. I s tou vodou chlazenou kaskádou...
Předně bychom si měli položit otázku, co brání AMD zvýšit počet jader pro ThreadRipper stejně, jako Intel na poslední chvíli zvýšil počet jader pro HEDT. Pouzdro TR vychází z pouzdra Epycu, takže má prostor pro až čtyři osmijádrové křemíky. Pokud AMD bude cítit dostatečnou poptávku, může vydat TR v konfiguraci čtyř křemíků, na každém aktivních 6 jader a jeden paměťový kanál, tzn. celkem 24 jader a 4 kanály.
Taky si zapomněl že Ryzen spotřebuje cca 120W ,kdežto 5Ghz Intel 400W ... Což si myslím že se k poměru k výkonu nevyplatí.
Dalším důležitým faktorem je cena ,kdy za cenu intel procesoru máš desku ,paměti a CPU u konkurence.
Nemam vodou chlazenou kaskadu. Ba nemam vubec vodni chlazeni. Co se tyce tveho "vsichni".
-------------------- -------------------- -------------------- -------------------- --------------------
clovece nestastna nevedoma, ja myslim takty pri plnom zatazeni z vyroby (multithread vykon na defaulte) a dokonca nemyslim ani default boost z vyroby (single thread vykon kde ma intel navrch jak v IPC tak vo frekvenciach) .... a uz vooooooobec nemyslim schopnost pretaktovania, pretoze schopnost pretaktovania je uplne ina kapitola !!!!!!!! boze to tu musi clovek vsetko vysvetlovat ??????????????
12jadrak Intel Core i9-7920X, 140 W, 1199 $
base 2,9 ghz / boost pre 1-2 jadra 4,5 ???? ghz
VERSUS
12jadrak AMD TrhacVlakien 1920X, 180W, 799$
base 3,5 ghz / boost pre 1-2 jadra 4,0 ghz
(porovnavam cisla 2,9 a 3,5 . T.J. base pri multi thread full load na defaulte)
16jadrak Intel Core i9-7960X, 165 W, 1699 $
base 2.7 ghz / boost pre 1-2 jadra 4,5 ???? ghz
VERSUS
16jadrak AMD TrhacVlakien 1950X, 180W, 999$
base 3,4 ghz / boost pre 1-2 jadra 4,0 ghz
(porovnavam cisla 2,7 a 3,4 . T.J. base pri multi thread full load na defaulte)
dokoca pri tak nizkej frekvencii HEDT 16-jadraku bude mozne, ze TR 1920X nebude multi thread vykonom iba nad intelovym 14-jadrakom, ale dokonca aj nad intelovym 16-jadrakom a intel si HEDT udrzi JEDINE s 18-jadrakom !!!!!!!!!!!!!!!!!! aj ked vykony 14-, 16- a 18-jadraku budu v full load (t.j. multi thread) veeeeeelmi podobne, pretoze ako stupa pocet jadier 14-16-18, tak klesa frekvecnia pri full load 3,0-2,9-2,7 ghz (https://goo.gl/J23Tv9), takze to bude veeeeeeeeeeeeeeeelmi tesne a vobec nie je jasne, kde zapadne AMD TR 1950X, osobne si myslim ze nastane jedna zo situacii zoradenia podla multi thread vykonu:
a) Intel Core i9 7940X - AMD TR 1950X - Intel Core i9 7960X - Intel Core i9 7980XE
alebo
b) Intel Core i9 7940X - Intel Core i9 7960X - AMD TR 1950X - Intel Core i9 7980XE
(s rozdielmi vykonu v jednotkach percent)
t.j. cele prvenstvo Intelu v HEDT segmente snobskych CPU bude viset na JEDNOM alebo DVOCH modeloch, ci uz iba na intelovom 18-jadraku, alebo pre intel pozitivnejsia sprava ze aj intelovsky 16-jadrak prekona amd 16-jadrak
ked intel vyrobi 16-jadrak ktory pri plnom zatezeni pojde na 3,4 ghz, potom sa ozvi !!!!!!!!!!!!!
spamataj sa, uvedom sa, ze vsetky tie intelove 140 W ultra-mega-brutal-14-16-18-20-22-24-26-28-jadrove serverove xeony maju pri full load brutalne nizke frekvencie od 2,1 po 2,6 ghz !!!!!!!!!!!!!!!!!
-------------------- -------------------- -------------------- -------------------- --------------------
Nevie niekto poradit, kde zohnat dobry chladic na tento CPU ?
Mam masinu s 16c TR (reference board) ale chladic tam dali tak hrozny, ze to neuchladi ani slabu zataz a huci to ako tryskac uz pri pohnuti mysi.
SilentiumPC Fera 3 HE1224 v2
na CZC pisou, ze uz to umi i AM4.
Samozrejme jsou i vykonejsi chladice, ale jsou drazsi. Fera je i pro velke tepelne ztraty OK, ale nasad dva ventilatory. Ten co tam je vyhod a dej bud dvakrat Noctua nebo aspon levnejsi Arctic Fan F12 PWM CO.
'' SilentiumPC Fera 3 HE1224 v2 ''
proc mu doporucujes chladic, co na tr4 socket nejde osadit?
Jo, toto neni AM4 a navyse CPU sa vklada do takeho modreho ramika, ktory sa potom zaklopi do socketu (LGA). Inak neviem kde ludia zobrali ten nazov soketu TR4.. AMD to vsade nazyva SP3r2..
Omlouvam se, neoveril jsem si informaci.
Momentalne pouze Noctua ma tri chladice, ale ani jeden jsem nenasel v prodeji, takze asi jeste bohuzel nejsou nebo mrknout na web Noctua, jestli se nedaji koupit na primo.
---
Edit: za predchozi prispevek, jsem si udelil minus.
SP3r2 je pracovní označení, finální jméno je TR4. Z aktuální tiskovky:
„Ryzen Threadripper will be available worldwide for the high-end desktop market in early August. In addition to the 16-core, 32-thread model previously announced, there will also be a 12-core, 24-thread model available. Both are unlocked, use the new Socket TR4, have quad channel DDR4, and feature 64 lanes of PCI Express. Base clock on the Ryzen Threadripper 1950X 16-core product is 3.4 GHz with precision boost to 4.0 GHz. On the Ryzen Threadripper 1920X 12-core product, the base clock is 3.5 GHz with precision boost to 4.0 GHz.“
A čo takto stará dobrá Noctua NH-D15 SE-AM4 ? ;)
dalsi chladic pro jinej socket nez mumak potrebuje.. chlapi, dneska fakt neni aprila.. (:
Ale figu. Tento chladič bude aj na TR4/SP3. Čaká sa len na vydanie procesoru. Už sú aj predobjednávy.
Mozno bude, ale urcite bude vyzadovat dany mounting kit.
Tento socket vyzera o dost inak, dal by som aj foto, ale mohol by z toho byt pruser.
TR bude ale podstatně větší, nedokážu si představit že ta plocha kterou to dosedá na CPU bude dostatečná.
To je, myslím, dost ošemetné. Není bezpodmínečně nutné, aby chladič kryl celou plochu IHS, ono stačí, pokud bezpečně překryje plochu, kde jsou jádra (resp. křemíky):
http://diit.cz/sites/default/files/amd_naples_epyc_lidless.jpg
Moc nechápu co máš. Jako 16C/32T ThreadRipper na referenční desce? Na adekvátní chlazení je potřeba pořádnej vzduchovej chladič s cenou 1500+ nebo nějakej lepší AiO vodník. CHladič tam dali nejšpíš ten referenční 65W Wraith. No...to je u tohohle procesoru tak na chlazení IO a řadičů pamětí. :)
Wraith by bol este dobry, ale to co tam dali je vysoko-otackovy srot. Navyse fan speed logic je hruza, ta doska je reference board. Ale uz by mala byt na ceste poriadna od ASUS (Zenith) :-)
Uz len poriadny chladic...
Nezabudajte drahi kolegovia, ze vykon a papierovy vykon vs cena nie je vsetko. Dolezitejsie je, ci sucasny mainstream OS od Microsoftu bude fungovat 100%. A dalsia dolezita vec je, ci na tych AMD CPU nebudu padat nejake rozsirene aplikacie z akehokolvek dovodu. Pamatam si davnejsi pripad, ked v hudobnom studiu padali programy od Steinbergu a ukazalo sa, ze je to prave kvoli AMD CPU a nejakej nekompatibility. Takze by som este pockal a predcasne sa netesil. Som zvedavy, ci bude vsetko fungovat OK, napriklad, ked na tom niekto(ci uz to bude vyrobca typu Dell aleo HP) postavi nejaku Workstation, ci s tym nebudu problemy. Osobne by som sa tomu necudoval, keby sa vyskytla nejaka nekompatibilita. Netvrdim, ze Intel je dokonaly a ze ich CPU je "svaty gral", ale aspon vieme, co sa od nich da cakat a ze ked zacne padat nejaka aplikacia, tak to na 99% chyba alebo nekompatibilita CPU nebude.
Osobne by som sa na Workstation s tymito CPU pozeral s velkou nedoverou, keby som take nieco mal mat vo firme...
Kazdopadne, drzim AMD palce a osobne som velmi zvedavy, ci sa teda bude konat velky comeback a ci to dopadne podla zelani AMD.
Tak zatím se našly u Ryzenu jen mušky, takže THr by na tom měl být podobně, nebo lépe. TO Intel dokázala udělat mnohem padavější CPU.
Ale my máme rok 2017.
Navíc to nepadalo kvůli CPU, ale kvůli čipové sadě a chybným návrhům desek pro procesory AMD.
OK, tak budeme mat spickove CPU ale programy budu padat kvoli tejh zlej cipovej sade. Fuj vyrobcovia dosiek.
V konecnom dosledku budeme mat nepouzitelnu platformu. meni to daco na veci?
Bláboly. Čiupové sady byly problém před 10 lety, od nástupu AMD čipsetů jsou problémy minimální.
No neviem odkial beries tu istotu. Osobne si myslim, ze len cas ukaze, ako to bude fungovat.
tobě neukáže protože se budeš bát tak vysolíš za podobnej výkon 1999 USD místo 999 USD
Taky v dnešní době (teď bych nerad kecal) je čipset v podstatě "jen" Southbridge, takže by padaly věci výš (níž) v potravním řetězci - disky apod.
Uz ani ty disky ne. Ryzen je SOCka co ma v sobe i dva sata porty.
No právě nevím, jestli je to stejný čip v EPYCu jak v Ryzenu, Threadripper je dvakrát Ryzen, to je jasný, u novějšího EPYCu si tak jistej nejsem. (ale asi je to všechno pořád jeden čip)
:D :D :D Tak to je síla..
Nějak ignorujeme nedávné (brutální chyby) v Intelích CPU...
Haswell - nefunkční TSX instrukce (mohlo způsobit pád); oprava nemožná (TSX bylo trvale deaktivováno); objeveno až cca rok po uvedení..
Skylake - AVX bug - při specifickém pořadí instrukcí (šance relativně malá, ale žel jsem měl to "štěstí" si bug zažít osobně) dojde ke kompletním záseku CPU
Skylake/Kaby Lake - HT bug (na ten přišli borci ze Debian týmu - Intel o něm už věděl déle, ale neobtěžoval se na něj upozornit.. Asi nechtěl negativní publicitu) - crash celého systému
A to jsou jen ty kritické (v errata ke každé architektuře si můžete přečíst desítky dalších).. AMD má v Ryzenu taky nějaké chybky a budou i v příštích generacích CPU obou společností. Zdá se ale, že s chybovostí je na tom Intel posledních pár let výrazně hůře..
Takže ano - víme, co od Intelu čekat :)
Jo a pokud by 1% pádů aplikací byla chyba/nekompatibilita v CPU, tak bychom byli v prdeli :D
Jeej, nahodou som nasiel na webe ako to vyzera ;-) http://imgur.com/a/W4tjM
ještě najít foto čipu bez heatspreaderu
To radsej nebudem hladat ;-)
Buď jak buď. Zasmrádlý vzduch na trhu s CPU nutně potřeboval provětrat. Sitauce, kdy nová CPU intelu byla drahá jak prase a jen o jednotky procent výkonnější než můj obstarožní haswell refresh byl výsměch zákazníkovi.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.