AMD Ryzen Threadripper – samlingstråd

Onekligen snygga och ett rejält lyft i prestanda!

http://www.clasohlson.com/se/view/content/search?gclid=EAIaIQ...

https://www.kjell.com/se/sok?query=pannlampa

Ditt system listar två NUMA-noder, det betyder att

• du körde i "local-mode"

• du hade ett system med två stycken single-channel bussar

Det som står i manualen var alltså helt inne på samma linje som jag.

Single-channel ger tyvärr ett visst negativt avtryck i vissa arbetslaster, men det har du ju åtgärdat nu med att ha fyra stickor i stället vilket ger två stycken dual-channel bussar.

Även om NUMA i praktiken är det bättre valet på Linux (och Windows-server) är det inte helt utan problem. Typiska desktop-applikationer har noll testning på NUMA-system, det vanligaste sättet detta manifesterar sig på är att prestanda mellan två körningar kan variera en hel del. Blir helt enkelt slumpen som avgör om minnet hamnar "nära" den CPU-kärna som råkar jobba med data (vilket ger en högre prestanda) eller om det hamnar "långt bort" (vilket ger en lägre prestanda).

Tack för förklaringen.

Uppdaterade BIOS, som sänkte prestanda liite till.

BIOS var tidigare "American Megatrends Inc. P1.30" men är nu "American Megatrends Inc. P2.00":

https://browser.geekbench.com/v4/cpu/compare/5519896?baseline...

Jo, NUMA-latensen ligger fortsatt högt, vilket jag rapporterat mer om i en annan tråd. Det som förbättrats här är SGEMM, SFFT och N-Body Physics, medan det mesta andra har sänkts lite grann.

Det är något magiskt här, eller, kanske det är naturligt stor variation i dessa benchmarks mellan körningar? Jag har inte kört dessa tillräckligt många gånger, men man kan ju konstatera generellt (oavsett värdena här) att benchmarks med hög "inre" variationskoefficient inte lär ge särskilt mycket relevant information.

EDIT: Okej, så var det dags för överklockning av cpu och minnen. Det gick mycket smidigt, på första försöket.

Jag följde instruktionerna på följande video och använde exakt samma värden. Beskrivningen är mellan 2:39 och 4:09 i följande klipp av "GGF Events" på Youtube:

https://www.youtube.com/watch?v=SK7LMHKxPdY&feature=youtu.be&...

Pang! Det fungerar direkt. Värden förbättras rejält; mycket rejält till och med, från drygt 46000 till över 54000 i Geekbench 4.2.0:

https://browser.geekbench.com/v4/cpu/5767724

Jag har alltså satt klockan till 4,1 GHz och minnena till 3200 MHz.

En kontroll med kommandot lscpu:

$ lscpu | grep MHz
CPU MHz:             2200.000
CPU max MHz:         4100.0000
CPU min MHz:         2200.0000

Mycket trevligt. En test av minnena:

# lshw -short -C memory
H/W path            Device     Class          Description
=========================================================
/0/0                           memory         64KiB BIOS
/0/10                          memory         32GiB System Memory
/0/10/0                        memory         [empty]
/0/10/1                        memory         8GiB DIMM DDR4 Synchronous Unbuffered (Unregistered) 3200 MHz (0.3 ns)
/0/10/2                        memory         [empty]
/0/10/3                        memory         8GiB DIMM DDR4 Synchronous Unbuffered (Unregistered) 3200 MHz (0.3 ns)
/0/10/4                        memory         [empty]
/0/10/5                        memory         8GiB DIMM DDR4 Synchronous Unbuffered (Unregistered) 3200 MHz (0.3 ns)
/0/10/6                        memory         [empty]
/0/10/7                        memory         8GiB DIMM DDR4 Synchronous Unbuffered (Unregistered) 3200 MHz (0.3 ns)
/0/12                          memory         1536KiB L1 cache
/0/13                          memory         8MiB L2 cache
/0/14                          memory         32MiB L3 cache

Det borde stämma, tror jag.

Det tål att ses igen:

https://browser.geekbench.com/v4/cpu/compare/5761556?baseline...

Latensen i multicore, 64.8 ns.

Ja jäklar!

Har äntligen börjat beställa alla delar för mitt nya Threadripper system som ska sättas ihop i nästa vecka, har väntat på chassit Cerberus X i månader och det släpptes äntligen.

Jag ska köra på 1950X, moderkort har redan kommit och valet föll på Gigabyte X399 Designare EX, för priset på ca 4K så tyckte jag att det gav en hel del.

RAM vill jag gärna ha feedback och tankar kring, använder datorn i 4K och 1440P och med 1800X så var det ingen nämnvärd skillnad mellan 2666MHz och 3200MHz, vad gäller för Threadripper eller vad har ni för erfarenheter? Mängden blir 32GB för priserna är helt uppåt väggarna i dagsläget.

Diskmässigt så planerar jag för 3 st Samsung 960 Evo, en för Windows 10 och två för spel och program som körs i Raid 0, synpunkter här, någon som kör raid 0 med TR?

Ska även ha en "vanlig" WD Black 4TB som lagring.

Kylning är hyfsat begränsat och med chassits storlek i åtanke så blev det en Enermax Liqtech 240 TR4, inget särskilt att säga annat än att jag hoppas att den är tillräckligt bra för att kyla.

Har ni förslag, idéer, vad tycker ni om TR, är ni nöjda eller något ni ångrar?

Mvh

Jag försöker hitta en stabil nivå just nu. 3200 MHz på minnena verkade inte fungera. Jag har rapporterat i en annan tråd också, #17183440

Jag skall alldeles strax testa Blender igen. Kylningen verkar vara viktig.

EDIT: Verkar vara min cpu som inte klarar 4.1 GHz, trots en kylning med Enermax Liqtech 360 TR4, och minnen sänkta till 2666 MHz; mer detaljer här.

Det är inget magiskt. Intels uttalande om "hopklistrade kärnor" var väldigt klumpigt, men grunden i uttalanden var tekniskt helt korrekt: problemet med en CPU där flera diskreta kretsar kopplas ihop med någon form av interconnect är exakt samma som för multisocket system.

Vad man får är ett system där total kapacitet skalar med antal kretsar/sockets, men man får också ett system med potentiellt hög varians varje enskild uppgift tar att hantera. Detta då prestanda är rätt mycket sämre om två trådar råkar hamna på olika CPU-kretsar, om aktivt RAM ligger på en NUMA-zon jämfört med den CPU-kärnan som utför jobbet.

Är effekter likt ovan som gör att Geekbench uppvisar hög varians. Tester har i grunden extremt låg varians om det körs på en monolitisk krets (brukar skilja någon enstaka procent mellan körningar). Du kan också få väldigt lång varians genom att tvinga Geekbench att hålla sig på en av CPU-kretsarna och på en specifik NUMA-zon.

Tror ändå att MCM kommer bli allt mer populärt på servers, detta då världen har ändrats. Idag är virtualisering allt viktigare och så länge varje instans använder lika många eller färre kärnor än vad som finns per CPU-krets finns en rad fördelar med MCM i form av lägre kostnad och högre total kapacitet.

Däremot kommer monolitiska kretsar fortfarande vara att föredra där man kör en applikation över väldigt många kärnor. Monolitiska kretsar är rent generellt att föredra överallt där låg latens och låg varians är viktigt.

