AMD Ryzen Threadripper – samlingstråd

Just det, testerna kan vara autentiska, allt beror på vad man skall köra för program. För en typisk hemmaanvändare gör extrem multicore föga nytta idag. Men för den som har ovan specifika behov kan det ge ett stort prestandalyft i rätt program.

Som typisk hemmaanvändare av en hemmadator ser det ut som att inget bör inhandlas innan Coffee Lake har presenterats.

Skickades från m.sweclockers.com

Jag inser inte att Geekbench är mycket sämre än andra komposita bänkmärken. Några av Geekbenchs deltester beskrivs i http://geekbench.com/doc/geekbench4-cpu-workloads.pdf och vad vi kunde se igår så ger de halvt rimliga värden för både harmoniskt medelvärde och median. Men, självklart ger deltester en bredare bild. Men, är bara medveten om det så ser jag inga problem; jag var ju inte medveten själv.

Här testar jag reliabiliteten av NUMA-effekten på data från Geekbench, om den är reproducerbar över fler olika processor-typer. Jag har valt ut NUMA/icke-NUMA-processorer som är samtida motsvarighet med äkta antal kärnor. Jag jämför med hyperthreading för att se skillnaden. Det finns både likheter och skillnader. Det jag testat är

• Intel E6600 och Q6600 https://browser.primatelabs.com/v4/cpu/compare/3320513?baseli...

• Intel 1*E5-2670 och 2*E5-2670 https://browser.primatelabs.com/v4/cpu/compare/3333349?baseli...

• Intel i5-7600K och i7-7700K https://browser.primatelabs.com/v4/cpu/compare/3347232?baseli...

• AMD Ryzen 1700 och Threadripper https://browser.primatelabs.com/v4/cpu/compare/3350876?baseli...

Man kan här betrakta Q6600 som NUMA-variant av E6600 på samma sätt som dual Intel Xeon E5-2670 och Threadripper är dubbleringar av antalet kärnor (och trådar). Hypterthreading är ju också en dubblering av antalet trådar varför i5-7600K och i7-7700K också fick vara med. Allt har ställts relativt i7-7700K i procent. I det tredje diagrammet så ser vi NUMA/HT ställt mot sin enklare variant med halva antalet trådar, enligt ovan.

Geekbench 4 single-core relativt i7-7700K

Visa innehåll

Dold text

Geekbench 4 multi-core relativt i7-7700K

Visa innehåll

Dold text

Geekbench 4 multi-core effekt av NUMA och HT

Visa innehåll

Dold text

Man ser att dubbla Xeon och Threadripper beter sig väldigt lika i nästan samtliga benchmarks och att NUMA-effekten finns där. Däremot är den inte alls lika påtaglig, om den ens finns i Q6600 jämfört med E6600! Var man bättre förr, eller förvärras det med än flera kärnor (Amdahl/Gustafson)? Hyperthreading ger säkert en boost, som eventuellt drunknat här då i5-7600K har 3800 Mhz och i7-4200 MHz; jag hittade ingen med samma klocka. Det förklarar sannolikt varför det är så jämn förbättring, det är frekvensskillnaden vi ser.

Okej, jag måste tänka över allt det här flera gånger till, och basera ett inköp på publicerade tester, på än fler tester. Var går gränser för hur mycket information man behöver?!

EDIT: Glömde säga att jag inverterat latenserna för att högre värden skall anses bättre.

EDIT 2: Såg på https://hothardware.com/news/amd-ryzen-threadripper-1950x-16-... att man hade använt DDR4 2400 MHz för Threadripper. Vi vet sedan tidigare att Ryzen vinner mycket på snabbare minnen tack vare Infinity Fabric. Det kan säkert påverka till det positiva på många av deltesterna i Geekbench 4.

Det kommer fler och fler läckor.

Som säkert en del av er har sett så har det släppts resultat från SiSoft Sandra, ett annat komposit bänkmärke som ger en (1) siffra för allt möjligt.

Från https://hothardware.com/news/amd-ryzen-threadripper-1950x-16-...

