[ Branimir Maksimovic @ 03.01.2019. 03:00 ] @
Interesantan video.
[ Ivan Dimkovic @ 03.01.2019. 11:00 ] @
Situacija da imas vise NUMA nodova unutar jednog procesorskog paketa (socket-a) je relativno nova situacija na konzumerskim platformamama tj. AMD Threadripper je prvi CPU sa takvom arhitekturom namenjen kucnim korisnicima.

Ocigledno Windows kernel tim i AMD nisu radili dovoljno dugo na peglanju problema. Na dual-socket+ serverskim platformama je ovo matora problematika i u BIOS-ima cak imas gomilu preseta za odredjene aplikacije koji konfigurisu sistem kao NUMA ili UMA, Cluster on Die (Intel) i sl. zato sto nema "one size fits all" resenja. Siguran sam da su Intel i Microsoft radili godinama na tweak-ovanju schedulera u kernelu takodje, ne znam da li je AMD imao takav pristup i resurse, verovatno ne.

Na zalost, ne postoji magicni fix za sve aplikacije - u ovom konkretnom slucaju verovatno postoji bug u Windows kernelu vezan za AMD procesore, ali cak i kad se to resi, pitanje koji je idealan procesor za neki thread na NUMA sistemu je daleko od trivijalnog i u mnogim situacijama OS tu nece umeti sam da se snadje, vec ce sama aplikacija morati da se konfigurise kako treba uzimajuci u obzir topologiju sistema.

Interesantno, bez Hyper-V-a (koji ima performance counter-e koji ti daju hint), Windows recimo nema javni API koji bi prijavio koliko tacno fizicke memorije ima svaki NUMA nod kako bi aplikacija znala kako da balansira workload u slucaju da NUMA nodovi nemaju jednaku kolicinu memorije. Ako si memory-bound, radis neko streaming procesiranje podataka i CPU-ovi nisu "jednaki" (tj. neki imaju manje fizicke memorije ili je nemaju uopste) a ti to ne znas, imas problem, veliki problem zato sto neces moci da raspodelis posao "ravnopravno" zato sto ce neki CPU-ovi pre ili kasnije morati da pristupaju "stranoj" RAM memoriji koja se nalazi na drugom NUMA nodu.

Linux je tu bolji, libnuma daje vise podataka i prakticno ako je developer aplikacije spreman za optimizacije moze je 100% optimizovati da radi optimalno, pod uslovom da je OS svestan hardvera :-) U slucaju bare-metal masina sa korektno podesenim firmware-om to obicno jeste slucaj, ali u slucaju virtualizacije to nije nuzno tacno zato sto hipervizor moze biti konfigurisan da sakrije pravu sistemsku topologiju.

Sve u svemu, mislim da je mix NUMA-e i konzumerskih aplikacija losa stvar za korisnike zato sto donosi probleme koji se na serverskim platformama resavaju rucnom optimizacijom sistema i aplikacija, sto skoro niko od consumera nece biti spreman da radi.

Verovatno cemo imati razne "patcheve" i tool-ove za specificne procesore/aplikacije ali sve je to jedno veliki s*anje IMHO.

Ako hoces 16/32+ jezgara u kuci... dobrodosao u NUMA hell :-)
[ Branimir Maksimovic @ 03.01.2019. 11:13 ] @
"AMD Threadripper je prvi CPU sa takvom arhitekturom namenjen kucnim korisnicima."

E sad, da li to znaci i da sa Intelom ima problema?
[ Ivan Dimkovic @ 03.01.2019. 11:24 ] @
Intel NUMA sistemi su obicno dual/quad/octal socket serverski procesori, ne secam se da je neko prijavljivao regresije u performansama ali, kao sto rekoh, na tim sistemima ima gomila firmware tweak-ova za specificne aplikacije.