Jo, jag insåg att det var något i den stilen.

Kan du inte testa th_ping på dina Ryzen?! Du hade väl både 1600 och 1700. Jag känner mig lite ensam med testandet och man behöver också en referenspunkt.

Jag har klockat ned till 4,05 MHz https://browser.geekbench.com/v4/cpu/5818725, men i stort bra värden, 50919. Inte illa för hopklistrade kärnor.

Har en R5-1600 som jag kör Ubuntu server på. Den är oklockad med DDR4-2933 CL16 minnen

th_ping

This system got 12 CPU-threads
 0 <-> 1  :  32 ns
 0 <-> 2  :  37 ns
 0 <-> 3  :  37 ns
 0 <-> 4  :  36 ns
 0 <-> 5  :  34 ns
 0 <-> 6  : 135 ns
 0 <-> 7  : 136 ns
 0 <-> 8  : 134 ns
 0 <-> 9  : 134 ns
 0 <-> 10 : 135 ns
 0 <-> 11 : 134 ns
 1 <-> 2  :  37 ns
 1 <-> 3  :  37 ns
 1 <-> 4  :  37 ns
 1 <-> 5  :  36 ns
 1 <-> 6  : 136 ns
 1 <-> 7  : 136 ns
 1 <-> 8  : 134 ns
 1 <-> 9  : 134 ns
 1 <-> 10 : 134 ns
 1 <-> 11 : 134 ns
 2 <-> 3  :  32 ns
 2 <-> 4  :  39 ns
 2 <-> 5  :  38 ns
 2 <-> 6  : 135 ns
 2 <-> 7  : 134 ns
 2 <-> 8  : 133 ns
 2 <-> 9  : 133 ns
 2 <-> 10 : 133 ns
 2 <-> 11 : 133 ns
 3 <-> 4  :  41 ns
 3 <-> 5  :  41 ns
 3 <-> 6  : 135 ns
 3 <-> 7  : 134 ns
 3 <-> 8  : 133 ns
 3 <-> 9  : 133 ns
 3 <-> 10 : 132 ns
 3 <-> 11 : 133 ns
 4 <-> 5  :  32 ns
 4 <-> 6  : 135 ns
 4 <-> 7  : 136 ns
 4 <-> 8  : 134 ns
 4 <-> 9  : 134 ns
 4 <-> 10 : 134 ns
 4 <-> 11 : 134 ns
 5 <-> 6  : 134 ns
 5 <-> 7  : 134 ns
 5 <-> 8  : 134 ns
 5 <-> 9  : 134 ns
 5 <-> 10 : 134 ns
 5 <-> 11 : 134 ns
 6 <-> 7  :  32 ns
 6 <-> 8  :  38 ns
 6 <-> 9  :  38 ns
 6 <-> 10 :  38 ns
 6 <-> 11 :  38 ns
 7 <-> 8  :  38 ns
 7 <-> 9  :  38 ns
 7 <-> 10 :  38 ns
 7 <-> 11 :  38 ns
 8 <-> 9  :  31 ns
 8 <-> 10 :  41 ns
 8 <-> 11 :  41 ns
 9 <-> 10 :  41 ns
 9 <-> 11 :  41 ns
10 <-> 11 :  31 ns

Som synes är konfigurationen: C0/T0, C0/T1, C1/T0,C1/T1,...
Första sex trådarna tillhör CCX0 och nästa sex trådar tillhör CCX1.

Lite skumt att det skiljer så lite mellan att kommunicera mellan två trådar på samma CPU-kärna och två CPU-trådar på olika kärnor i samma CCX.

Har gjort lite andra tester, i de flesta andra fall uppför sig Zen precis som Intel. D.v.s. är betydligt billigare om två trådar från samma fysiska kärna delar ett lås kring data. I dessa tester var det väldigt liten skillnad (<5 %) mellan att köra två kärnor i samma eller olika CCX.

Det är positivt då Zen inte så fall inte behöver optimeras på något annat sätt än Core (finns betydligt fler Core ute på marknaden...).

Edit:

This system got 32 CPU-threads
 4 <-> 5  :  45 ns
 4 <-> 12 : 187 ns
 4 <-> 20 :  13 ns

Hej!

Har du månne koll på om man kan få igång en numa-linux-kernel på Threadripper?
Försöker jag slå på numa i kernel-konfig så bootar maskinen om direkt, får inte ens nåt meddelande från kerneln. (Har kört numa på andra system, så har iallafall lyckats förr)

Då körde jag med 4 minnesstickor och interleave = channel.
Har nu bytt till interleave = die, och får ungefär dubbla minnesbandbredden, ca 1GB/sec/thread för alla 32 trådar jämfört mot ca 730 resp 360 MB/sec för vardera hälften av trådarna med interleave=channel.

Kör lite underklockat just nu; 1.064V enligt bios och minnet går i 1866 MHz.
Det lustiga är att klockar jag upp minnet till 2666 så ökar bara bandbredden ca 11%, så finns nån annan begränsning än minnet. Infinity fabric ska ju följa minneshastigheten om jag fattat rätt, så borde inte vara den. (Har ECC minne, specat till 2133, har ännu ej provat högre än 2666)

mer info och prestanda under GB4 här:

https://browser.geekbench.com/v4/cpu/5819928

Några ideer?

Kommande kärnan Linux 4.15 innehåller ytterligare förbättringar för EPYC (och förhoppningsvis därmed även för Threadripper) med fokus på NUMA.

Nu är release-candidate 5 ute, https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.1...

Det som kommer att ingå listas här https://www.phoronix.com/scan.php?page=article&item=linux-415...

där det ingår förbättrad NUMA-balansering https://www.phoronix.com/scan.php?page=news_item&px=AMD-EPYC-...

vilket redan syns i preliminära benchmarks https://www.phoronix.com/scan.php?page=news_item&px=AMD-EPYC-...

Den lär bli officiell om tre veckor. Men, du måste kompilera Linux 4.15 själv om du vill testa redan nu.

Tack, ska ta och prova 4.15 och se om den går bättre.

Edit:

Provade 4.15 och där kraschade även icke-numa versionen direkt... Efter en del bråkande med den visade det sig att elilo inte kan ladda kärnor större än 8MiB... så efter att ha tagit bort en del driv som inte behövdes fick jag igång numa versionen. Sen om den är bättre får man väl ta och fundera på. Dock verkar det löna sig bättre att klocka upp minnet lite i denna mod.

Enligt GB4 gick multicore-minnesbandbredden upp från 30 GB/s till 40 GB/s, däremot gick multicore poängen ned från 44860 till 42551.

Alla trådar får nu samma minnesbandbredd:

rippy:~/numatest$ ./numatest
Number of instances: < 1 > : 32
Done: 52 loops in 10.01 seconds --> 1039.07 mb/s
Done: 52 loops in 10.01 seconds --> 1039.01 mb/s
Done: 53 loops in 10.06 seconds --> 1053.71 mb/s
Done: 52 loops in 10.01 seconds --> 1038.46 mb/s
Done: 53 loops in 10.06 seconds --> 1053.65 mb/s
Done: 52 loops in 10.03 seconds --> 1037.39 mb/s
Done: 53 loops in 10.08 seconds --> 1051.24 mb/s
Done: 52 loops in 10.04 seconds --> 1036.06 mb/s
Done: 53 loops in 10.08 seconds --> 1051.52 mb/s
Done: 53 loops in 10.09 seconds --> 1050.72 mb/s
Done: 52 loops in 10.04 seconds --> 1036.02 mb/s
Done: 53 loops in 10.07 seconds --> 1052.87 mb/s
Done: 53 loops in 10.10 seconds --> 1049.80 mb/s
Done: 53 loops in 10.10 seconds --> 1049.69 mb/s
Done: 53 loops in 10.11 seconds --> 1048.40 mb/s
Done: 53 loops in 10.14 seconds --> 1045.00 mb/s
Done: 53 loops in 10.12 seconds --> 1047.49 mb/s
Done: 53 loops in 10.17 seconds --> 1041.99 mb/s
Done: 53 loops in 10.16 seconds --> 1043.41 mb/s
Done: 53 loops in 10.14 seconds --> 1045.08 mb/s
Done: 53 loops in 10.18 seconds --> 1041.45 mb/s
Done: 53 loops in 10.16 seconds --> 1043.54 mb/s
Done: 53 loops in 10.16 seconds --> 1043.65 mb/s
Done: 53 loops in 10.19 seconds --> 1040.71 mb/s
Done: 53 loops in 10.18 seconds --> 1041.14 mb/s
Done: 53 loops in 10.15 seconds --> 1043.96 mb/s
Done: 53 loops in 10.19 seconds --> 1040.70 mb/s
Done: 53 loops in 10.19 seconds --> 1039.82 mb/s
Done: 53 loops in 10.20 seconds --> 1038.94 mb/s
Done: 53 loops in 10.20 seconds --> 1039.07 mb/s
Done: 53 loops in 10.19 seconds --> 1040.36 mb/s
Done: 53 loops in 10.18 seconds --> 1040.87 mb/s

Däremot om en tråd vill använda mer än halva minnet så sänks bandbredden:
(har 16 GiB här och varje block är 500MB)

rippy:~/numatest$ ./numatest2
Number of 500MB blocks to alloc and test: < 1 > : 32
Block-001: 46 loops in 5.03 seconds --> 9147.55 mb/s
Block-002: 46 loops in 5.04 seconds --> 9131.65 mb/s
Block-003: 46 loops in 5.01 seconds --> 9172.73 mb/s
Block-004: 47 loops in 5.05 seconds --> 9311.07 mb/s
Block-005: 47 loops in 5.03 seconds --> 9346.23 mb/s
Block-006: 47 loops in 5.01 seconds --> 9376.67 mb/s
Block-007: 47 loops in 5.03 seconds --> 9347.39 mb/s
Block-008: 47 loops in 5.01 seconds --> 9385.57 mb/s
Block-009: 47 loops in 5.03 seconds --> 9341.65 mb/s
Block-010: 47 loops in 5.01 seconds --> 9377.38 mb/s
Block-011: 47 loops in 5.01 seconds --> 9375.20 mb/s
Block-012: 47 loops in 5.04 seconds --> 9333.39 mb/s
Block-013: 47 loops in 5.03 seconds --> 9348.05 mb/s
Block-014: 47 loops in 5.03 seconds --> 9346.98 mb/s
Block-015: 47 loops in 5.03 seconds --> 9342.40 mb/s
Block-016: 44 loops in 5.11 seconds --> 8612.45 mb/s
Block-017: 32 loops in 5.01 seconds --> 6383.93 mb/s
Block-018: 33 loops in 5.05 seconds --> 6533.91 mb/s
Block-019: 33 loops in 5.16 seconds --> 6401.04 mb/s
Block-020: 33 loops in 5.10 seconds --> 6467.65 mb/s
Block-021: 33 loops in 5.11 seconds --> 6456.87 mb/s
Block-022: 33 loops in 5.10 seconds --> 6474.54 mb/s
Block-023: 33 loops in 5.11 seconds --> 6458.17 mb/s
Block-024: 34 loops in 5.14 seconds --> 6609.67 mb/s
Block-025: 33 loops in 5.10 seconds --> 6474.90 mb/s
Block-026: 33 loops in 5.10 seconds --> 6468.53 mb/s
Block-027: 33 loops in 5.11 seconds --> 6459.57 mb/s
Block-028: 34 loops in 5.15 seconds --> 6607.97 mb/s
Block-029: 33 loops in 5.10 seconds --> 6470.05 mb/s
Block-030: 33 loops in 5.10 seconds --> 6471.53 mb/s
Block-031: 34 loops in 5.15 seconds --> 6607.58 mb/s
Block-032: 33 loops in 5.06 seconds --> 6525.90 mb/s
rippy:~/numatest$

Och nu finns även nån sorts tempsensorer, så nu kan man ju prova med lite överklockning.

rippy:~/numatest$ sensors # idle temps.
asus-isa-0000
Adapter: ISA adapter
cpu_fan: 0 RPM

k10temp-pci-00c3
Adapter: PCI adapter
temp1: +25.8°C (high = +70.0°C)

k10temp-pci-00cb
Adapter: PCI adapter
temp1: +25.8°C (high = +70.0°C)

This system got 12 CPU-threads
 0 <-> 1  :  32 ns
 0 <-> 2  :  37 ns
 0 <-> 3  :  37 ns
 0 <-> 4  :  36 ns
 0 <-> 5  :  34 ns
 0 <-> 6  : 135 ns
 0 <-> 7  : 136 ns
 0 <-> 8  : 134 ns
 0 <-> 9  : 134 ns
 0 <-> 10 : 135 ns
 0 <-> 11 : 134 ns
 1 <-> 2  :  37 ns
 1 <-> 3  :  37 ns
 1 <-> 4  :  37 ns
 1 <-> 5  :  36 ns
 1 <-> 6  : 136 ns
 1 <-> 7  : 136 ns
 1 <-> 8  : 134 ns
 1 <-> 9  : 134 ns
 1 <-> 10 : 134 ns
 1 <-> 11 : 134 ns
 2 <-> 3  :  32 ns
 2 <-> 4  :  39 ns
 2 <-> 5  :  38 ns
 2 <-> 6  : 135 ns
 2 <-> 7  : 134 ns
 2 <-> 8  : 133 ns
 2 <-> 9  : 133 ns
 2 <-> 10 : 133 ns
 2 <-> 11 : 133 ns
 3 <-> 4  :  41 ns
 3 <-> 5  :  41 ns
 3 <-> 6  : 135 ns
 3 <-> 7  : 134 ns
 3 <-> 8  : 133 ns
 3 <-> 9  : 133 ns
 3 <-> 10 : 132 ns
 3 <-> 11 : 133 ns
 4 <-> 5  :  32 ns
 4 <-> 6  : 135 ns
 4 <-> 7  : 136 ns
 4 <-> 8  : 134 ns
 4 <-> 9  : 134 ns
 4 <-> 10 : 134 ns
 4 <-> 11 : 134 ns
 5 <-> 6  : 134 ns
 5 <-> 7  : 134 ns
 5 <-> 8  : 134 ns
 5 <-> 9  : 134 ns
 5 <-> 10 : 134 ns
 5 <-> 11 : 134 ns
 6 <-> 7  :  32 ns
 6 <-> 8  :  38 ns
 6 <-> 9  :  38 ns
 6 <-> 10 :  38 ns
 6 <-> 11 :  38 ns
 7 <-> 8  :  38 ns
 7 <-> 9  :  38 ns
 7 <-> 10 :  38 ns
 7 <-> 11 :  38 ns
 8 <-> 9  :  31 ns
 8 <-> 10 :  41 ns
 8 <-> 11 :  41 ns
 9 <-> 10 :  41 ns
 9 <-> 11 :  41 ns
10 <-> 11 :  31 ns

This system got 32 CPU-threads
 4 <-> 5  :  45 ns
 4 <-> 12 : 187 ns
 4 <-> 20 :  13 ns

Jag blir förvånad av dina intra-ccx-resultat, på mellan 30 till 40 ns. Oklockat låg mina på mellan 18 och 22 ns, och nu när jag överklockat ligger de på högre värden, mellan 20 och 30. Båda med spänningen på 1.36250 V.

• Här är oklockade @ stock: 3.4 GHz och 2133 MHz

• Här är överklockade: 4.1 GHz och 3200 MHz

Har du någon förklaring varför dina ligger högre inom CCX:erna?

Skall fortsätta jaga stabila värden på min överklockning. Hittade följande diagram i en artikel i techpowerup.com som verkar vara en bra utgångspunkt för spänningen:

Jag har snålat med spänningen inser jag. Förvisso är det värden för Ryzen 1800X, men så stor skillnad bör det inte vara; tvekar lite på nyttan med 4.1 mot 4.0 när man ser det här diagrammet. Fast, jag kör ju ändå i blindo just nu, då jag inte har lm-sensors än; den kommer först med Linux 4.15 som jag kanske nämnt tidigare.

Rätt udda att latensen ökar för dig när du klockar högre, fast är något som jag kan reproducera!

Tänkte först att jag inte ändrade "scaling govenor" från den normala "ondemand", misstänkte då att latensen kanske blev lite hög p.g.a. tiden det tar att rampa upp frekvensen.

Grejen är att latensen ökar till 40 ns med "performance" (som alltid kör i maxfrekvens) och minskar till 26 ns med "conservative" (som kör med lägsta frekvens, eller borde i alla fall, ser ut som det ger 3,2 GHz på alla kärnor för mig vilket knappast är lägsta frekvens).

Tror man kan dra slutsatsen: den här "thread ping" testet är ett typiskt micro-benchmark som inte säger något alls. Är rätt säker på att det inte är någon bug i "th_ping" då det ger mer eller mindre identiskt resultat med motsvarande program som PC-perspective kör med (rätt osannolikt att vi skulle gjort exakt samma bug).

Har sett det i lite andra micro-benchmarks, ibland får man helt sanslöst hög prestanda med Ryzen som inte alls går att se i mer "verkliga" resultat.

Jag tror nog att th_ping förklarar mina latenser i Geekbench, där de ibland ligger på runt 80 ns men allt som oftast på runt 145 ns. Det lär då bero på de där hemska hoppen över raviner, på upp till 320 ns. Jo, th_ping är bra!

Hittade ytterligare reflektioner på överklockning av TR4, på [H]ardOCP - https://www.hardocp.com/article/2017/08/20/threadripper_at_4g... Kyle sammanfattar det med "Be prepared for a lot of trial and error", men nämner att man behöver ha koll på temperaturen också för ett långsiktigt stabilt system.

EDIT: Uppgraderade grafikkortet. Tyckte att Sweclockers test var övertygande - tyst och lugnt; ASUS 1070 Ti Strix blev det.

EDIT: geekbenchs latenser är ju mot minnena... Duh

Visst förklarar th_ping en hel del. Här är geekbench mot th_ping. Det är tydliga samband för både single och multi:

Fick nu 55269 på 4.1 GHz (med 1,40000 V) och 3200 MHz på minnena, https://browser.geekbench.com/v4/cpu/5884597

Jag försökte sänka tCL på minnena från CL16 men vid CL14 bootar det inte och vid CL15 sänktes såväl th_ping som Geekbench något.

Nej, det är inte fullt ut stabilt. Blender fryser datorna, men å andra sidan saknar Asrock fortfarande UMA ("distributed") och har ännu enbart NUMA ("local"); Blender gillar bandbredd.

Men, Civilization VI och annat fungerar bra, så... Jag är mycket nöjd för stunden.

Har inget TR-system så kan inte testa NUMA-prylarna där. Har nu lagt till en axel till i th_ping (vet inte hur det namnet kom till, ska ju alltid vara "a three letter acronym" så ändrat till thr_ping ).

Har bara fixat Linux-stödet (bygger inte ens på Windows längre), nu måste man även länka med libnuma. I Debian-baserade distros installeras detta med

$ sudo apt-get install libnuma-dev

och man bygger t.ex. på detta sätt

make CXXFLAGS="-std=c++11 -O3 -march=native -pthread" LDLIBS="-lnuma" thr_ping

Källkoden finns här, lägg i en fil med namnet thr_ping.cpp

Min misstanke är denna: till och med inom en CPU-krets har Zen ett CCX-to-CCX latensberoende på RAM-latens (är absolut RAM-latens som spelar roll, att RAM-frekvensen spelar roll är bara en bieffekt av att högre RAM-frekvens med bibehållen CL ger lägre RAM-latens), som programmet var skrivet innan lär den cache-line som används för core-to-core kommunikation i princip alltid hamna på NUMA-node 0 och aldrig flyttas.

Att mitt program ser en skillnad mot PC-Perspective program på TR på "andra" CPU-kretsens inter-CCX latens kan mycket väl bero på att PC-per allokerar sin minneskanal på heap:en inför varje körning -> normalt kommer då både Windows och Linux att allokera minnet på den NUMA-nod som är "nära" den CPU-tråd som allokerar minnet.

Detta är hyfsat logiskt om man tänker på hur L3$ är konstruerad i Zen och om man har lite koll på MESI (Zen kör antagligen MOESI då AMD använt detta i tidigare designer, irrelevant för denna diskussion). Faktum är att cache-lines i "S" tillståndet kommer i vissa läge se ett beroende på RAM-latens även om det är två kärnor på samma CCX som kommunicerar.

Vad jag gör nu är att allokera kommunikationskanalen på heap:en, det via libnuma så jag kan välja vilken NUMA-zon minnet hamnar på. Kör sedan ett vända mer NUMA-zon.

Detta ger NOLL skillnad på dual-socket Xeon E5 2690, vilket är rätt väntat givet den CPUns cache-policy och L3$ layout. D.v.s. får inom felmarginalen samma latens oavsett om kommunikationskanalen ligger på samma eller olika NUMA-zon som de kärnor som kommunicerar. Logiskt här då RAM i praktiken inte används all vid kommunikation, kanalen består av en enda cache-line.

Misstänker att kommunikation som går mellan kärnor som inte delar någon cache-nivå på Zen (d.v.s. all kommunikation utanför ett CCX) alltid får ett beroende på RAM och därmed ett beroende på latens mot RAM (bandbredd är totalt irrelevant för thr_ping).

Edit: pastebin verkar var lite sådär när det kommer till tillförlitlighet. Lägger in källkoden här också

// Either remove "stdafx.h" on non-Windows platforms, or create an empty file
// with that name.
#include "stdafx.h"

#ifdef WIN32
#include <windows.h>
#else
#include <pthread.h>
#include <numa.h>
#endif

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#include <atomic>
#include <chrono>
#include <condition_variable>
#include <iomanip>
#include <iostream>
#include <memory>
#include <set>
#include <string>
#include <thread>
#include <vector>

using namespace std;

// SMT on x86, tell the CPU-thread to relax a bit while busy waiting
#ifdef WIN32
#define cpu_relax() __asm { pause }
#else
#if defined(__i386__) || defined(__x86_64)
#define cpu_relax() asm volatile("pause" ::: "memory")
#else
#define cpu_relax() asm volatile ("" ::: "memory")
#endif
#endif

typedef uint32_t num_t;
typedef uint32_t cpu_id;
typedef enum tse
    {
    THR_READY,
    THR_STEADY,
    THR_GO
    } thr_state_e;

// Global state to implement a rendevouz for the two communicating threads
mutex                   mtx;
condition_variable      cv;
thr_state_e             thr_state;

static void rendevouz(void)
    {
    unique_lock<mutex> lock(mtx);

    if (thr_state == THR_READY)
        {
        thr_state = THR_STEADY;
        cv.wait(lock, [] { return thr_state == THR_GO; });
        }
    else
        {
        thr_state = THR_GO;
        cv.notify_all();
        }
    }

[[noreturn]] static void panic(const char * desc)
    {
    perror(desc);
    exit(EXIT_FAILURE);
    }

// Binds a software thread to a specific CPU-thread
static void cpu_bind
    (
    cpu_id c
    )
    {
#ifdef WIN32
    if (SetThreadAffinityMask(GetCurrentThread(), 1UL << c) == 0)
        {
        panic("SetThreadAffinityMask() failed");
        }
#else
    cpu_set_t cpu;

    CPU_ZERO(&cpu);
    CPU_SET(c, &cpu);
    if (pthread_setaffinity_np(pthread_self(), sizeof cpu, &cpu) != 0)
        {
        panic("pthread_setaffinity_np() failed");
        }
#endif
    }

void worker
    (
    atomic<num_t> &ch,
    atomic<bool> &is_done,
    cpu_id cpu_thread,
    uint32_t *latency
    )
    {
    num_t cnt = (latency == nullptr ? 1 : 0);
    cpu_bind(cpu_thread);
    rendevouz();

    auto startClk = chrono::steady_clock::now();
    while (!is_done.load(memory_order_relaxed))
        {
        if (ch.load(memory_order_relaxed) == cnt)
            {
            cnt = ch.fetch_add(1, memory_order_relaxed) + 2;
            }
        else
            {
            cpu_relax();
            }
        }

    if (latency != nullptr)
        {
        auto endClk = chrono::steady_clock::now();
        auto duration = chrono::duration_cast<chrono::nanoseconds>(endClk - startClk);
        *latency = duration.count() / cnt;
        }
    };

static void measure
    (
    cpu_id cpu_threads,
    const set<cpu_id> &cpu_filter,
    int numa_node = 0
    )
    {
    for (cpu_id ping_id = 0; ping_id < cpu_threads - 1; ping_id++)
        {
        for (cpu_id pong_id = ping_id + 1; pong_id < cpu_threads; pong_id++)
            {
            if (cpu_filter.count(ping_id) + cpu_filter.count(pong_id) != 2)
                {
                continue;
                }

            cout << setw(2) << ping_id << " <-> "
                 << setw(2) << left << pong_id << right << flush;

            atomic<num_t> *channel;

            channel = static_cast<atomic<num_t>*>(numa_alloc_onnode(sizeof *channel, numa_node));

            atomic<bool> is_done{ false };
            uint32_t latency;
            thread ping(worker, ref(*channel), ref(is_done), ping_id, &latency);
            thread pong(worker, ref(*channel), ref(is_done), pong_id, nullptr);

            this_thread::sleep_for(chrono::seconds(4));
            is_done.store(true);
            ping.join();
            pong.join();

            cout << " : " << setw(3) << latency << " ns" << endl;

            numa_free(channel, sizeof *channel);
            }
        }
    }

static set<cpu_id> parse_args
    (
    const vector<string> &args,
    cpu_id cpu_cnt
    )
    {
    set<cpu_id> filter;

    if (args.size() == 0)
        {
        for (int c = 0; c < cpu_cnt; c++)
            {
            filter.insert(c);
            }
        }
    else
        {
        for (auto cpu_thr: args)
            {
            filter.insert(stoi(cpu_thr));
            }
        }

    return filter;
    }

int main
    (
    int argc,
    char *argv[]
    )
    {
    auto num_numa_nodes = numa_num_task_nodes();

    try
        {
        vector<string> args(argv + 1, argv + argc);
        cpu_id cpu_threads = thread::hardware_concurrency();
        auto cpu_filter = parse_args(args, cpu_threads);

        cout << "This system got " << cpu_threads << " CPU-threads and "
             << num_numa_nodes << " NUMA nodes." << endl;
        for (auto numa_node = 0; numa_node < num_numa_nodes; numa_node++)
            {
            cout << "Allocate from NUMA node " << numa_node << endl;
            measure(cpu_threads, cpu_filter);
            }
        }
    catch (...)
        {
        cerr << "Usage: " << argv[0] << " [CPUTHR0 CPUTHR1 ...]" << endl;
        }
    }

// Local Variables:
// compile-command: "make CXXFLAGS=\"-std=c++11 -O2 -pthread\" LDLIBS=\"-lnuma\" th_ping"
// End:

$ sudo apt-get install libnuma-dev

make CXXFLAGS="-std=c++11 -O3 -march=native -pthread" LDLIBS="-lnuma" thr_ping

// Either remove "stdafx.h" on non-Windows platforms, or create an empty file
// with that name.
#include "stdafx.h"

#ifdef WIN32
#include <windows.h>
#else
#include <pthread.h>
#include <numa.h>
#endif

#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <time.h>

#include <atomic>
#include <chrono>
#include <condition_variable>
#include <iomanip>
#include <iostream>
#include <memory>
#include <set>
#include <string>
#include <thread>
#include <vector>

using namespace std;

// SMT on x86, tell the CPU-thread to relax a bit while busy waiting
#ifdef WIN32
#define cpu_relax() __asm { pause }
#else
#if defined(__i386__) || defined(__x86_64)
#define cpu_relax() asm volatile("pause" ::: "memory")
#else
#define cpu_relax() asm volatile ("" ::: "memory")
#endif
#endif

typedef uint32_t num_t;
typedef uint32_t cpu_id;
typedef enum tse
    {
    THR_READY,
    THR_STEADY,
    THR_GO
    } thr_state_e;

// Global state to implement a rendevouz for the two communicating threads
mutex                   mtx;
condition_variable      cv;
thr_state_e             thr_state;

static void rendevouz(void)
    {
    unique_lock<mutex> lock(mtx);

    if (thr_state == THR_READY)
        {
        thr_state = THR_STEADY;
        cv.wait(lock, [] { return thr_state == THR_GO; });
        }
    else
        {
        thr_state = THR_GO;
        cv.notify_all();
        }
    }

[[noreturn]] static void panic(const char * desc)
    {
    perror(desc);
    exit(EXIT_FAILURE);
    }

// Binds a software thread to a specific CPU-thread
static void cpu_bind
    (
    cpu_id c
    )
    {
#ifdef WIN32
    if (SetThreadAffinityMask(GetCurrentThread(), 1UL << c) == 0)
        {
        panic("SetThreadAffinityMask() failed");
        }
#else
    cpu_set_t cpu;

    CPU_ZERO(&cpu);
    CPU_SET(c, &cpu);
    if (pthread_setaffinity_np(pthread_self(), sizeof cpu, &cpu) != 0)
        {
        panic("pthread_setaffinity_np() failed");
        }
#endif
    }

void worker
    (
    atomic<num_t> &ch,
    atomic<bool> &is_done,
    cpu_id cpu_thread,
    uint32_t *latency
    )
    {
    num_t cnt = (latency == nullptr ? 1 : 0);
    cpu_bind(cpu_thread);
    rendevouz();

    auto startClk = chrono::steady_clock::now();
    while (!is_done.load(memory_order_relaxed))
        {
        if (ch.load(memory_order_relaxed) == cnt)
            {
            cnt = ch.fetch_add(1, memory_order_relaxed) + 2;
            }
        else
            {
            cpu_relax();
            }
        }

    if (latency != nullptr)
        {
        auto endClk = chrono::steady_clock::now();
        auto duration = chrono::duration_cast<chrono::nanoseconds>(endClk - startClk);
        *latency = duration.count() / cnt;
        }
    };

static void measure
    (
    cpu_id cpu_threads,
    const set<cpu_id> &cpu_filter,
    int numa_node = 0
    )
    {
    for (cpu_id ping_id = 0; ping_id < cpu_threads - 1; ping_id++)
        {
        for (cpu_id pong_id = ping_id + 1; pong_id < cpu_threads; pong_id++)
            {
            if (cpu_filter.count(ping_id) + cpu_filter.count(pong_id) != 2)
                {
                continue;
                }

            cout << setw(2) << ping_id << " <-> "
                 << setw(2) << left << pong_id << right << flush;

            atomic<num_t> *channel;

            channel = static_cast<atomic<num_t>*>(numa_alloc_onnode(sizeof *channel, numa_node));

            atomic<bool> is_done{ false };
            uint32_t latency;
            thread ping(worker, ref(*channel), ref(is_done), ping_id, &latency);
            thread pong(worker, ref(*channel), ref(is_done), pong_id, nullptr);

            this_thread::sleep_for(chrono::seconds(4));
            is_done.store(true);
            ping.join();
            pong.join();

            cout << " : " << setw(3) << latency << " ns" << endl;

            numa_free(channel, sizeof *channel);
            }
        }
    }

static set<cpu_id> parse_args
    (
    const vector<string> &args,
    cpu_id cpu_cnt
    )
    {
    set<cpu_id> filter;

    if (args.size() == 0)
        {
        for (int c = 0; c < cpu_cnt; c++)
            {
            filter.insert(c);
            }
        }
    else
        {
        for (auto cpu_thr: args)
            {
            filter.insert(stoi(cpu_thr));
            }
        }

    return filter;
    }

int main
    (
    int argc,
    char *argv[]
    )
    {
    auto num_numa_nodes = numa_num_task_nodes();

    try
        {
        vector<string> args(argv + 1, argv + argc);
        cpu_id cpu_threads = thread::hardware_concurrency();
        auto cpu_filter = parse_args(args, cpu_threads);

        cout << "This system got " << cpu_threads << " CPU-threads and "
             << num_numa_nodes << " NUMA nodes." << endl;
        for (auto numa_node = 0; numa_node < num_numa_nodes; numa_node++)
            {
            cout << "Allocate from NUMA node " << numa_node << endl;
            measure(cpu_threads, cpu_filter);
            }
        }
    catch (...)
        {
        cerr << "Usage: " << argv[0] << " [CPUTHR0 CPUTHR1 ...]" << endl;
        }
    }

// Local Variables:
// compile-command: "make CXXFLAGS=\"-std=c++11 -O2 -pthread\" LDLIBS=\"-lnuma\" th_ping"
// End:

Coolt! Testade Threadpinger igen, nu med det nya namnet!

Threadipper 1950X 4.1 GHz, 1.4 V
DDR4 Corsair Vengeance LPX 3200MHz CL16

Jag startar ("./") programmet (thr_ping) med en pipe (">") så att resultatet åker rakt in i en textfil som kallas "thr_ping.txt". Jag är lite övertydlig här så att andra kan testa själva på Linux. Så här ser det ut vid "prompten" som vanlig användare :

./thr_ping > thr_ping.txt

Därefter trycker man Enter och Threadpinger rasslar igenom samtliga hårdvarutrådar. Det tar över tjugofem minuter att köra det med trettiotvå hårdvarutrådar; datorn är ju låst under tiden då man inte vill påverka tiderna. Har man färre kärnor går det på några enstaka minuter. Därefter startar jag statistikpaketet R, med kommandot R...

R

Väl inne i R klistrar jag in följande skript, allt i ett svep:

thr <- as.matrix(read.table("thr_ping.txt", row.names=NULL, skip=1))
thr <- t(apply(thr[, c(1,3,5)], 1, as.numeric))
thr <- cbind(t(t(thr[,c(1,2)]+1)),t(t(thr[,3])))
write.csv(thr, file = "thr_ping.csv")
png(filename="thr_ping.png",width = 768, height = 480, units = "px", bg = "white")
hist(thr[,3],xlim=c(0,300), ylim=c(0, 300), xlab="Latency (ns)",breaks=seq(0,300,by=10), main="Thread ping times (ns)")
dev.off()

Det tar någon sekund och så får man ett stapeldiagram med fördelningen av latenstiderna i nanosekunder (ns) samtidigt som allt sparas i en fil som är enkel att importera till ett kalkylark, t.ex. Google Sheets, LibreOffice Calc eller något liknande från t.ex. Microsoft. Här är rådata, upplagt i Pastebin. Här är stapeldiagrammet från R, thr_ping.png:

Jag vet inte hur mycket förändringar som gjorts, men latenserna är lägre än tidigare. Här är tre olika percentiler, 1%, 50% och 99%:

P01:  17
P50: 234
P99: 269

Hur gick det med din Ryzen? Fick du samma värden?

EDIT: Glömde säga att Serve the home har en test av latenser, på EPYC. De diskuterar även blockdiagrammen.

https://www.servethehome.com/amd-epyc-infinity-fabric-latency...

I en ny test från häromdagen återupprepar de sin ståndpunkt att snabbare minnen är viktigt, även för de som vill köra ECC.

https://www.servethehome.com/amd-epyc-7301-dual-socket-linux-...

Jo, det gäller ju även Threadripper.

./thr_ping > thr_ping.txt

R

thr <- as.matrix(read.table("thr_ping.txt", row.names=NULL, skip=1))
thr <- t(apply(thr[, c(1,3,5)], 1, as.numeric))
thr <- cbind(t(t(thr[,c(1,2)]+1)),t(t(thr[,3])))
write.csv(thr, file = "thr_ping.csv")
png(filename="thr_ping.png",width = 768, height = 480, units = "px", bg = "white")
hist(thr[,3],xlim=c(0,300), ylim=c(0, 300), xlab="Latency (ns)",breaks=seq(0,300,by=10), main="Thread ping times (ns)")
dev.off()

P01:  17
P50: 234
P99: 269

Du borde få två uppsättningar resultat nu, ett för NUMA-zon 0 och ett för NUMA-zon 1. Kanske missade det, men tyckte inte jag ser det i dina data.

Verkar som allokering på heap:en av någon outgrundlig anledning minskade intra-CCX latensen på min R5-1600

This system got 12 CPU-threads and 1 NUMA nodes.
Allocate from NUMA node 0
 0 <-> 1  :  23 ns
 0 <-> 2  :  25 ns
 0 <-> 3  :  23 ns
 0 <-> 4  :  25 ns
 0 <-> 5  :  22 ns
 0 <-> 6  : 132 ns
 0 <-> 7  : 126 ns
 0 <-> 8  : 128 ns
 0 <-> 9  : 128 ns
 0 <-> 10 : 129 ns
 0 <-> 11 : 130 ns
 1 <-> 2  :  26 ns
 1 <-> 3  :  23 ns
 1 <-> 4  :  26 ns
 1 <-> 5  :  22 ns
 1 <-> 6  : 132 ns
 1 <-> 7  : 127 ns
 1 <-> 8  : 130 ns
 1 <-> 9  : 128 ns
 1 <-> 10 : 130 ns
 1 <-> 11 : 129 ns
 2 <-> 3  :  23 ns
 2 <-> 4  :  28 ns
 2 <-> 5  :  25 ns
 2 <-> 6  : 134 ns
 2 <-> 7  : 127 ns
 2 <-> 8  : 129 ns
 2 <-> 9  : 130 ns
 2 <-> 10 : 131 ns
 2 <-> 11 : 130 ns
 3 <-> 4  :  29 ns
 3 <-> 5  :  26 ns
 3 <-> 6  : 134 ns
 3 <-> 7  : 127 ns
 3 <-> 8  : 129 ns
 3 <-> 9  : 133 ns
 3 <-> 10 : 130 ns
 3 <-> 11 : 131 ns
 4 <-> 5  :  23 ns
 4 <-> 6  : 130 ns
 4 <-> 7  : 129 ns
 4 <-> 8  : 132 ns
 4 <-> 9  : 130 ns
 4 <-> 10 : 131 ns
 4 <-> 11 : 130 ns
 5 <-> 6  : 131 ns
 5 <-> 7  : 131 ns
 5 <-> 8  : 129 ns
 5 <-> 9  : 130 ns
 5 <-> 10 : 131 ns
 5 <-> 11 : 130 ns
 6 <-> 7  :  23 ns
 6 <-> 8  :  27 ns
 6 <-> 9  :  23 ns
 6 <-> 10 :  27 ns
 6 <-> 11 :  24 ns
 7 <-> 8  :  26 ns
 7 <-> 9  :  24 ns
 7 <-> 10 :  26 ns
 7 <-> 11 :  23 ns
 8 <-> 9  :  23 ns
 8 <-> 10 :  25 ns
 8 <-> 11 :  25 ns
 9 <-> 10 :  25 ns
 9 <-> 11 :  26 ns
10 <-> 11 :  20 ns

Visa innehåll

histogram

För TR gissar jag att CCX-till-CCX latens inom en viss CPU-krets är lägre/högre (CPU#0/CPU#1) när man allokerar från NUMA-zon 0 och högre/lägre när man allokerar från NUMA-zon 1. Detta då NUMA-zon 0 är "nära" CPU#0 men "långt från" CPU#1, för NUMA-zon 1 gäller det omvända.

PC-perspective får inte riktigt samma resultat. De har ungefär samma absolutlatens mellan CPU-trådar som delar fysisk kärna samt mellan CCX, thr_ping verkar dock få latensen till ett betydligt lägre värde för kärnor inom ett CCX.

Är inte helt på det klara med hur deras program fungerar, thr_ping mäter tiden det tar för atomic-increment på en integer att propagera mellan CPU-trådar.

Sh här ser utfilen ut nu för mig. Den inleds med följande två rader:

This system got 32 CPU-threads and 1 NUMA nodes.
Allocate from NUMA node 0

Det framgick inte att den skulle vara uppdelad per NUMA vad jag kunde se.

Jämför gärna latenserna med både pcper.com och servethehome.com. Ingen av dem har något i stil med 20 ns; de lägsta ligger snarare runt 60-80 ns, vilket är mer i stil med det som Geekbench rapporterar.

This system got 32 CPU-threads and 1 NUMA nodes.
Allocate from NUMA node 0

Undrar om det är något strul med libnuma på TR då, hade förväntat mig detta (CPU-tråd 1 och 2 är samma CPU, 1 och 17 är olika trådar på samma kärna samt 1 och 8 ligger på olika sockets, detta på Xeon E5 2690 som är en Sandy Bridge).

$ ./thr_ping 1 2 8 17
This system got 32 CPU-threads and 2 NUMA nodes.
Allocate from NUMA node 0
 1 <-> 2  :  44 ns
 1 <-> 8  : 197 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 202 ns
 2 <-> 17 :  44 ns
 8 <-> 17 : 211 ns
Allocate from NUMA node 1
 1 <-> 2  :  45 ns
 1 <-> 8  : 196 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 199 ns
 2 <-> 17 :  47 ns
 8 <-> 17 : 201 ns

Latensen är ju inte minneslatens, 60-80 ns är normal minneslatens för Zen. 20-30 ns är fullt rimlig latens mellan kärnor i samma CCX. Lite förvånad att det inte är lägre latens mellan trådar i samma CPU, fast å andra sidan är latensen mellan kärnor i samma CCX väldigt låg.

Som synes ovan är den 40-50 ns för Xeon Sandy Bridge (något lägre för konsument men stämmer bra med PC-pers siffror). Här är det 10 ns mellan trådar i samma fysiska kärna.

Så frågan är varför programmet, eller mer specifikt libnuma, bara tycker det är en NUMA-zon på din TR...

$ ./thr_ping 1 2 8 17
This system got 32 CPU-threads and 2 NUMA nodes.
Allocate from NUMA node 0
 1 <-> 2  :  44 ns
 1 <-> 8  : 197 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 202 ns
 2 <-> 17 :  44 ns
 8 <-> 17 : 211 ns
Allocate from NUMA node 1
 1 <-> 2  :  45 ns
 1 <-> 8  : 196 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 199 ns
 2 <-> 17 :  47 ns
 8 <-> 17 : 201 ns

Kan det bero på att NUMA för Threadripper fixas först med nästa kärna, Linux 4.15?

$ ./thr_ping 1 2 8 17
This system got 32 CPU-threads and 2 NUMA nodes.
Allocate from NUMA node 0
 1 <-> 2  :  44 ns
 1 <-> 8  : 197 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 202 ns
 2 <-> 17 :  44 ns
 8 <-> 17 : 211 ns
Allocate from NUMA node 1
 1 <-> 2  :  45 ns
 1 <-> 8  : 196 ns
 1 <-> 17 :  10 ns
 2 <-> 8  : 199 ns
 2 <-> 17 :  47 ns
 8 <-> 17 : 201 ns

Ett nytt test, nu med SMT = OFF (4.1 GHz [1.40000 V] + 3200 MHz). Det är alltså 16 kärnor och 16 trådar mot tidigare 16 kärnor och 32 trådar.

Latenserna hamnar åter i fyra grupper, vilket syns tydligt i diagrammet:

Visa innehåll

Dold text

Medelvärdena för varje grupp av latenser är.
18.96
175.63
234.55
266.44

Percentilerna för samtliga värden är:
P01 18
P50 234
P99 269

Det verkar inte vara någon större skillnad.

EDIT: Här är reultaten från Geekbench 4.2

https://browser.geekbench.com/v4/cpu/compare/5968445?baseline...

Single core är i princip oförändrat, förutom latensen. Men den verkar vara lite slumpartad.

Multi core sjunker som förväntat på de flesta, men ökar på HTML5 DOM.

EDIT 2: Klockade ned lite, till 3,9 GHz och körde thr_ping, med SMT påslagen igen; 3.9 GHz [1.40000 V] + 3200 MHz. Stapeldiagrammet liknar tidigare, även om jag ökat upplösningen på staplarna.

De sammanfattande statistiken är nästan oförändrad:

20.03
176.88
235.50
268.81

P01:  18
P50: 236
P99: 269

Jo, det verkar som om att snabbare minnen är viktigare här än överklockning av cpun. Det bekräftas även av Geekbench, https://browser.geekbench.com/v4/cpu/5971583 där singlecore ger 4767 och multicore ger 52192. Skall se om man kan ge sig på minnena igen framöver. Men, det kanske blir först nästa år.

EDIT 3: Yes! Blender är stabil vid 3.9 GHz. Orsaken att jag sänkt klockan lite till vara att jag läste "AMD Threadripper Water Block Cooler Roundup for 2017", https://www.hardocp.com/article/2017/12/29/amd_threadripper_w... I den artikeln nämner de också en tidigare test av min kylning, Enermax Liqtech 360 och att de inte kom över 3.9 GHz. Ja, det är väl bekräftat för mig härmed också, då jag testat 4,00 och 4,05 och 4,10 GHz utan längre stabilitet. Bäst i test för hardocp blev XSPC RayStorm som kostar närmare fem tusen kronor, jämfört med min som kostade nittonhundra.

Det här motsvarar 638 sekunder och är runt en minut långsammare [beroende på distro] än Intel Core i9 7980XE som kostar ca 20 000 Kr; se detaljer i länken https://www.phoronix.com/scan.php?page=article&item=windows10...

Blender-filen, "barbershop", finns här https://svn.blender.org/svnroot/bf-blender/trunk/lib/benchmar... om man vill testa själv.

Sakta men säkert.

Kanske. Tror dock mer på att det är någon bug i libnuma som drabbar AMD.

Oavsett vilket lär det lösa sig med tiden.

Inte för att regna på din parad, men grejen är att Blender verkar uppvisa rätt mycket "dimishing returns" efter 10 kärnor, så även i9-7900X är snabbare än i9-7980XE enligt Phoronix tester...

Visa innehåll

blender

Gäller rätt många tester av "verkliga" program som databaser, webbservers och liknande. Upp till 8-10 kärnor går i någon mån att utnyttja med ett enda program om det skalar riktigt bra. Med fler kärnor är det mest några benchmarks samt typiska serverlaster (virtualsering eller att man på andra sätt kör flera program samtidigt) som ser någon relevant boost.

Rena gissningar här. Troligen handlar det mest om att man inte ville sätta för lågt pris initialt när tillgången var låg och förhoppningsvis hypen var hög. Det handlar i så fall om en fullt normal prisjustering nu när produkterna finns i lager.

En annan potentiell och för AMD i så fall långt värre förklaring är konkurrens från Qualcomm och Cavium. En stor orsak till att det fanns en tilltro till att Epyc skulle lyckas är att väldigt många desperat söker efter vettiga alternativ till Intel på serversidan. Finns något som går under benämningen "all but Intel" (bl.a. Google har uttryck sig så).

I serverrummet är x86 inte alls lika självklart som det är på skrivbordet med Windows. Framförallt inte när saker som "live-migration" och liknande inte är kompatibelt mellan AMD och Intel, medan det är kompatibelt över ARMv8 då virtualisering är del av den specifikationen.

Bygger man en serverhall är därför AMD en lock-in precis som Intel är lock-in, d.v.s. det är en migreringskostnad trots att båda är x86. Väljer man i stället ARM är det med stor sannolikhet en större migreringskostnad, men fördelen är att man sedan enkelt kan hoppa mellan alla som implementerar ARMv8 (vilket på serversidan är två just nu, fler lär följa om det går bra här).

Toppmodellen av Qualcomm Centriq 2400 är full jämförbar med de absolut snabbaste Epyc modellerna, skillnaden är att den plattformen kostar $2000 per CPU och den drar ungefär hälften av Intel/AMDs toppmodeller.

Till skillnad från tidigare ARM-försök som inte alls presterade i nivå med x86 ligger Qualcomm/Caviums på väldigt snarlik nivå sett till SPECint och SPECfp prestanda per CPU-tråd! Båda dessa ARM kretsar har upp till 48 kärnor i en monolitisk design med ~250 GB/s s.k. bisect bandwidth (Intel har 768 GB/s på de största kretsarna, AMD har endast ~40 GB/s p.g.a. MCM).

I klartext: MCM gör Epyc billigare att tillverka men en sådan design diskvalificerar kretsen från vissa typer av laster. Även om Qualcomm inte når Intels toppmodeller här har man samma låga latens tack vare en monolitisk design + man har ändå väsentligt lägre pris än till och med AMD!

Microsoft och Qualcomm verkar just nu vara väldigt bra kompisar (ARM på Windows). Microsoft håller redan på att lägga in stöd för Qualcomms serverplattform i Azure.

Väldigt hög perf/W och väldigt bra pris för "scale-out" är en perfekt match för t.ex. Googles och Facebooks datacenter. Även dessa tittar därför väldigt mycket på utveckling kring 64-bitars ARM på server.

Kort och gott, kanske är så att AMD borde skrotat Epyc och gått all-in på K12. Ett rykte säger att Jim Keller sa upp sig p.g.a. att trodde stenhårt på K12 så när AMDs ledning drog ur pluggen på det projektet fick han nog. Oavsett om det är sant eller ej så tror jag också att med facit i hand hade K12 varit en bättre produkt just nu än Epyc.

Tack för svar, men nu riskerar jag att regna tillbaks på din parad. "Meltdown and Spectre", från https://www.phoronix.com/scan.php?page=news_item&px=Google-CP... är två djupa hårdvarubuggar, designmissar där Meltdown enbart drabbar Intel och Spectre drabbar alla tre, Intel/AMD/ARM.

Meltdown, https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-E.... Phoronoix har redan testat patchar,

• https://www.phoronix.com/scan.php?page=article&item=linux-415...

• https://www.phoronix.com/scan.php?page=article&item=linux-mor...

Visst blir den en liten performance hit men det drabbar väl bara de som säljer stora mängder serverprocessor, dvs inte AMD, ännu.

Det var ju en ganska duktig skillnad. Det kan förklara min temp som jag inte varit helt nöjd med, även om den är ganska bra. Du har inte sett fler jämförelser? Hade varit intressant att se om fler fått samma resultat.