Threadripper

Visa innehåll

Dold text

Top 16 i databasen http://ranker.sisoftware.net

Visa innehåll

Dold text

Så långt ser det ju bra ut. Threadripper är rejält högre i "GOPS" än både i9-7900X och i7-6950X.

Men, den där jäveln är väl i detaljerna här åxå, men dessa saknas ju än.

EDIT: Jo, en detalj fanns ju och det var att resultaten för Threadripper var överklockade till drygt 3,9 GHz! Det går alltså överklocka! 431 GOPS för Threadripper på 3,9 GHz mot 336 GOPS för i9-7900K på 4,3 GHz. Nästa steg bli att tolka vad GOPS (GigaOperationsPerSecond) är här... och vilka deltester det är uppbyggt av samt är ett mått på. Där tror jag inte att man kan komma mycket längre just nu.

Ju mer jag tänker på det verkar det vettigaste att vänta på Cannonlake, då får man i alla fall en ny tillverkningsprocess med bättre egenskaper rent allmänt, så samma gamla datorer får tugga på för mig fram till runt Maj 2018 verkar det som ...

Kan man vänta så är det ju alltid ett alternativ. Framtiden är inte vad den har varit.

Här är 11 stycken Ryzen 1800X ställda mot en Threadripper och alla relativt i7-7820X.

Single-core

Visa innehåll

Dold text

Multi-core

Visa innehåll

Dold text

Det man ser är att det är att i7-7820X är snabbare i de flesta av single-core men att Ryzen 1800X är snabbare i de flesta multi-core deltesterna.

Det finns däremot stor variation bland enskilda 1800X som kan beror på minnen och klockning och andra parametrar, kanske främst i multi-core. 1800X-4, 1800X-9 och 1800X-10 är överklockade (3,9-4,1 GHz) men det syns tydligast på 1800X-4 som dessutom är den enda som kör Linux.

Threadripper är väldigt lik 1800X här, och vinner ett antal, där förväntat. Som @Yoshman sade, kanske färre än vad många önskar.

Man kan hoppas att det här är något tidigt exemplar där förbättringar syns bättre senare.

Här förklarar man varför Epyc (och därmed Threadripper) använder en NUMA--lösning med Infinty Fabric

https://youtu.be/aokgkxHJVYQ

Skickades från m.sweclockers.com

Geekbench 4 är ett klart fall framåt jämfört med tidigare versioner sett till vilka deltester man har med.

Problemet med det geometriska medel man beräknar är att det blir hopplöst att tolka den siffran på något sätt då GB4 innehåller väldigt olika typer av arbetslaster.

Att det är många olika typer av arbetslaster är ju verkligen tummen upp. För att ha någon nytta av den informationen måste man dock jämföra specifika tester, för om jag tänker använda min CPU till applikationer som löser ett specifikt problem med många CPU-trådar där grundproblemet inte skalar perfekt är ju testresultatet från t.ex. AES, LLVM och "Rigid Body Physics" totalt irrelevanta.

Ett stort grundproblem kvarstår dock med Geekbench 4: tummen upp för deras initiativ att skriva sitt whitepaper som kort beskriver vad alla tester gör (det dokument du länkar till). En stor tumme ned för att beskrivningarna överhuvudtaget inte beskriver hur man parallelliserat problemet i multi-tråd testerna samt nästan totalt avsaknad av vilka algoritmer som används.

Ta PDF-testet, man skapar ett PDF-dokument. Fine, men hur ser arbetslasten ut? I vissa fall är algoritmen uppenbar, t.ex. Dijkstra, SGEMM, SFFT och "Histogram Equalization", det förutsatt att man själv jobbat med fall där dessa används.

Just Dijkstra (används t.ex. av GPS-system och även spel för att beräkna optimala vägen mellan två geografiska punkter) kan nog fungera som hyfsad proxy för "problemet som har viss skalbarhet med CPU-kärnor". Men man ska inte övertolka resultatet, finns trots allt en rad saker som kan skilja sig i andra problem som råkar vara lika på just punkten "skalning med CPU-kärnor".

C2Q är inte NUMA! Den är inte en symmetrisk quad-core design, men det är fortfarande ett UMA-system (Uniform Memory Architecture) och inte NUMA (Non-Uniform Memory Architecture). Alla CPU-kärnor har samma kostnad mot all RAM, C2Q designen är betydligt mer jämförbar med två CCX.

R5-1400/1500X och C2Q är ur den aspekten lika, båda består av två st dual-core komponenter som delar RAM-buss men som inte delar någon nivå CPU-cache.

NUMA inför en långt starkare form av asymmetri, men om du tittar på t.ex. Dijkstra resultatet ser man att C2Q skalar något sämre än en helt symmetrisk design. Rent praktiskt är nog effekten runt en tiopotens större mellan NUMA-noder.

Ett fall med relativt låg cache-hit rate där alla kärnor använder RAM från alla NUMA-noder skulle uppföra sig väldigt mycket värre på ett system med mer än en NUMA-nod jämfört med C2Q och Ryzen. I de två senare fallen må det finnas två cache-öar, men det är fortfarande bara en RAM-ö!

Gissar att något blivit vänt åt fel håll i din multi-thread graf. i7-7820X verkar faktiskt öka sin ledning över R7-1800X i multitrådfallet i (geometrisk) genomsnitt.

Tittade på några fall och i det enkeltrådade fallet ligger i7-7820X ~20 % före i enkeltrådprestanda och ~50 % före i multitrådprestanda (det då enligt GB4 aggregerade resultat).

BTW: hur tar du in data från GB-databasen in i det du gör graferna med (gissar det är R...)? Inte manuellt hoppas jag! Har ett AWK-skript som givet resultat ID printar namnet på deltesterna, ST-resultat och MT-resultat.

Ex (Edit: den som vill ha skriptet kan skicka PM)

$ gb4cat.sh 3356333 | awk -f gb4.awk - CPU=R7-1800X
--2017-07-09 16:09:49--  https://browser.primatelabs.com/v4/cpu/3356333
Resolving browser.primatelabs.com (browser.primatelabs.com)... 23.92.21.41
Connecting to browser.primatelabs.com (browser.primatelabs.com)|23.92.21.41|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘3356333’

3356333                                        [ <=>                                                                                   ]  26.08K  --.-KB/s    in 0s

2017-07-09 16:09:50 (114 MB/s) - ‘3356333’ saved [26707]

CPU model: AMD Ryzen 7 1800X @ 3.60 GHz

R7-1800X,       AES,                            5981,           17341
R7-1800X,       LZMA,                           4634,           30406
R7-1800X,       JPEG,                           4266,           30550
R7-1800X,       Canny,                          4593,           23433
R7-1800X,       Lua,                            3041,           24416
R7-1800X,       Dijkstra,                       4476,           18457
R7-1800X,       SQLite,                         3776,           27112
R7-1800X,       HTML5 Parse,                    3435,           22140
R7-1800X,       HTML5 DOM,                      5050,           32704
R7-1800X,       Histogram Equalization,         3758,           19404
R7-1800X,       PDF Rendering,                  4135,           15642
R7-1800X,       LLVM,                           6266,           41403
R7-1800X,       Camera,                         4822,           27168
R7-1800X,       SGEMM,                          2502,           8442
R7-1800X,       SFFT,                           3657,           20254
R7-1800X,       N-Body Physics,                 4262,           32139
R7-1800X,       Ray Tracing,                    4304,           20971
R7-1800X,       Rigid Body Physics,             4266,           32118
R7-1800X,       HDR,                            4457,           29533
R7-1800X,       Gaussian Blur,                  5094,           21726
R7-1800X,       Speech Recognition,             5011,           21015
R7-1800X,       Face Detection,                 4687,           29458

3D Beoynd var inne på att "Intel"maskinen var virtualiserad.
De startade alltså en virtuell maskin under en Ryzen 1700x och döpte den till Intel 1700x.

Tror du inte en mycket enklare förklaring är att man kör Ryzen fast med Intels OpenCL implementation?

Tittar man på "Info" tabben för "Intel® Ryzen 7 1700X Eight-Core Processor" resultatet ser man bl.a. dessa två fält

System: AMD Ryzen 7 1700X Eight-Core Processor (d.v.s. här står det AMD Ryzen...)
CL_DEVICE_VENDOR: Intel® Corporation

Tittar man däremot på det andra fallet, det som säger "AMD Ryzen 7 1700X Eight-Core Processor" så ser man
CL_DEVICE_VENDOR: AuthenticAMD

Intel har lagt en hel del krut på OpenCL stödet, både för iGPU och CPU. När jag gjorde lite jämförelser mellan Nvidia 750M, HD4600 och i7-4702HQ (d.v.s. på en 2013 års Dell XPS15) presterade ofta iGPU och CPU ungefär lika (men CPU-delen var oftast snabbast) medan 750M fick sämre resultat (trots långt högre teoretisk flyttalsprestanda för single precision). Nu verkar i.o.f.s. Nvidia skita rätt mycket i OpenCL, prestanda är långt bättre med CUDA...

När man kör Intels OpenCL paket för CPU kommer koden typiskt bli väldigt optimerad med AVX2+FMA (Ryzen stödjer båda dessa), teoretisk prestanda är faktiskt rätt hög i moderna CPUer om de kan utnyttja dessa tekniker fullt ut.

Finns ingen anledning att döpa om något. OpenCL är en "runtime" vars uppgift är att översätta OpenCL-kod till maskinkod för underliggande HW. Det är lite som en kompilator, fast den körs av en applikation. Shaders för GPUer fungerar på i stort sätt exakt samma sätt, d.v.s. shader-kod är generell och respektive drivare översätter ("kompilerar") den koden till GPU-maskinkod.

I fallet x86 är underliggande HW x86-assembler, i praktiken används väldigt mycket SIMD, d.v.s. SSE/AVX. Intels OpenCL implementation kolla vad CPUn implementera i form av SIMD och anpassar den genererade koden efter vad som är möjligt. Så på Atom skulle det bli SSE4, Sandy Bridge AVX och Skylake X AVX512+FMA.

Gör man samma sak på Ryzen kommer CPUn säga: jag stödjer AVX2+FMA, det är samma som Haswell, Broadwell och Skylake S/U/Y/H så inga konstigheter (ur programvarans synvinkel). Om det inte finns en explicit spärr för att Intels OpenCL implementation kräver just en Intel CPU så kommer det fungera även på Ryzen.

Verkar som du har rätt.
Även om din förklaring verkar troligare, är den inte lika skojig.

edit Fast det som talar för en VM är att "Intel Ryzen" saknar benchmarks av grafikkortet.

$ gb4cat.sh 3356333 | awk -f gb4.awk - CPU=R7-1800X
--2017-07-09 16:09:49--  https://browser.primatelabs.com/v4/cpu/3356333
Resolving browser.primatelabs.com (browser.primatelabs.com)... 23.92.21.41
Connecting to browser.primatelabs.com (browser.primatelabs.com)|23.92.21.41|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘3356333’

3356333                                        [ <=>                                                                                   ]  26.08K  --.-KB/s    in 0s

2017-07-09 16:09:50 (114 MB/s) - ‘3356333’ saved [26707]

CPU model: AMD Ryzen 7 1800X @ 3.60 GHz

R7-1800X,       AES,                            5981,           17341
R7-1800X,       LZMA,                           4634,           30406
R7-1800X,       JPEG,                           4266,           30550
R7-1800X,       Canny,                          4593,           23433
R7-1800X,       Lua,                            3041,           24416
R7-1800X,       Dijkstra,                       4476,           18457
R7-1800X,       SQLite,                         3776,           27112
R7-1800X,       HTML5 Parse,                    3435,           22140
R7-1800X,       HTML5 DOM,                      5050,           32704
R7-1800X,       Histogram Equalization,         3758,           19404
R7-1800X,       PDF Rendering,                  4135,           15642
R7-1800X,       LLVM,                           6266,           41403
R7-1800X,       Camera,                         4822,           27168
R7-1800X,       SGEMM,                          2502,           8442
R7-1800X,       SFFT,                           3657,           20254
R7-1800X,       N-Body Physics,                 4262,           32139
R7-1800X,       Ray Tracing,                    4304,           20971
R7-1800X,       Rigid Body Physics,             4266,           32118
R7-1800X,       HDR,                            4457,           29533
R7-1800X,       Gaussian Blur,                  5094,           21726
R7-1800X,       Speech Recognition,             5011,           21015
R7-1800X,       Face Detection,                 4687,           29458

Du hade ju gjort ett lite program där man kunde mäta tiden mellan olika processorer. Jag testade det för några månader sedan och det var ju viss skillnad men inga tiopotenser. Så, nej, det är nog inte i närheten av NUMA-latenser.

Jo, det hade blivit inverterat i diagrammet...

Jag blev peppad att testa web scraping med R. Jag har aldrig fullföljt det tidigare, men nu hade jag lite semestertid över. Men, oj, det blev mer komplext än jag räknat med, men det fungerar till stor del. Det är "halvautomatiskt", där jag fortfarande måste ange löpnummer manuellt, men det är allt. Allt kommer in i R som en data.frame vilket är bekvämt.

Men, för mindre projekt är copy-paste snabbare, dvs upp till ett par dussin observationer. Men, nu har jag koden vilken ju går att återanvända.

Men att få snygga diagram snabbt tar fortfarande lite för lång tid för att det skall bli relevant. Här kommer ett diagram skapat i vanliga Excel, baserat på data hämtade via R.

Som vi ser är det visst överlapp mellan AMD Ryzen 1800X och Intel i7-7820X. Det fanns inga tydliga samband med minnesmängd. Tyvärr fick jag inte med minneshastigheter.

De Ryzen som ligger högst är de som är överklockade till 4,0-4,1 GHz. Det är fortfarande en billigare lösning än att kyla en i7-7820X.

Det mäter bara en enda aspekt, hur lång tid det tar att hantera cache-koherens mellan två CPU-trådar. Detta är urtypen för mikrobenchmark, det mäter absolut en specifik aspekt av systemet men det går inte direkt att applicera på hur specifika applikationer kommer påverkas av detta.

För varje specifik applikation måste man veta vad flaskhalsarna är för att veta om just latensen för att hantera cache-koherens för en enda cache-line (vilket är vad mitt och PCPerspectives program testar).

På min dual E5-2690 är det ungefär en faktor fem i latens mellan två kärnor i samma NUMA-zon och två på olika NUMA-zoner (olika socklar), så inte riktigt en tiopotens men väl flera heltalsfaktorer (så icke-försumbart).

Är ju uppenbart att Geekbench 4 testerna gör saker som skalar uselt på NUMA, finns ju ett test med Epyc 7601 och där är prestanda sämre än både Threadripper och 1800X (d.v.s. flera av programmen har negativ skalning med antalet NUMA-zoner).

AnandTech såg ju också ett sådant fall i deras snabbtest av Epyc och Skylake EP

"In previous articles, we tested with Spark 1.5 in standalone mode (non-clustered). That worked out well enough, but we saw diminishing returns as core counts went up. In hindsight, just dumping 300 GB of compressed data in one JVM was not optimal for 30+ core systems. The high core counts of the Xeon 8176 and EPYC 7601 caused serious performance issues when we first continued to test this way. The 64 core EPYC 7601 performed like a 16-core Xeon, the Skylake-SP system with 56 cores was hardly better than a 24-core Xeon E5 v4."

En 22-core Xeon E5 2699 v4 (står fel, är 22 kärnor inte 24) är inte heller någon supermatch för just detta fall, skulle fungera bättre med färre lägre klockade kärnor, men här ser man att försöker man skala en och samma instans över NUMA-zoner, av ett program som ändå är helt designat för att skala bra med kärnor, så blir det i princip noll skalning.

Ett annat exempel är AnandTechs databastest. Det är enda testat där det kör ett program över alla CPU-kärnor, fungerar inte bra på Epyc (och finns ingen annan rimlig förklaring än just NUMA, Ryzen står sig riktigt bra i databastester).

Vad man vill göra med NUMA är att se till att varje enskild process inte behöver fler CPU-trådar än vad som kan hållas inom en NUMA-zon. Ur den bemärkelsen är inte Epyc 7601 en 32 kärnors CPU, det är fyra stycken 8-kärnors CPUer i samma paket och den presterar bara väl om man behandlar den som sådan.

Threadripper är två stycken 8-kärnors CPUer.

Någon som sett vatten kylning till Threadripper/EPYC?

Sett Noctua tornkylare men vad finns det mer?

Priserna framgick ju i klippet. Dessutom att 1950X fick över 3000 i Cinebench R15 multi.

Det kan jämföras med andra cpuer, där t.ex. i9-7900X når mellan 2100 och 2200.

https://hothardware.com/reviews/intel-core-i9-7900x-and-core-...
http://m.hexus.net/tech/reviews/cpu/107017-intel-core-i9-7900...

Nu gäller det vad prestanda blir i single. Priset vet vi nu.

EDIT

Från
http://www.anandtech.com/show/11636/amd-ryzen-threadripper-19...

Cinebench:

"AMD Threadripper 1950X 16C/32T 3.4/4.0 $999 3062
AMD Threadripper 1920X 12C/24T 3.5/4.0 $799 2431
Intel Core i9-7900X 10C/20T 3.3/4.3 $999 2167"

Undrar hur de utan X kommer att kosta.

Nu har det dykt upp Threadripper på Geekbench, med löpnummer

3108740
3108784
3108817
3108918
3108958

En tabell med råvärdena:

Om man överklockar 3,4 GHz med samma faktorer som man fick med 1700 i ett tidigare inlägg blir det

Hur väl det stämmer får vi se framöver.

Från artikeln

"For our testing we used the read-only OLTP benchmark,"

Det är absolut best-case för system med flera NUMA-noder, detta p.g.a. av att latensen är rätt hög mellan NUMA-noder och relationsdatabaser garanterar att alla alltid får samma värde (det senaste som skrevs). Detta enligt en utökning av CAP-teoremet som kallas PACELC.

Då det bara är läsningar borde det inte vara något jätteproblem att Epyc har 8 st 8 MB L3-kakor, det är totalt 64 MB L3$ vilket är rätt mycket större än 8176 (38,5 MB), till och med större än 2699v4 (55 MB).

Och om cache nu var ett problem så borde skillnaden vara väsentligt större, 2690 med sina 20 MB L3$ borde knappast vara så mycket långsammare än Epyc 7601 om den förra kör ur L3$. Nog för att det är mycket bandbredd mot RAM, men det är fortfarande ett par heltalsfaktorer mer bandbredd mot L3$ och framförallt ett gäng heltalsfaktorer lägre latens.

Förhoppningsvis gör AnandTech vettiga databastester framöver, denna är rätt meningslös som den är designad nu. Dels bör man ha väsentligt större databas men framförallt bör det även vara skrivningar (fast gissar att man skippade det då NUMA+massor med kärnor kommer få MySQL att rejält tanka...).

AT har intressant text kring tekniken i servers, men de verkar rätt dåliga på att faktiskt testa sådana system på ett vettigt sätt. Som tur är har STH (Serve The Home) tillgång till både Epyc och Skylake SP, är där man får läsa de vettiga testerna (de ska komma inom kort).

Effekten av NUMA syns faktiskt riktigt väl i Geekbench 4, förutsatt att man tittar på individuella tester. Har tagit med E5-2667v4 då det i princip är server-versionen av i7-6900K, så dessa två förhåller sig som Threadripper 1950X vs R7 1800X när det kommer till antal kärnor och NUMA. 16 kärnor / 2 NUMA-zoner mot 8 kärnor / 1 NUMA-zon.