Primetio sam interesantan problem sa Windows-om i 4S Haswell E7 Xeon-ima (128 thread-ova) sa mojim aplikacijama - iz nekog razloga procesori iz NUMA noda 0 i 3 ne mogu da izprocesiraju vise od ~50% podataka ako su thread-ovi naterani da procesiraju samo lokalne podatke unutar svog NUMA noda. Ako dozvolis thread-ovima da pristupaju i stranoj NUMA memoriji, onda sve procesore mozes drzati 100% zauzetim ali ni tada to nisu optimalne performanse posto tada procesori sigurno provode deo vremena procesirajuci "daleku" memoriju.

Dalje kopanje sa Linux-om pokazuje da na Linux-u sistem kompletno drugacije prijavljuje NUMA topologiju sto sugerise da mozda postoji neki bug ili u Windows-u ili u hipervizoru koji, mozda, pogresne procesore asocira sa NUMA nodovima pa niti 0-32 i 96-128 zapravo sve vreme pristupaju "dalekoj" memoriji. Tu sam i otkrio Windows problem da nemas API koji bi ti rekao koliko koji NUMA nod ima zaista fizicke memorije posto mi je prva pomisao bila da, mozda, procesori nemaju jednaku kolicinu fizicke memorije koja dolazi do njih.

Nisam imao ni vremena a ni neke motivacije dalje da kopam, 4S sistemi su retkost i cela stvar je cist hobi.

Ali ako sva ta kompleksnost stigne na kucne masine, to ce biti show.

Pazi, sam OS moze samo da nagadja sta tvoja aplikacija pokusava da radi i mislim da nije pametno resenje da se OS previse mesa u high-perf aplikacije. Ok je da OS scheduler rasporedjuje desktop aplikacije i tranzijentne procese kako vec misli da treba, ali nesto sto planira da 100% zakuca procesore... moze vrlo lako doci do konflikta izmedju OS-a i aplikacije ako sama aplikacija isto pokusava nesto da uradi po pitanju performansi.
[ Branimir Maksimovic @ 03.01.2019. 11:56 ] @
Sve u svemu bice interesantna 2019 ;)
[ nkrgovic @ 03.01.2019. 12:18 ] @
Cisto da dodam: Linux kernel ima Numa affinity podesen tako da izbegava pristup "dalekoj" memoriji, do tog nivoa da ce pre otici u swap nego traziti memoriju sa drugog procesora. Ovo zvuci kao redak slucaj, ali nije: Ja sam naleteo sa MySQL-om, ali svaki multi-threaded single-process kod koji proba da alocira vise memorije nego sto ima na jednom procesoru ce imati problem. Ja sam, kazem, probao da u masini sa 128GB RAM-a dam MySQL-u za InnoDB Buffer Pool nekih 96GB - i otisao u swap.

Postoje cak i userland fixes, pokrene se numactl kao wrapper, koji onda pokrece konkretan proces i kaze mu kako da hendluje memoriju. Bez toga, ova moja situacija gore, ako se podesi swappiness na 0 (nije dobro u praksi, ali odlicno za test), moze da se zavrsi tako sto na masini sa 128GB RAM-a jedini proces koji se pokrene, i zatrazi npr. 72GB RAM-a, ako je arhitektura 2xNUMA s 2x64GB, dobije Out of Memory!

Sve u svemu, na Linux-u je problem resiv, ali ako program nije explicitno pisan da to podrzi, onda ce biti problema. Ako u igru uleti virtuelizacija, iskreno, preporuka za KVM, bar iz nekog iskustva, je da se VM-ovi ogranice na jedan NUMA node. Preko toga, moze da se mapira drugacije, ali je veliko pitanje koliko se isplati virtuelizacija - to su oni problemi gde je bare metal jos uvek validan izbor.
[ Ivan Dimkovic @ 03.01.2019. 12:28 ] @
Windows ce isto izbegavati daleke NUMA pristupe po defaultu (ali, ako ne moze da izservisira zahtev za lokalnom memorijom, nece ici u swap vec ce deo memorije doci sa stranog NUMA noda), mozda u tome i lezi problem ovde zato sto, koliko razumem, u Threadripper situaciji postoje CPU-ovi koji uopste nemaju "svoju" memoriju vec moraju da pristupaju memoriji preko fabric-a. Moguce je da Windows scheduler stalno pokusava da premesti nit na drugi CPU zbog pristupa memoriji sto ocigledno nije najpametnije resenje ovde.

Slazem se za Nikolom, ako sam program nije napisan da bude NUMA svestan, problema ce vrlo verovatno biti kako god i za virtuelizaciju je najpametnije sisteme "izolovati" tako da svaki bude unutar svog NUMA noda.

Na zalost, koliko razumem, neki AMD-ovi procesori imaju jezgra koja nemaju svoj memorijski kontroler.
[ Branimir Maksimovic @ 03.01.2019. 12:36 ] @
Ako nemaju memorijski kontroler onda to treba da bude transparentno i da se ne oseti po performansama, po meni. Svako bi tako razmisljao, zato sto bi onda problem bio i na Linux-u. Nego to sa swapom ce svakako da udari na Linux od 2020 kad DDR5 udje
u igru ;)
(pretpostavljam da ce tad 32GB biti ko sad 8 ;)
[ Ivan Dimkovic @ 03.01.2019. 12:47 ] @
Pretpostavljam da je na Linuxu neko implementirao fix koji "sirota" jezgra u TR procesorima ne tretira tako da stalno pokusava da im ukrade posao a da ocigledno Windows kernel ne resava ovu situaciju zadovoljavajuce - mozda AMD tim nije imao dovoljno resursa u MSFT-u posvecenih ovoj problematici. Ne znam kako uopste ide ta saradnja izmedju CPU vendora i Microsofta, pretpostavljam da dovoljno bitne arhitekture imaju neke timove koji rade na optimizaciji.

Na Linuxu je ocigledno to lakse posto je kod otvoren.

Ali ovo je samo jedan od mnogih mogucih problema sa ovakvim asimetricnim topologijama. Ovde je ocigledno slucaj OS-a koji pokusava da "optimizuje" stvari na los nacin ali i kad se to fixuje ostaje problem da u slucaju AMD TR-a sva jezgra nisu jednaka u smislu memorijskih performansi.
[ Branimir Maksimovic @ 03.01.2019. 12:51 ] @
Citat:

Ne znam kako uopste ide ta saradnja izmedju CPU vendora i Microsofta, pretpostavljam da dovoljno bitne arhitekture imaju neke timove koji rade na optimizaciji.

Da, to je veliko pitanje. Pretpostavljam da su ili iz AMD-a ili iz M$-a jednostavno napravili propust iz ovog ili onog razloga. Sto je najveci fazon niko to ne bi ni primetio
da TR nema toliko bolje performanse na Linux-u ;)
[ Ivan Dimkovic @ 03.01.2019. 14:05 ] @
Mislim da ce to biti brzo reseno sada kada je AMD ponovo postao jak igrac, sumnjam da ce ih MS ignorisati sa resursima :)

Ali, kao sto rekoh, kada je NUMA u pitanju OS moze da bude pametan do neke mere, ali bez specificnih softverskih optimizacija nista od maksimalnih performansi osim ako ne iscepkas sistem na VM-ove gde je svaki VM izolovan u svom NUMA ostrvu (sto je nemoguce sa trenutnim TR-om). Mada i tada imas bar mali VM penal, ali sta je tu je.

Intel ima "CoD" (Cluster on Die) mod na serverskim procesorima, gde se jedan socket deli na vise NUMA nodova tako da svaki NUMA nod ima svoj memorijski kontroler i u njemu su jezgra koja imaju direktan pristup istom. Ovo je relevantno za HCC/XCC jezgra gde postoji vise memorijskih kontrolera. Ako se trce izuzetno optimizovane aplikacije ili se sistem cepka na VM-ove velicine NUMA noda, onda je ovo resenje dobro zato sto se izbegava cross-node saobracaj.

Inace, Windows zahteva koriscenje tzv. "procesorskih grupa" ako sistem ima vise od 64 jezgra - to znaci da ce za sisteme sa vise od 64 jezgra biti neophodna aplikativna podrska ako aplikacije hoce da iskoriste 100% potencijal procesora. Ako aplikacija koristi stare Win32 API-je (pre Win7 / Srv2008 R2), trci u jednoj procesorskoj grupi sto znaci max. 64 jezgra za 64-bitne aplikacije. Pretpostavljam da za high-level jezike to resava sistemski runtime, ali za "native" developere koji koriste direktno Windows API ce ovo takodje biti bitna stvar koja je do sada kacila samo proizvodjace serverskih / WS aplikacija.
[ nkrgovic @ 03.01.2019. 17:25 ] @
Citat:
Ivan Dimkovic:
mozda u tome i lezi problem ovde zato sto, koliko razumem, u Threadripper situaciji postoje CPU-ovi koji uopste nemaju "svoju" memoriju vec moraju da pristupaju memoriji preko fabric-a.

Na zalost, koliko razumem, neki AMD-ovi procesori imaju jezgra koja nemaju svoj memorijski kontroler.

Iseckao sam quote, jer .... ovo BOLI.

Ne boli kao takvo, sve je to OK, to je ajde neka arhitektura, ali ovo boli kad se prave VM-ovi, ovo boli kad se koristi standardni Linux kernel. Ne sumnjam ja da je AMD napravo odgovarajuce patch-eve i da su oni usli u kernel, ali ja sam kapirao da AMD radi tako sto ima 4 numa "ostrva" sa fabricom izmedju njih, gde svako ima 2 memorijska kanala i svoj memorijski kontroler, koji pricaju kroz fabric na chip-u. Ako postoje jezgra koja nemaju pristup memorijskom kontroleru unutar ostrva, vec moraju da idu kroz druga jezgra, onda je to, po meni, prilicno lose... Intel nema taj problem na jednom chip-u koji ima 28 core-ova, najveci AMD blok ima 8 core-ova, ocekivao bi da svih osam mogu da gadjaju svoj memorijski kontroler ravnopravno, ne da su oni unutar tog numa ostrva nekako uvezani u dodatni fabric, a da je memorijski kontroler vezan samo za neke od njih...


[ Ivan Dimkovic @ 03.01.2019. 17:52 ] @
Evo slike:

https://images.anandtech.com/d...4/2990WX%20vs%202950X%20v2.jpg

U slucaju 2990WX, jezgra u modulu 1 i 3 nemaju svoje memorijske kontrolere vec idu preko fabric-a.

Pretpostavljam da ce AMD izbeci ovakvu konfiguraciju u sledecoj iteraciji posto je cela stvar prilicno nezgodna za softver.

AnandTech:

Citat:

The reason that these extra cores do not have direct access is down to the platform: the TR4 platform for the Threadripper processors is set at quad-channel memory and 60 PCIe lanes. If the other two dies had their memory and PCIe enabled, it would require new motherboards and memory arrangements.


EPYC nema ovaj problem (svaki modul ima svoje memorijske kontrolere) - mislim da je problem specifican samo za TR procesore sa 4 MCM modula.

Citat:

Going back to Threadripper 2, it is important to understand how the chip is going to be loaded. We confirmed this with AMD, but for the most part the scheduler will load up the cores that are directly attached to memory first, before using the other cores. What happens is that each core has a priority weighting, based on performance, thermals, and power – the ones closest to memory get a higher priority, however as those fill up, the cores nearby get demoted due to thermal inefficiencies. This means that while the CPU will likely fill up the cores close to memory first, it will not be a simple case of filling up all of those cores first – the system may get to 12-14 cores loaded before going out to the two new bits of silicon.


