Gäller väl bara om applikations minnesarea understiger NUMA-zonens minneskapacitet? Men borde vara ovanligt med enkeltrådade applikationer som tar mer än hälften av systemets RAM så det är nog ett icke-problem i allafall.
Om det vore normalfallet vore kommande 32C Threadripper meningslös. Moderna "big-core" CPUer är väldigt duktiga på att "gömma" latens förutsatt att programkoden innehåller väldigt lite minnessynkroniserade instruktioner. Enkeltrådade program har ju ingen annan tråd de behöver synkronisera med => fungerar normalt sett väldigt bra att köra dessa även om de refererar RAM på "fel" NUMA-zon.
Det havererar när man har program där olika CPU-trådar behöver synkronisera access till gemensam data, i det läget är det i praktiken omöjligt för CPUn att spekulera => latens blir superkritiskt (är exakt så man "fixar" Spectre, stoppar in en synkroniserande x86 instruktion då den förbjuder CPUn att spekulera).
Överbeläggningen på 14nm produktionen är ju bra för de Intel-fabrikerna, de borde vara rätt lönsamma när de går konstant på 100%, men man undrar ju lite smått hur mycket kapacitet deras 22nm-frabriker går på, hade kanske varit bra idé att designa även z390 för den processnoden.
Med facit i hand är det absolut så. Rent generellt tror jag Intel insett att deras nuvarande strategi där man endast planerar en mikroarkitektur-uppdatering per nod håller inte, man har ingen plan B på vare CPU eller kringkrets-sidan som täcker fallet att 10 nm inte börjar rulla på inom en väldigt snar framtid.
Gissar att även en relativt enkel krets som Z390 skulle ta minst ett år att designa om till en annan process, d.v.s. inget man rimligen gör i detta läge.
Om vi antar att Ice Lake hittar ut Q3 2019 så har Intel inte haft några nyheter sett till mikroarkitektur under 4 års tid (i7-6700K lanserades Q3 2015) på konsumentsidan, det är något man måste ha en väsentligt bättre plan för framöver. (Jag förutsätter nästan att Cannon Lake kommer bli mer eller mindre skrotad, det verkar mest vara Skylake på 10 nm med uppdaterad iGPU).
Lite samma sak med ARM, prestandan förut har ju begränsat användning av ARM-baserade servrar till vissa nischer, är väl först nu med Cavium Thunder X2 som det börjar bli lite intressant, men det saknar rätt mycket mjukvaru-stöd i form av optimeringar för arkitekturen vilket får prestandan att ligga efter på vissa saker, misstänker att det fortfarande är 2-3 år bort innan mjukvaran börjar närma sig och givetvis så behöver de större tillverkarna leverera systemlösningar med ARM i vilket också känns som det är ett tag bort. Molnleverantörer är nog de som har bäst resurser idag att kunna basera system på det.
Saknas absolut optimering inom vissa nischer, 64-bitars ARM är inte ens 10 år gammalt än (lanserades 2010).
Dock saknas mindre än vad många kanske skulle gissa, säljs trots allt ungefär 5x så många 64-bitars ARM CPUer enbart till mobiler jämfört med totala mängden x86 CPUer. Totalt säljs det väl över 10x så mycket ARM som x86, en väldigt stor andel av dessa ARM-system kör Linux med ett stort överlapp av grundläggande programvara/bibliotek med vad en server använder.
Blivit rejält positivt överraskad över mognadsgraden under det år jag nu jobbat med 64-bitars ARM (i form av utveckling av C/C++ standardbibliotek ihop med LLVM/clang).
@Yoshman: Rätt hårdvara till rätt problem, jag hade inte tackat nej till nya TR med 32 cores för att baka ljus i Unity. Ska jag köra en databas, not so much
Exakt! Och har flera gånger understrukit att TR är absolut en vettig produkt. Men TR är bara bra till vissa nischer, så man måste vara väldigt medveten om hur de fall man själv är intresserade av är befattade för att kunna avgöra om TR är rätt produkt eller ej.
Att "baka" ljus är exempel på något som är "embarrassingly parallel" och det passar därför TR väldigt väl.
Många, dock långt ifrån alla, "embarrassingly parallel" problem fungerar lysande att accelerera med GPGPU. Att baka ljus är en sådan. Så för Unity är TR ett vettig val då det tyvärr saknas GPGPU stöd för detta, i t.ex. UE4 vore det helt meningslöst då en GPU krossar en CPU på denna uppgift (FP32 kapacitet i TR-1950X ligger i nivå med GPUer som Intel Iris Plus Graphics 650 och Nvidia GT 1030).
Men finns kanske hopp för Unity. Dels finns en del försökt med CUDA-backends för att baka ljus. AMD presterande också rätt nyligen "Radeon Rays" stöd i Unity, här är vad de bl.a. säger om prestanda
"10 – 20x performance improvement
Before 1 day baking => 1 hour with Radeon Rays"
Så rätt absolut viktigt att välja rätt maskinvara och än mer att välja rätt teknik för varje uppgift.
Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer