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.
Napadlo mě to hned po nedávném článku. Není tohle důvod proč zmizel Threadripper 3000 z roadmap? Že postrádá smysl když teď dokážou dát 16 jader při lepším IPC do AM4 patice ?
Threadripper môže v rade 3000 vyplniť 16-64 jadier
A neide len o jadrá, niekto potrebuje viac PCI Express liniek, ktorých má AM4 z CPU 24, TR4 ich má 64
Tiež je tu prípadná potreba vyššieho množstva RAM, kde AM4 má maximum 64GB, možno keď prídu 32GB moduly a zvládne aj to, tak 128, pričom TR4 dá až 128GB už teraz, do budúcna 256GB.
Takže podľa mňa má TR4 stále svoje opodstatnenie
Vidim to tak, ze TRipper zase casem bude, pokud AMD prinasel penize. Tim myslim, pokud to melo dostatek zakazniku. Otazku bych videl tak, jestli nedokazi pokryt trh jen dvojici RyZen+Epyc, coz urcite neznamena, ze TRipper nema opodstatneni, ale ten profil zakazniku, kterym nevyhovuje ani RyZen, ani Epyc, nemusi byt prilis velky.
Threadripper nezmizel z roadmap, pouze ho AMD nezařadila do jednoho slajdu, který sumíroval produkty již vydané v letošním roce a nejbližší chystané. Krom Threadripperu v něm není uvedena i řada dalších produktů, které budou letos vydané. Nic to ale neznamená, není to roadmapa.
Pravdepodobne ho vydaji o neco pozdeji nebo zacatkem pristiho roku. Nejspis neni pro ne momentalne prioritou a jejich soucasna nabidka 12-32C jim prijde dostatecne konkurenceschopna.
Pořád budou existovat oblasti, kde čtyřkanál bude mít své opodstatnění i když se jedná o dost specifickou část trhu a paměťová kapacita už je trochu těsná. Ale je pěkné že v běžných aplikacích/hrách se dostali výkonem na stejnou úroveň jako workstation CPU, pro Intel je jistě nemilé muset pozorovat jak se výkon pracovních stanic přesouvá do levného mainstreamu konkurence.
10% narust IPC by byla bomba. Uvidime jak se to ale 'pretavi' do realnych aplikaci :)
10% navic na IPC by byla bomba a navic se zvysenim frekvence by mohl byt celkovy vykon jeste vyssi az klidne k 15% celkove oproti Zen (ne Zen+).
A ted ta druha strana. Uz Zen+ prinesl navyseni vykonu o cca 10% celkove kde cca 5% z toho navyseni pripadlo na IPC. Tim padem se nedostavame na nejake zazracne navyseni vykonu, ale prave jen na cca 5% navyseni mezi Zen+ a Zen2.
Dale je potreba rict, ze tyto vysledky jsou udelany na takrka idealne skalujici multi thread zatezi vyuzivajici vsechna jadra. Uz to nemusi byt tak uzasne v pripade, ze aplikace bude pouzivat omezeny pocet vlaken (coz se porad deje - napr. 8 vlaken max) nebo dokonce jen jedno (To uz je dnes nastesti spis vzacnost a to vcetne her).
Hele, ja mam v pameti Zen->Zen+ cca +3% IPC, a zbytek pak vylepsenyma frekvencema. Ale mozna to zalezelo na typu aplikace.
S tim skalovanim vice jader..podle mne by to platilo v momente, kdy by nejak jeste vylepsili SMT, jinak si myslim, ze jsou ty vysledky aplikovatelne i na mensi pocet threadu, protoze tady se porovnavaji fixni frekvence s fixnim poctem stejnych threadu.
Mám dojem, že už i "jedničkový" TR má oproti Ryzenům pár vylepšení, které Ryzeny dostaly až se Zen+ - nejaké ty latence a tak (podobné jako Raven Ridge)
To myslim ano, ale jeste se TR 1000 rada nepovazovala za Zen+ myslim, ale jen za novou revizi (jeste spise jen stepping vodive masky) puvodniho Zenu.
Zen+ mel navyseni IPC dle aplikace ruzne. Nekde 0 a nekde az 7% zvyseni IPC. V nekterych pripadech to spolu s frekvenci udelalo klidne 10% absolutniho vykonu navic.
Zas to nak nechapu. Co ma spolecnyho IPC s pameti? Pokud je benchmark zamereny na CPU, tak by s pameti mel pracovat minimalne, takze jestli jeden procesor ma 2 kanal a druhej treba 8 kanal by se vubec nemelo projevit...
Asi hodne zalezi, jestli si vystaci s daty, ktere se vlezou do cache a nebo potrebuje aktivne prenaset obri data do RAM. Propustnost pameti to muze a nemusi ovlivnit. Vse zalezi na podminkach testu.
Přesně tak, pokud se ti data vejdou do L2/3 cache, i relativně pomalá RAM není takový problém. Dobrý příklad přináší například starší revize Intel Xeonů, které díky masivní 55MB L3 cache byly schopné překonat na práci s databázemi i jejich o generaci novější bratříčky, které se díky zvětšenému počtu jader tolika L3 cache nedočkaly. Měly sice obecně matematicky větší výkon, ale malá L3 cache jim neumožnila tento výkon pro práci s databází využít. Jakmile se data do cache nevlezou, začne být propustnost a latence RAM alfa omega výkonu a ty rozdíly jsou pak skutečně markantní :-).
mene JADER vic GIGAHERZ
fakt naka 3ghz 16core backora mi je nanic
klidne 8 ale at to jede aspon 4.5
"fakt naka 3ghz 16core backora mi je nanic"
..On nekdo takovy CPU vydava? :)
bager: Ta tvoje cesta nikam nevede, není technicky proveditelné dělat málo jader na tak vysoké frekvenci aby se vyrovnaly, nebo dokonce překonaly naopak technicky proveditelný návrh mnoha jader na nižší frekvenci, která se drží energetického optima procesu. Právě Intel je velmi dobrá ukázka že už není kam dál jít, jejich 200W osmijádra se zdaleka nemohou rovnat 32jádrovým 180W CPU od AMD a o tom to je. Myslím že v příštích generacích Intel vydá stejnou cestou jako AMD, jinudy to s křemíkem stejně nepůjde...
Moje cesta nikam nevede...
Jedine nacem zalezi je single core vykon, protoze 99% enterprise i neenterprise softu nic jineho neumi.
Jedine kde se to da vyuzit je 3rd rendering a encoding videa, pripadne pro twitch thotky.
Zapni si nakej CAD a rekni mi jak ta 3gigaherzova 20jadrova backora dostava naprdel od 5 gigove i5ky z roku 2016.
Pokad nedorovnaj ingle core na uroven 8700k a vejs tak je to naprostej krám.
To že něco sám neumíš využít automaticky neznamená že to je špatné. Hardware si vybíráme podle toho na co ho potřebujeme, sám sis tu vyjmenoval dost úloh ve kterých bude zase ta i5 naprostý krám ale zdaleka se nejedná o nějak konečný výčet, ono obecně stačí když se začne spouštět jedna úloha vícekrát :-).
Technicky dnes není možné udělat takový procesor co sis vysnil. To bychom se všichni zastavili na 8 jádrech a 5 GHz o výkonu X protože víc už to nejde uchladit ani masově vyrobit. Ale je naopak technicky možné začít dělat masově CPU o výkonu násobků X tak, že se využije víc jader na nižší frekvenci a dá se to jak vyrobit tak i dobře uchladit.
Jj. single-core výkon je většinou nejdůležitější.
Netýká se to jen nějakých "velkých" aplikací typu CAD, ale i obrovského množství "serverových" úloh. Například souborové servery, kde je latence a i rychlost velmi závislá na single-core výkonu. Dtto databázové servery, síťové aplikace (pomalejší jádra způsobují velkou latenci a tranzitní zpoždění)...
Vykon na jadro je urcite dulezity vzdycky, akorat ze nikam dal neskaluje. Tvuj priklad se servery je pravdivy jen castecne. Na serverech mas velkou cast uloh (rekl bych vetsinu), kde hlavne potrebujes mit nejlepe v kazdem okamziku volny "resource", kam ti scheduler priradi dalsi request a celkove soft/architekturu, ktera ti to dokaze takhle kocirovat. Cili, cim vic jader tim vic adidas a to jestli ma to jadro u toho 2,5Ghz a nebo 3Ghz nehraje v principu moc velkou roli...
V nejake narocne ST uloze, to samozrejme mit vliv bude, ale obecne servery jsou delane prave masivni MT zadez s velkym poctem requestu nez na nejake ST ulohy...
Serverové OS i aplikace jsou konstruované ne monoliticky jako balvan ale jako lavina kamínků. Je pak mnohem snazší využít víc jader a přitom ty jednotlivé komponenty nepřesáhnou nějakou míru náročnosti, takže systém pěkně běží i v případě, že nemáte maximální frekvence na jedno jádro - už se s tím dopředu počítá. A tam, kde se vyžaduje skutečně vysoký výkon na vlákno se používají počítače, které dovedou využít mnoho procesorů jako jeden. S PC samozřejmě nemají nic moc společného a jejich cena se v základu počítá na miliony dolarů. Jo a Intel je nedělá ;-).
Ja myslim, ze jsme oba napsali vicemene to stejne ;)
Já reagoval na toho pána nahoře, s Tvým příspěvkem souhlasím :-).
Dělal jsi to vůbec někdy, myslím na serverech? Zjevně ne, protože jinak bys takovou pitomost nemohl tvrdit. Jojo, chápu, že takové blbé pindy se hodně píší v časopisech a různě na netu, ale...
Není to prostě pravda, není totéž mít v serveru třeba 8 jader na 4 GHz nebo 16 jader na 2 GHz. V případě rychlejšího jádra trvá zkrátka vykonání třeba 10 tisíc instrukcí 2x kratší čas, tím je obsluha 2x rychlejší, jelikož ohromné množství věcí je stále napsaných jednovláknově a i když ne, tak paralelizace nesahá výše než na pár vláken. Příkladem jsou transakční databáze, webové servery, souborové systémy... téměř všechny serverové úlohy. A to i systémové - například obsluha SATA, SAS disků při čtení/zápisu jsou desítky tisíc instrukcí a rychlost jejich provedení je vpravdě kruciální...
Není to bohužel tak, že by se každá úloha rozložila na větší počet pomalejších jader...
Na tomhle prostém faktu ztroskotaly "Buldozerové" AMD Opterony - server s celkem 64 jádry byl celkovou propustností katastrofa, proti 8-jádrovému Xeonovému s mnohem vyšší IPC... sice by obsloužil např. v OLTP úloze databázového serveru stejně nebo i více úloh, ale pomááááálůůůůůůůůůůůů.
Koukam, ze pan je expert a ze si z toho vybere dokonce i to, co tam ani nebylo..:)
A ano, dokonce jsem drive navrhoval a i kouskem psal back-end cast aplikace pro jeden client-server enterprise system, ktery byl schopny skalovat prakticky neomezene s poctem threadu. Jeho limitace byla spis uz jen schopnost DB (se vsim co k tomu patri) reagovat na pozadavky a request dispatcher. V dobe, kdy jsme ten system navrhovali, bychom nekomu byt jen za 1 socketovy 64T server utrhali ruce a bylo by uplne jedno, jestli jede na 3 nebo dokonce 4Ghz..protoze nejuzsi misto systemu byva tradicne stejne pristup pres sit..
Jinak zkuste si precist ten prispevek znova, nikde neporovnavam 2Ghz vs 4Ghz, ani 50% nizsi IPC, jako v pripade Bulldozeru.. Nikde ronvez netvrdim, ze vyssi vykon na jadro neni vyhoda, nicmene u spousty uloh ten vyssi vykon na jadro neprinese ani zdaleka tomu umerne zrychleni vysledne ulohy. Dale Vam nejak z tech vasich uvah vypadlo to, na cem dneska servery stoji a to je virtualizace, ale to by se Vam asi nehodilo do kramu. Pouziti napr. vice instatanci jednoho systemu, pouziti EE s JVM, atd...podle mne jste si vybral jeden nejaky svuj specificky priklad a nebo jednoduse placate protoze si asi neumite predstavit backednovou cast serveru jako celek, ktera je slozena z dilcich casti, kdy jednotlive casti maji treba sva specifika....
Mozna by jste mel na zaver rict vyrobcum HW, ze to delaji blbe, protoze Intel dela 4 socketove system, AMD zatim jen 2 socketove (zato s 128T)..tipnul bych si, ze vyuziji asi tak 3 jadra a zbytek je tam pro paradu, protoze to nepojede na tech 4Ghz... ;)
"paralelizace nesahá výše než na pár vláken"..tenhle prispevek si schovam :)
Sorry vic na tenhle prispevek nebudu reagovat, neb mi to prijde dost plana diskuse..
Nj soudruh se možná přichomýtl k situaci nebo viděl benchmark kdy taková specificky jendovláknově napsaná úloha běhala na 8jádrovém vysoko taktovaném Xeonu rychleji než na 4 kusech Bulldozerů. Jaké překvapení. Doufám že to taky pouštěli na windows, ty jsou "móóc efektivní systém" na takové 4CPU konfigurace... Ale už se asi nepřichomýtl k situaci kdy 64vláknová aplikace běžela na 64 obdobně výkonných jádrech oproti 8. Bulldozer je IPC nevýkonné CPU a dnes už 6+ let stará architektura, tu už asi nikdo moc nepoužívá. Tenhle typ úloh taky Opteron nejhůř zvládá, to CPU je dělané na mnoho vláken, ne na pár.
Měl by s Xeonem srovnávat Zen Epyc, to by asi to IPC vypadalo jinak. Případně fyzicky Zen 2 64 jádrový Epyc Rome s dále vylepšeným IPC, ten už bere Xeony rovnou dva :-).
Hardware se navíc kupuje na typ úloh co se řeší, univerzální CPU neexistuje. Koupit pomalé mnohojádro na jednu úlohu je blbost, stejně tak nataktované osmijádro na potřebu běžet 128 tasků naráz. Náklaďák Formuli 1 nepředjede ale do formule se nevejde 10 tun kamene...
Když neumíš argumentovat - nebo argumenty nemáš, a hnedka skáčeš k ad hominem žvástům o "soudruhu", doporučoval bych Ti navštívit psychologa...
Všechno, co jsem psal bylo, že vysoké IPC a frekvence jsou velmi důležité i u serverů... a u většiny serverových úloh. Takže při nákupu serverů je rozumné jít po co nejvyšším IPC a nejvyšší frekvenci, na úkor počtu jader (pokud se ovšem zrovna nejedná o ryze speciální aplikaci, která je schválně psaná tak, aby to bylo jedno a škálovala s počtem jader bez ohledu na výkon jednotlivého vlákna). V dnešní době je nejlepší koupí nějaký ten výše taktovaný EPYCový server, ovšem záleží také na ostatním většinou korporátním okolí, které mnoha různými triky nutí dál kupovat Xeonové stroje - protože na EPYC "není certifikace", "nevíme co ty mainboardy udělají", "mají v tom už vychytaný BIOS", "nemáme EPYC v investičním plánu" atd. Holt to bude ještě tak rok dva trvat, než se podniková sféra "chytne" AMD.
Obávám se že k ad hominem útoku jsi si odskočil hned na začátku debaty sám takovou tou přátelskou zmínkou o intelektuální a znalostní nedostatečnosti všech a všeho okolo.
Klasik praví, že čím míň člověk ví, tím mu to je všechno jasnější. To jen ten pitomej profesor se pořád škrábe na čele.
Při nákupu serveru musíš hlavně zvažovat na co ten server budeš používat, pak ti už odpovídající konfigurace sama přistane ladně na stole. Žádný univerzálně platný postup neexistuje. Takže slepě preferovat malý počet vysoko nataktovaných jader je hloupost. Takové CPU se hodí jen na velmi úzkou skupinu úloh a celý koncept takových CPU už je dnes hardwarově i softwarově překonaný protože už je s možnostmi technicky na konci cesty a software dnes více a více umí používat mnoho jader paralelně pro jednu úlohu, čímž jedno byť rychlé jádro ztrácí svou výhodu vyššího výkonu a o to palčivěji tě pak brzdí malý počet fyzických jader co máš k dispozici.
S virtualizací je to naprosto stejné jako se vším jiným. Přehazování kontextu (tj. přepínání procesů nebo i celých virtuálních strojů) na jádru je minimální overhead (a dokonce je menší, když je méně jader s vyšším IPC/frekvencí). Pořád platí, že "rychlejší mlýn rychleji mele". Pochopte, že nejde pouze o jakýsi celkový výkon serveru, ale také - a to velmi významně - také o rychlost/latenci každého toho jednotlivého tasku. Jestli zákazník čeká na odpověď na svůj HTTPS požadavek 200 ms nebo 50 ms. Ukažte mi nějakou například s PHP backendem napsanou stránku, která je udělaná paralelizovaně, aby jela na mnoha vláknech... jo, dílčí věci ano, ale celkový průchod tou úlohou je stejně jednovláknový. Podobně i databázové aplikace - je pěkné, že RDBMS engine je multi-threadový do alelujá, ale stejně každý jednotlivý SQL dotaz má určitý čas zpracování a ten je významně ovlivněn právě IPC/frekvencí každého jádra. Ve výsledku to může rozhodovat o tom, zda je to vůbec použitelné či nikoliv (je fůra úloh, kde se požaduje co nejrychlejší odpověď a nejde to oblbnout žádným cashováním nebo dalšími triky).
Prostě z praxe tvrdím, že i v té serverové oblasti je - mimo speciální případy skutečně paralelizovaných věcí, třeba u různých typů vědeckých výpočtů - výkon na jádro (IPC a frekvence) naprosto základní věc, která se nedá ničím obejít. Týká se to všech možných použití, virtualizaci nevyjímaje.
Nezlobte se, ale mate hodne zuzeny pohled na vec a nektere vase arguenty jsou dovedeny skoro az ad absurdum. Servery jsou delane predevsim pro uspokojeni velkeho poctu requestu. Napr. pokud mate 100 concurrent uzivatelu, tak je opravdu jedno, jestli ma to jadro 3 nebo 4ghz. Pokud to neumite rozhazet na co nejvic volnych threadu, tak vam ty pozadvaky budou akorat viset ve fronte a je opravdu fuk, jestli se ta uloha vykona o 0.2s rychleji nebo ne, protoze ta fronta Vam to kompletne zazdi a vy naopak potrebujete frontu mit co nejmensi, potazmo zadnou. To jak to rozhazovat na co nejvic volnych zdroju zavisi podle typu, o jaky system se jedna. Nicmene obecne plati, ze pro kazdy novy request je dobre mit volny resource a tady Vam vysoke frekvence oproti volnym prostredkum moc nepomohou.
Rovněž se nezlobte, není proč, jde jen o odbornou otázku.
Samozřejmě, že věc je poněkud složitější, protože jde - jak píšete v případě třeba Java EE aplikací - také o další věci, třeba počet theadů a formu jejich správy, nastavení plánovače, v hlubší úrovni i jak s tím železem zachází hypervisor atd. A o ladění celého toho škálování - tj. jak a zda se nějak nastavuje jádrová/vláknová afinita a podobně. Rozhodují kolikrát maličkosti (často i různé implementační vlastnosti/chyby - třeba afinita virtualizované periferie k fyzickému jádru/vláknu atd.), je to zkrátka skutečně složité.
Ale k meritu věci - říci, že u serverů na IPC a frekvenci nezáleží, prostě není pravda. Záleží na tom, a to že hodně.
"Ale k meritu věci - říci, že u serverů na IPC a frekvenci nezáleží, prostě není pravda."
..ja si nepamatuji, ze by nekdo neco takoveho tvrdil, pouze vy jste se toho chytnul ;)
Nicmene k meritu veci...pokud udelam zjednodusenou idealni ulohu, ve ktrere budu prijimat 30 pozadavku soucasne, ktere mi SW idealne rozhodi do 30 threadu, tak co si vyberu.. 8C na 5Ghz. ktere bude jeden pozadavek zpracovavat 1s nebo 32C na 3Ghz, kde 1 pozadavek bude trvat 1,65s....samozrejme tech 32C, protoze je obslouzim v jednom "cyklu" za 1,65s, kdezto ten turbo 8C bude potrebovat 4cykly tudis cca 4s ..a o tom to v obecne rovine je, zbytek jsou specificke pripady, presne naopak, nez to tvrdite vy :)
Myslím jako každou z těch úloh. Takže v tom příkladu s OLTP by třeba odpověď na každý jednotlivý SQL dotaz trvala na Opteronovém serveru 0,8s, ale na Xeonovém 0,2s. Při stejně rychlých discích a celkové konfiguraci. Nebo v případě diskového fileru pro virtualizační farmu, kde to musí běžet z bezpečnostních důvodů jako blokované transakce (tj. s potvrzením), je pak výsledek takového iSCSI/NFS serveru s rychlejšími jádry třeba 4x rychlejší, jak do propustnosti (rychlosti přenosu jednotlivého bloku/souboru), tak co se týče latence. I když, v celkovém součtu, může být celkové číslo přenesených MB/s stejné (ale není, protože rychlejší jádra jsou prostě výhodnější, jelikož paralelizace těchto systémových věcí není velká, respektivě se jedná o návazné operace, které na sebe stejně musí čekat).
Sorry, vy si porad premyslite v nejake svoji skatulce. Mozna mate predstavu jak skaluje nejaka RDB v urcite konfiguraci, nicmene ja se bavim o serverovem reseni jako celku a obecne o serverove platforme a skalovani takove platformy. Jinymi slovy ja mluvim o jabkach, vy jste si vybral pro Vas zajimavou hrusku...myslim, ze pokracovani diskuse bude neplodne..
Hezky vecer :)
Každý má nějakou tu škatulku :-)
Ale je to prostě tak, jak jsem napsal. Kdybys měl pravdu Ty, tak by všude v datacentrech byly nějaké masivně mnohojádrové ARM-core mašinky, s tisíci jádry... ale nejsou. Jsou tam většinou Xeonové servery, s co nejvýše taktovanými jádry (i na úkor celkového počtu jader). A nyní bude (jakmile si korporáty "zvyknou") všude obrovský boom těch AMD EPYCů (a troufám si tvrdit, že nejlépe půjdou na odbyt ty procesory na nejvyšších hodinách, i na úkor počtu jader - z výše uvedených důvodů).
Nezlobte se, ale pisete uz nesmysly. Ja se nebavim o ARM jadrech, byt ty by treba nekde fungovali v klidu taky.
Myslete si co potrebujete, ale EE Serverove aplikace se urcite nenavrhuji podle Vasich predstav :)
Ono do toho kecá ještě jedno... sice je hezké pořád tvrdě stát na těžkém ST výkonu, jenže ono to IPC tak rychle neroste, dokone se zjistilo u intelu, jakou daň si to vybralo a IPC nejvíce rostlo spolu s frekvencí. Architektonicky lze samozřejmě nějaké ty procenta nahnat, ale jde to mnohem hůře a rezervy se hledají zkrátka těžko. Tudíž lze tvrdit, že jsme v případě IPC na pomyslném maximu a jedinná rozumná cesta je, hledat jak SW paralelizovat, protože je to podstatně snažší a levnější. Navíc honit křemík na vysokých taktech stojí také nemálo prostředků (energie, kterou si cucne ten křemík, energie, kterou si cucne klíma). Takže z pohledu vývoje a technologických limitů je rozhodně moudřejší jít do vyššího počtu vláken, čehož si jsi taky vědom, bohužel to nedochází každému. Tenhle fakt už vybublal dávno v dobách netbuřtu a následně i buldozeru.
Prosim o jaky databazi se bavis? MySQL? My se tu na Sybase/Microsoft/Oracle pohybujeme blizko stovky jader na jednom serveru (RAM v jednotkach TB a uloziste v desitkach TB) a zadny problemy s propustnosti v procesorech nemame. To uz spis mame problem u jednoho serveru s operacnim systemem (Solaris), ze kvuli chybe nezvlada ty tisice threadu co tam bezej vzdy obslouzit.
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.