Zvuci kao horor.
[ nkrgovic @ 04.01.2019. 08:33 ] @
Die 1 i 3 nema ni PCIe kontrolere, koliko vidim, toliko od primena za neki NVMe storage....

OK, bar Epyc radi kako valja. Za desktop, sta ga znam....
[ Branimir Maksimovic @ 04.01.2019. 10:21 ] @
Cek zar onda 2 i 4 nisu dovoljni, sto se tice NVMe?
[ Ivan Dimkovic @ 04.01.2019. 10:32 ] @
Problem te kaci samo ako hoces HEDT platformu (Threadripper) koja ima 4 MCM modula.

IMHO, AMD je verovatno procenio da je taj segment trzista mali, vise sluzi kao neki "halo" marketing i da je TR4 socket/MB kompatibilnost sa "sirotim" jezgrima bolji kompromis od prelaska na novi socket.

Mislim da je taj dizajn nakaradan i da treba da umre, verovatno ce i da umre kada AMD bude lansirao novu HEDT platformu.

Ali ko zna, mozda ce asimetricni dizajn ostati... na suprotnoj strani trzista se vec debelo prica o kombinaciji jakih i slabih jezgara kao na ARM platformi, mozda cela stvar ode i u visoki segment trzista. Izazov za kernel developere svakako i jos jedna za*bancija za ljude koji moraju da odrzavaju takve sisteme svakako.

Citat:
Branimir Maksimovic
Cek zar onda 2 i 4 nisu dovoljni, sto se tice NVMe?


"Dovoljni" jesu da platforma radi, ocigledno, ali ako se prica o maksimalnim performansama onda stvari nisu optimalne za jezgra u modulima koja nemaju svoje PCIe kontrolere posto ta jezgra prakticno moraju da delegiraju sve na druge module (memorijski i PCIe saobracaj).

Infinity Fabric link izmedju MCM modula ima bandwidth od 42.6 do 102.2 GB/s po AMD-ovim marketinskim specifikacijama - i tu moras da upakujes i pristup memoriji i PCIe transakcije. Modul ima 8 jezgara, sto znaci da u nekim situacijama sa visokim load-om ocigledno jezgra moraju ostati "gladna".
[ Branimir Maksimovic @ 04.01.2019. 11:35 ] @
Heh, AMD se potrudio da zarad ne moranja menjanja maticne ploce za TR, obezbedi mozgalicu za MS ;)
Mozda ce to biti razlog da likovi koji su kupili tu zver konacno predju na Linux ;)
Ali ne mogu da zamislim koliko to struje moze da vuce kad ovo moje sa 8 kora vuce 200W na stock kloku ;)
[ nkrgovic @ 04.01.2019. 11:50 ] @
Citat:
Branimir Maksimovic:
Cek zar onda 2 i 4 nisu dovoljni, sto se tice NVMe?

Zamisli da hoces da uguras recimo 20xNVMe drajva. Ili 24 . Svaki PCIex4 .

Nije HEDT, ali jeste za DC. Srecom, Epyc nema taj problem.....
[ Branimir Maksimovic @ 04.01.2019. 12:05 ] @
Mislim da niko ko kupuje TR nece gurati 20 NVMe drajva ;)
TR je pandan Intel HEDT-una koji takodje ne moze 20 istih, tako da je AMD ovde verovatno racuna na to. Epyc je pandan Xeon-ima, cini se?
[ Ivan Dimkovic @ 04.01.2019. 18:46 ] @
Citat:
Branimir Maksimovic
Heh, AMD se potrudio da zarad ne moranja menjanja maticne ploce za TR, obezbedi mozgalicu za MS ;)


Meni ovo vise deluje da se AMD i MS inzenjeri nisu bavili dovoljno tom platformom. Da li je to krivica AMD-a ili MS-a, pojma nemam.

Inace, da, TR je HEDT platforma (ne konkurent Xeon-ima, to je EPYC) i 32-core model je prakticno halo produkt rezervisan za vrrrrlo mali % korisnika.

Moje iskustvo sa NUMA platformama i Windows-om je bilo tako da sam na kraju presao na 100% kontrolu gde koji thread trci i koju memoriju koristi. Windows scheduler mi se ne mesa u posao posto svakom thread-u setujem afinitet i memoriju alociram "rucno" za svaki NUMA nod. I svima lepo :)

Na zalost, sa 32-core TR platformom ja ne znam da 2 od 4 NUMA noda >nemaju< memoriju. Windows API mi ne daje tu informaciju! Na Linuxu libnuma daje tu informaciju koja je u ovom slucaju vrlo vredna, posto bih onda mogao da, recimo, unapred dajem manje posla nitima koji trce na "sirotim" jezgrima zato sto su im svi pristupi memoriji sporiji.

Naravno, do toga mogu da dodjem i indirektno, posle nekoliko iteracija gde postaje jasno da CPU-ovi procesiraju manje podataka, ali bih sa direktnom informacijom mogao to znam bez nekog auto-tuning procesa.
[ Ivan Dimkovic @ 04.01.2019. 19:30 ] @
Btw, cisto za zainteresovane da opisem koliko je NUMA gadan problem: DigiCortex ima interni "work stealing" scheduler koji na svakom jezgru trci radnu nit i daje im posao.

Zanimljivo, za compute-bound problem (inicijalizacija neuralne mreze gde neuroni "rastu") je isplativo da niti smeju da "kradu" posao nitima sa drugih NUMA nodova. Ovo se desava ako neko jezgro dobije mnogo "nezgodnih" neurona koji se mnogo vise granaju sto scheduler ne zna unapred, posto je odnos racunanja i pristupa memoriji povoljan, kradja posla drugom jezgru nije skupa i pozitivno utice na performanse zato sto ce se iskoristiti sva jezgra maksimalno.

U ovom slucaju je OK da radna nit na NUMA nodu X "ukrade" task od niti na NUMA nodu Y.

Ali kada se predje na simulaciju, koja je cisto ogranicena memorijskim bandwidth-om je stetno da nit krade posao nitima na stranim NUMA nodovima. Na Intel platformama kradjom dolazi do saturacije QPI/UPI linkova i performanse se gube zato sto sistem gubi vreme sa ogromnim bus traffic-om. U ovom slucaju je bolje da nit ode da spava i ceka kraj koraka nego da pokusava da krade posao nitima sa drugih NUMA nodova. Igrao sam se i sa threshold-ovanjem tipa koliko jedna nit treba da bude "iza" u poslu da postane isplativo krasti joj posao sa drugog NUMA noda, odgovor: skoro nikad.

Ovo vazi za vecinu sistema (nisam probao na 32-core TR-u!)... osim za par oddball Haswell EX 4S sistema gde, mislim, da prijavljena NUMA topologija ne odgovara pravom stanju stvari pa work-stealing zapravo smanjuje pad performansi.

Nisam nikad probao 2990WX, ali pretpostavljam da bi 2990WX bio bas takav oddball sistem - ako neko ima 2990WX bio bih zahvalan za volontiranje :-)

Ljudima koji rade HPC/serverske aplikacije ovo nije nista novo. Sta je bolje zavisi od konkretnog problema. Silne disertacije su napisane na ovu temu.

Ali AMD je celu problematiku sada uveo na desktop polje sa TR procesorima.

Ako neko ocekuje da OS scheduler to magicno resi... hahaha :)

Windows ocigledno ima TR-specific bag. Ali ni Windows ni Linux ne mogu biti pametniji od samih aplikacija.
[ Branimir Maksimovic @ 05.01.2019. 17:56 ] @
Ove godine na Ryzenu sa 64 kora ;)
Mozda uzmes dual soket pa stavis 128 kora ;)
Tesko ce neko da kupi sada 2990WX, kosta 2k evra i TDP mu je 250W. Racunaj da to vuce minimum 400W na stoclk taktu (znaci minimalni takt) samo procesor ka d se upogoni ;)

[ Ivan Dimkovic @ 05.01.2019. 18:27 ] @
64 jezgra je za sada izvesno ove godine samo na serverskom trzistu (EPYC). Slazem se da ce 2S Rome masina sa 128 jezgara biti ubica.

Videcemo sta ce AMD uraditi na HEDT polju i da li ce zadrzati TR4 socket kompatibilnost (u kom slucaju cemo verovatno i dalje imati "krnjava" jezgra bez svog DRAM kontrolera u konfiguracijama sa 4 cipleta) ili ce novi Threadripper dobiti novi socket.

Rome EPYC ce biti socket kompatibilan sa trenutnom EPYC platformom (Naples), cak ce i sledeca generacija (Milan) isto zadrzati isti socket.
[ Ivan Dimkovic @ 05.01.2019. 22:58 ] @
Haha jao nesto sad razmisljam oko celog oddball NUMA dizajna 2990WX-a...

Znaci moja aplikacija sama kreira thread-ove za svaki CPU i alocira memoriju za svaki NUMA nod. Radna pretpostavka (Windows, posto nema potreban API) je da svaki NUMA nod ima jednaku kolicinu memorije, tako da se ceo problem podeli na N jednakih delova (gde je N - broj NUMA nodova).

Haha, znaci na Windows-u, ja lepo kazem VirtualAllocExNuma(bla bla) i lepo mislim da sam dobio memoriju u svom NUMA nodu.

Ali taj nod nema memorije :) Hahahahaha - sta ce da se desi? Pa dobicu memoriju, ali iz nekog N-tog NUMA noda, necu dobiti ni info u kom nodu sada sedi ta memorija. Windows API je takav, broj NUMA noda je samo "hint" alokatoru memorije koji ce koristiti i druge NUMA nodove ako ne moze da ispuni zahtev.

I tako, mojih 16 thread-ova (2 x 8) sirocica bez svoje memorije rade i misle da obradjuju lokalnu memoriju, a memorija razbacana negde u 3 lepe :)

Na Linuxu bih bar znao da je procesor bogalj i koja jezgra nemaju memoriju, pa bih mozda i nesto korisno mogao da uradim sa tom informacijom.
[ Branimir Maksimovic @ 06.01.2019. 00:16 ] @
Znas kako ako pola procesora nema direktan pristup memoriji ne mozes tu puno. Jedino da rasporedis threadove koji rade sa malim slojem podataka tamo, ako je to uopste moguce.
[ Ivan Dimkovic @ 06.01.2019. 09:26 ] @
Btw, moja greska, Windows API nudi funkciju koja daje informaciju koliko koji NUMA nod ima memorije: GetNumaAvailableMemoryNode(Ex)()

Jedino je jako tesko bilo naci ovaj API googlanjem iz nekog razloga.

Pretpostavljam da bi na 2990WX-u dobio informaciju da neki nodovi nemaju memoriju i procesorima iz tih nodova bi mogao da alociras manje posla. Problem je, naravno, sto kolicina posla koju ces im dati zavisi od koriscenja memorije i varira od problema do problema, mozda i unutar problema ako memorijske potrebe nisu konstantne u vremenu.

Moras uzeti u obzir da pristup stranoj memoriji, takodje, oduzima bandwidth i jezigrima na tom stranom nodu + zagusujes bus sa memorijskim saobracajem koji mozda delis i za PCIe, itd.