Har rangordna testerna efter hur de skalar med NUMA, från bra skalning (saker där beräkningen är helt lokaliserad och kan köra ur L2$) till usel skalning med NUMA, d.v.s. saker där trådarna relativt ofta måste synkronisera med varandra.

I mitten finns kanske de mest intressanta resultaten, de som skalar med monolitiska designer men inte med NUMA. Är en effekt av latens och/eller det faktum att data i ena faller alltid ligger i RAM som är "nära" (en NUMA-zon), rätt dyrt att läsa/skriva RAM som ligger på "fel" NUMA-zon.

Finns inget som pekar på att Infinity Fabric på något sätt är bättre eller för den del sämre än andra NUMA-designer som finns. Threadripper vs 1800X uppför sig i det närmaste identiskt jämfört med E5-2667v4 vs i7-6900K.

Finns absolut saker som skalar lysande över NUMA-zoner, de flesta servers är idag trots allt dual-socket (så två NUMA-noder). Men rätt få saker på skrivbordet skalar speciellt bra över NUMA (och det kommer fortsätta vara fallet så länge som latensen inte är lika låg som on-chip och bandbredden inte är lika hög).

Alla resultat i tabellen är genomsnittet av de tre senaste resultaten för respektive CPU i oklockat tillstånd och med 64-bitars Windows som OS. Noterade att Linux skalar klart bättre över NUMA-zoner i vissa fall, så där är genomsnittsvärdet för multitrådning bättre, så går inte att jämföra GB4 resultat från olika OS!!!

@Pudeln:
IF är det snabbaste som finns, vad gäller bandbredd mellan små kluster med kärnor, det är bara det att den designen passar dåligt för den lasten. Det är som vanligt, känn din last!

@sAAb: Det dina beräkningar pekar på är bl.a. att sättet Geekbench mäter latens är extremt opålitligt, personligen tycker jag just minnesmätningarna är totalt värdelösa i GB4 då de har otroligt dålig korrelation till prestanda i applikationer (och det gäller allt från mätningar på mobiler till server-kretsar).

Vidare är minneslatensen långt ifrån den viktigaste latensen för en CPU, framförallt på desktop där man normalt har extremt hög lokalitet av minnesaccesser -> väldigt hög cache-hit rate.

Det som spelar långt större roll är latensen för att upprätthålla en koherent bild av RAM över alla CPU-kärnor. Och häri ligger förklaringen till varför "read-only" fall faktiskt fungerar rätt OK på NUMA-system även om applikationen i fråga inte alls är skriven med NUMA i åtanke. I det läget kommer de flesta minnesaccesser hanteras via den lokala cachen.

Så fort man har skrivningar till minne som flera CPU-kärnor delar blir det problem. I det läget är bästa fallet en monolitiskt CPU-design där LLC (sista cache-nivå) inkluderar all information från lokala CPUer cache-nivåer, detta då ingen annan design gör det lika billigt att reda ut exakt om och i så fall vilka CPU-kärnor som måste notifieras om skrivningen.

Bl.a. spel gör saker som beror av detta vilket förklarar varför Intels CPU-modeller med ring-buss presterar bättre än både Ryzen och SKL-X. TechSpot har precis gjort en jämförelse mellan i7-7700K och i7-7800X, även om man överklockar den senare får den konsekvent stryk i spel av i7-7700K. Cache is king. Vad som är "kung" sett till design är däremt en funktion av arbetslast, Ryzen/SKL-X har en cache-design som vi sett presterar bättre än SKL-S när det handlar om att hantera väldigt många jobb som sinsemellan är oberoende (eller i alla fall det närmast oberoende).

Finns ju fall där även NUMA är en fördel! Har man två NUMA-zoner och jobbar med två helt oberoende uppgifter som båda äter RAM-bandbredd så kommer dessa uppgifter skala perfekt på ett NUMA-system men inte på ett system med en NUMA-nod (RAM blir då en flaskhals).