Cela stvar je fakat zivota u serverskom svetu, gde je obicno najlakse resenje iscepati server na VM-ove gde svaki dobija svoj nod, ako vec imas skalabilnu arhitekturu koja moze da trci na cloudu/clusteru, i ne moras uopste da mislis o NUMA optimizacijama.

Ali na desktop/WS-u obicno zelis da trcis neku kljucnu aplikaciju. U tom slucaju nema druge nego da app. vendor zasuce rukave i optimizuje app za ovakve procesore.
[ nkrgovic @ 06.01.2019. 13:38 ] @
Da, ali kao sto rekosmo u rugom thread-u, koliko onih koji imaju novca da kupe takve aplikacije, hoce da ih vozi na non-ECC masini? :)

Po meni, tezak edge case. Ne racunajuci one sto bi da imaju "najbolji na testovima", samo zbog toga, cenim da ThreadRipper i nema neko trziste. Intel je, na zalost, bolji izbor.
[ bojan_bozovic @ 07.01.2019. 07:36 ] @
Intel i9-9900K je svakako najbolji izbor, bolji od Ryzena 7 2700X a i Ryzena TR za obicnog desktop korisnika, no ovde je bezobrazno skup. U USA je ispod 500 USD a ovde je cena osamdesetak hiljada!
[ Ivan Dimkovic @ 07.01.2019. 10:20 ] @
Citat:
nkrgovic:
Da, ali kao sto rekosmo u rugom thread-u, koliko onih koji imaju novca da kupe takve aplikacije, hoce da ih vozi na non-ECC masini? :)

Po meni, tezak edge case. Ne racunajuci one sto bi da imaju "najbolji na testovima", samo zbog toga, cenim da ThreadRipper i nema neko trziste. Intel je, na zalost, bolji izbor.


Slazem se, ECC je prilicno neophodna stvar za bilo sta sto trci neko duze vreme na ovim masinama (renderi, simulacije).

AMD ima mnogo manje resursa nego Intel ili NVIDIA tako da su verovatno morali da prioritizuju EPYC i consumer Ryzen (ne TR) u ovoj iteraciji. Mozda ce im dodatna kinta omoguciti da R&D-uju nesto sto je ozbiljnije od trenutnog TR-a za WS upotrebu.

Meni trenutni TR deluje kao neki hobi projekat AMD tima - "hej, sta mozemo da uradimo sa EPYC procesorom sto pre i sa sto manje troskova za MB vendore". Sto je sasvim OK za HEDT (gaming) ali za WS je sasvim druga prica.

Za WS upotrebu bi AMD zapravo trebao da se fokusira na EPYC i ponudi SKU-ove koji rade na visljim frekvencijama, ali to ce verovatno zahtevati 7nm i nekakvu segmentaciju kako bi i dalje mogli da traze nekoliko hiljada $ za serverske/enterprise kupce (EPYC 601) a da ponude nesto jeftinije WS korisnicima.
[ Branimir Maksimovic @ 07.01.2019. 12:31 ] @
Citat:
bojan_bozovic:
Intel i9-9900K je svakako najbolji izbor, bolji od Ryzena 7 2700X a i Ryzena TR za obicnog desktop korisnika, no ovde je bezobrazno skup. U USA je ispod 500 USD a ovde je cena osamdesetak hiljada!


Gde si video da je ispod 500$? Koliko vidim na amazonu ~530$ + jedno ~160$ za carinu i shipping. sto ce reci jedno ~700$. Agde je onda garancija?

edit: Inace na KP je jos skuplji nego u radnjama ;p
Uporedi to sa duplo jeftinijim 2700X i stavi na papir kolko moze 9900k da bude brzi od njega...
A od 9700K je brzi posto dobijas jedno 30% na SMT... kod AMD-a


[Ovu poruku je menjao Branimir Maksimovic dana 07.01.2019. u 14:04 GMT+1]
[ bojan_bozovic @ 07.01.2019. 13:04 ] @
Tacno izvinjavam se na dezinformaciji.