Rykte: AMD kan ta 12 kärnor till sockel AM4 med arkitekturen Zen 2

Eller fler kärnor och intelligens att gå upp i höga klockfrekvenser när få kärnor pressas hårt.

Inte heller TSMC's 7nm lär antagligen ge utrymme till några stora frekvenshöjningar, men är bara processen så bra som den redan verkar så kan det helt klart finnas möjlighet till fler kärnor. Sedan kanske det likväl dröjer till Zen 2+ beroende på kanske redan spikade lanseringsscheman.

Skickades från m.sweclockers.com

Med den lilla kylare man får med och hur bra den klarar kyla skulle jag säga att 2700X klarar sig väldogt bra fär att ha 8 kärnor. Intel som redan gått rätt varma med 6 kärnor får det nog svettigt med 8 kärnor om de inte börjar löda IHS'en nu. Sedan slipper de undan lite genom att inte skicka med en kylare (som hade visat hur varm den går) utan kräver av kunden att köpa en "tillräckligt bra" kylare själv.

Ja, att helt sonika stänga av de som inte används (behövs) och så trycka upp de som används. Det är ett bra alternativ

.

Nu har jag 32 GB med fyra stickor. Men har aldrig upplevt några issues. Jag förväntade mig faktislt mer "småstrul" än vad jag upplevt. Tänkte man skulle behöva mellan deras olika minnesmodeller, avaktivera kärnor oxh annat hela tiden men förutom just FarCry 3 och 4 så har all spel fungerat utan issues.

Arkitekturen som sådan får inte lägre IPC eller lägre praktiska frekvenser för att du väljer att använda den till att designa en modell med många kärnor. Du klockar inte en 4-kärnig Ryzen högre än en 8-kärnig. Även vid 8 kärnor så är det själva arkitekturen och tillverkningsprocessen som sätter stopp.

Fler kärnor ger utvecklare större möjligheter så även om idag inte tar nytta av mer än 4-8~ så när det släpps en 12 kärning mainstream cpu så kommer utvecklare ha program/spel ute ca 2 år efter o det kommer bli fler. Någon måste ta första klivet och självklart är det hårdvaran som skall ta klivet först och så är ofta fallet?

Dom som tycker det är fel med fler kärnor borde tänka på att nya produkter kommer för att någon ska utveckla program och spel för dom också, hade alla suttit med enbart 1 kärna i cpun hade ingen heller brytt sig om att programmera för fler och då hade en dual core idag varit helt värdelös. Om en utvecklare gör en sak så hakar kanske fler på också.

Inte AMD kanske. Jag inbillar mig att Intel hade klarat högre frekvenser om de stannat på fyra kärnor och arbetat på högre frekvenser på dem, istället för att lockas tillverka fler kärnor (vilket många av oss inte behöver ändå)

.

Ja intels processorer klarar ju högre frekvens i grund, så där kan de ju inte få samma antal kärnor i maxfrekvens utan att överskrida TDP. Men eftersom AMDs kärnor ändå inte klarar de ~5GHz som Intels klarar så finns det inte samma trade off med att gå upp till 8 kärnor eller mer.

Vi lär få se hur fundamentalt dagens fyra kärnors CCX är i Zen. Är tekniskt relativt enkelt och därför hyfsat sannolikt att man utnyttjar möjligheten till en högre transistorbudget till ett tredje CCX.

Fördelar med ett tredje CCX

• tekniskt enkelt, ett till CCX blir bara en till nod på den interna bussen (som kör protokollet "Infinity fabric")

• egentligen ingen annan transistorkostnad utöver den för CCX

• varje CCX, vilket inkluderar L3$, är en funktionell enhet som kan "power-gate:as" i lägen där man vill få ner effekt

Nackdelar

• asymmetri, flera körningar av samma multitrådade program kommer leda till olika prestanda beroende på hur trådarna fördelar sig över CCX. I praktiken ett långt mindre problem mellan CCX jämfört med hur det uppför sig på ThreadRipper och Epyc när det även kan sprida sig mellan CPU-kretsar (där blir även I/O-kapacitet och latens mot RAM asymmetriskt vilket inte alls är fallet för Ryzen med en CPU-krets)

• effektiva storleken på L3$ ökar egentligen inte, varje CCX kan bara använda de 8 MB som är "lokalt"

Fördelar med att öka antalet kärnor i varje CCX

• ger bäst prestandautdelning

• om L3$ ökas proportionellt drar även program som använder en delmängd av kärnorna nytt av detta, Zen har visat sig vara mer beroende av sin cache jämfört med Core. D.v.s. har man ett "working-set" som inte får plats i cache tappar Zen mer prestanda jämfört med Core i de flesta fall, så en större L3$ är positivt för Zen

Nackdelar

• den gigantiska nackdelen är att CPU-kärnorna och L3$ inom ett CCX är ihopkopplade med en cross-bar switch, komplexiteten sett till antal transistorer hos en sådan ökar exponentiellt med antalet noder. Så en ökning från fyra till sex kärnor ökar komplexiteten med en faktor fyra!

i7-8700K har ju högre maxfrekvens jämfört med i7-7700K. i9-7940X (14 kärnor) har samma maxfrekvens som i7-7820X (8 kärnor). En specifik kärna kan nå 4,5 GHz (Turbo boost 3) och "normala" TB2 frekvekvensen är 4,3 för båda.

De har även samma frekvens när 8 kärnor jobbar på 4,0 GHz. (i9-7940X klarar 4,0 GHz till 12 kärnor).

Lite detta är dock poängen idag. Ta en titt i ditt aktivitetsfält, eller i resurshanteraren och räkna de 100+ saker som på ett eller annat sätt körs idag. Om något är våra datorer fullsmockade med program och saker som körs samtidigt idag vs bara 5-10 år sedan. Tror du måste gå till Windows 2000 bara för att ens komma under 50 processer idag.

Lägg till mängden bakgrundsjobb som görs både i Windows och andra saker. Webbläsare som öppnar 4+ core hantering med nästan varje flik fördelar på CPUerna. Det är inte så svårt att använda många trådar som folk verkar tro.

Svåra är så klart att använda dem 100%, men... måste du?
Jag ser det som om du envisas med att maxa din CPU hela tiden, är det lite dumt. Det är säkert kanon i beräkningssituationer, men titta på tex GPUer. Deras turbo och kylning idag beror enormt på att du spelar och har lite "marginal" för att undvika FPS dipps. Och om du kör benchmark kommer kortet bli varmt och klocka ner.

Detta kan man ironiskt också se på tex 2 st 1060 GPUer. MSI vs ASUS vem är snabbast?
På pappret, ASUS, för den har högre klock.... i verkligheten MSI kortet då dens kylning är bra nog att kunna låta den nå sin turbo, utan så hög spänning mycket mer ofta. Så ASUS kortet spenderar sin tid varmare och långsammare pga de satt högre spänning, för att klara den nivån.

Samma är det ju med dagens CPUer. Ta AMDs 2000 serie och AFR. Där har du en dynamisk anpassning efter behov. Så om du har 12 kärnor, men bara behöver 4, får du en boostad frekvens. Om du kör 8 får du en annan nivå, och kör du alla 12 får du den nivån. Mao... de anpassar sig efter dina behov, precis som en GPU gör.

Så snälla sluta titta på CPUer och GPUer som något stelt från 1990 talet nu, och titta på hur de fungerar idag. Om detta innebär att vi kan köpa 8c16t billigare, är det en Win för oss, även om det är "trasiga" CCX kluster. Trasig innebär nämligen inte nödvändigtvis sämre frekvens.

Fysikens lagar har träffat Intel som en tegelvägg också... det kan du se i deras 10nm nod som skulle komma 2017... och nu kanske kommer 2019. Problemet är... Intel har förfinat 14nm med 14nm++ så mycket, att ingen 10nm gen 1 har en chans i helvete att nå de nivåerna.

Låt oss påminna er om vad 14nm 1 gen gör...
Broadwell.
Yep... de där 65W, 3.1-3.7Ghz CPUerna, som många inte ens når frekvenserna AMDs nya 2600X når stock. Och AMD har trots allt hoppat till 12nm på denna, med bara ny nod som tanke.

Skylake var lite hitNmiss, där du kunde få upp många av dem till ca 4,5Ghz (sweclockers fick sina i 4,4 och 4,6). Detta är efter Intel hade pillat med nod och så. Skulle därför säga att AMD är inte så långt efter som alla tror.

Och 10nm har de endast lyckats släppa någon 2-2,5Ghz laptop CPU sak... mao, de kan inte ens tillverka 3-4Ghz CPUer på denna nod än. Mao... Intel kommer vara fast på 14nm ett tag nu skulle jag tro, för även om de får liv i 10nm, lär det inte vara något som ens kan matcha 8700k, utan vi pratar en försämring... troligen tom en enorm sådan.

Enda gången Intel vinner är om du:
1. Vill delidda din CPU och klocka 5Ghz+
2. Vill betala premium pris för något du troligen inte har nytta av (då folk tror 1060 får samma boost som 1080Ti)
3. Spelar något udda spel som än kör 1-2 kärnor där intels turbo kan pressa upp.

Säger inte att AMD är bästa CPUn... det ä den inte. Men det är utan tvekan en satans prisvärd sådan, och den har en design som möjliggör enorma förbättringar på sikt, där Intels redan är slipad... och inte längre kan slipas mycket mer.

Inget snack om att Ryzen är riktigt bra, framförallt för oss som kör Linux! Dels har Linux lägret alltid gillat AMD, men framförallt är UNIX-filosofin än mycket bättre match för Zen (och även SKL-X) jämfört med Windows-filosofin (där passar S-serien bättre). Går bl.a. att studera i Windows vs Linux resultaten i Geekbench 4, upp till 4C/8T får man i princip samma resultat oavsett OS men vid fler kärnor börjar framförallt Zen och SKL-X resultaten rejält tilta i favör för Linux!

Men finns några fall som kanske är lite bredare än de du listar där Intel utan tvekan har ledartröjan

• alla former av I/O-begränsade laster, detta med väldigt stor sannolikhet orsaken till varför det går så extremt trögt för Epyc, servers tenderar göra en hel del I/O... Ingen skillnad vid bulköverföring, men är en klar skillnad när IOPS drar iväg

• de som jobbar med problem i Matlab, Matematica, R och liknande program, här har man sedan lång tid tillbaka varit extremt duktigt på att utnyttja SSE/AVX/AVX512 (är upp till 3x bättre prestanda för Intel per kärna och MHz i SIMD)

• CPUer för mobila enheter, här måste AMD lyfta sig rejält då första generationens Ryzen bara är någorlunda prestandamässigt konkurrenskraftigt mot Intels 15 W TDP modeller när Ryzen har sin cTDP satt till 25 W (CPU-mässigt, de flesta kontorsråttor klarar sig mer än väl med Intel iGPU). De Ryzen-modeller som är lanserade kör alla 25 W cTDP, t.ex. HP Envy x360 (något som man inte varit speciellt transparenta med, det antogs att de körde 15 W TDP men det är 25 W, vilket bl.a. TechReport fått ur HP och man nämner 1h31m in i denna podcast)

Och angående SIMD händer det rätt mycket intressant inom C++ världen kring detta. Tekniken har egentligen funnits sedan första Pentium MMX, men har fram till 2017 års C++ standard egentligen inte funnits något standardiserat och portabelt sätt för oss programmerare att dra nytta av detta. Sett till rå beräkningskraft används ju faktiskt bara 20-30 % av en modern x86 CPU om man inte alls nyttjar SIMD, så finns rejält med potential här.

Portabelt = jag ska inte behöva ändra min kod för att köra den på en CPU utan säg AVX512 och inte ändra den bara för att CPUn är en ARM med NEON. Och ska finnas stöd på ett sätt som man kan förvänta sig finns på alla relevanta system programmet kan tänkas köra på.

Sedan C++17 kan i nästan alla standardalgoritmer (d.v.s. de i <algorithms>, <functional> samt <numeric>) dra nytta av SIMD om funktionen man ger till algoritmen är "SIMD-säker". Enda man som programmerare behöver göra i det läget är att "tagga" koden med std::execution::par_unseq (om det är något som bättre skalas över CPU-kärnor väljer man i stället std::execution::par).

Inget som magiskt kommer ge heltalsfaktorer i prestanda, men är fullt realistiskt att inom ~5 år förvänta sig en generell prestandaboost på dagens CPU-modeller på kanske 30 % enbart från detta (förutsätter naturligtvis att CPU är flaskhals i applikationen).

SIMD är mer restriktivt jämfört med uppgiftsparallellism (som bäst hanteras med flera kärnor). Dock har SIMD långt bättre energieffektivitet jämfört med flera kärnor samt runt tre tiopotenser lägre synkroniseringskostnad (~10 ns i stället för ~10 µs som är fallet för att sprida ut något över kärnor). D.v.s man man komma åt rätt många fall där det finns potentiell parallellism som idag inte kan utnyttjas med flera kärnor då vinsten äts upp av synkroniseringskostnaden.

Tror du missförstår vad vi pratar om. Jag menar bara på att AMD inte hade kunnat nå högre frekvenser än de redan har om de satsade på färre kärnor. Intel däremot når högre frekvenser och har större trade off på att öka antalet kärnor då det sänker deras frekvenser. Ditt svar är lite orelaterat.

Sitter just nu av en händelse och spelar World of tanks. Ett litet udda spel som inte spelas av så många 100 000 spelare simultant världen över just nu. Tragiskt men med 1440p inställningar och allt på max får jag GPU usage på ca 35-50% i Frontline läget med extremt låg fps stundtals. Resurshanteraren säger att en tråd ligger på nästan 100% medans resterande ligger på en 25% vilket totalt landar på långt under 50% cpu-load.
Detta spelet är LÅNGT ifrån ensamt..

Yep. Det är för de görs av lata programmerare som inte orkar ta lite modernare motor.

Tittar du på de som gör det, ser du att 6+ kärnor är inga problem att använda. Och om AMD nästa i konsolerna blir 6c12, vad tror du kommer ske med spelens grund? Jo de kommer optimera det för just fler trådar redan när det utvecklas på konsol.

Folk är så satans stela och sura när de tror att gammalt Windows håller tillbaka utvecklingen, men sen tittar personer och stirrar sig blinda på dåligt kodad DX11 spel också, som verkligen är hämmande för utvecklingen.

Som sagt, Intel nådde 5GHz med en 3 stegs optimerad nod på en 3 år gammal Nod. Vill du vänta till 2021-2022 när Intel nått samma med 10nm? För de kan inte ens nå 4Ghz med den idag...

Alltså vad vill du mig?
Vad tror du det är jag säger som du tror att du säger emot? Känns som att du har en helt annan diskussion än jag bara att du citerar fel.

Problemet är, även i de fallen då folk köper HEDT system här, är det extremt sällan det tittas på mest effektivaste lösningen. Utan man tittar på den som ser snyggast ut i en benchmark, eller överklock... det är ju lite så på en sida vars namn har överklockning i sig.

Tycker bara det väldigt dumt att gång på gång ta mer fördelar en 150kkrs server har... som en naturlig sak vi alla "gynnas av". För det gör vi inte...

Sen har jag inga tvivel på att det finns fall vi ha nytt av dessa instruktion-set, men normalt sett är det extremfall, iaf första 4-5 åren de inte implementeras. Och som det är nu, är nog alla CPU buggar en större faktor problem för allt seriöst HEDT jobb vs mycket annat.

Intel har en enormt bra minneslatens hantering också, förnekar inte detta ett dugg. Eller att alla våra Optane diskar når mycket bättre prestanda på din Intel maskin... men det jag dock fortfarande poängterar är, där är fler i detta forum som träffats av blixten i verkliga livet, än som troligen sitter på en Optane.

Och förlusten en NVMe disk gör, är... försumbar för klient bruk. Lägg till att Spectre 2 dödade all fördel Intel hade på många nivåer där. Du återkom aldrig när du hade "tittat runt på detta"... konstigt nog. Intel CPUn idag, med spectre 2 patch, har totalt usel latens mot NVMe SSDer. Så... idag är Intel inte något att titta på för detta, då får du vänta till tidigast hösten om nu inte de flertalet nya buggarna som också hittas påverkar dem också (då de troligen inte hunnit fixa dem också).

Och vi andra vill kanske ha lite mer än adobes
Som sagt, GPU acc är ju hela poängen för AMDs framtida APU-lösning, som dessa på något sätt måste klassas för, då 2600X inte normalt har GPU.

Min poäng var, vi alla letar inte efter exakt samma "problem"... och det finns nytta även med 25W 4c8t och även 15W 4c8t. Och i samtliga fall... syftat på att om du just har GPGPU... vill du gärna ha lite mer prestanda i GPUn också

Det krävs ju en utveckling av frekvenshanteringen helt klart, men detta är också en naturlig del av få-trådig till mång-trådig CPUs "fördel" över båda alternativen. Att kunna anpassa sig efter behovet, inom så bra ram du kan, och istället för att du måste ha en 2500k för en sak, och en 3960X för en annan, alt mer moderna 7600k för en 7820X för två olika maskiner, bör kunna med 8700k Turbo eller en XFR2 2700X kunna anpassa dig mellan det bästa från båda.

Så ja, det behövdes denna teknik för att kunna få 15W optimalt, men tekniken kom med kaby lake... och lanserades ändå först med coffee lake. Men att medvetet låsa sig till få kärnor i framtida CPUer är en dum lösning, om du kan styra dem så pass att du får bästa ur båda. Sen självklart kommer ju TDPn alltid vara begränsande faktor.

Och här har OS tillverkare och programmerare en ypperlig chans att optimera mycket. Att kanske tänka på mer effektiva och bättre sätt att sprida lasten, beroende på om du vill ha max batteritid, eller max prestanda. Behöver ju inte ens ta mycket mer än några bråkdelar av en sekund för hela OSet att ställa om sig heller.

Om du nu ska köra GPGPU lösningar och faktiskt använda GPUn till framtida hjälp, vilket är något fler och fler saker kan göra. Och H/W kodare i GPUerna gör ju typ all avkodning/kodning av media idag också, men då måste också GPUn vara igång.

Nu tycker jag det är fel att bara sikta på att gynna en, men om du vill dra det tråget... sikta på att dela in CPUns hantering i OSet i CCX kluster. Behandla dem mer separat, precis som man tvingades göra med HT/SMT när OS först trodde de var riktiga kärnor.

Win 2000 trodde en P4 var 2 riktiga kärnor, XP visste att den var 1 kärna, med SMT. På samma sätt behöver en Ryzen delas med CCX klusterna, så man undviker högre latensen att hoppa mellan infinitybryggan.

Intressant läsning, men problemet är fortfarande... du kommer inte få 6Ghz+ CPUn. Så... ska vi bara lägga ner?
Jag förstår att lösningen inte direkt är enkel, och att "effektivt" är det inte. Men om vi frågar dig, hur i H ska vi få 100% mer prestanda ur dagens CPU om vi inte kan öka IPC, vi inte kan göra allt i H/W acc delar, vi fortfarande kör samma frekvens mer eller mindre i 5 år nu och enda vi kan göra är fler kärnor och låta CPUn pressa sig upp så den ger maximal frekvens, med maximalt antal kärnor?

Finns liksom inget kvar mer att göra än att effektivisera koden, eller byta hela CPU grunden.

Vi har faktiskt kommit rätt långt med div H/W funktioner, instruktioner och GPU acc, men vi kan bara inte sluta.
Förstår att bygga något i assembler kostar... men jag säger åter, vad gör du när du inte kan göra något annat? Titta på priset på utvecklingen av 5/7nm noder, eller bara hur mycket Intel lagt på 10nm, och återkom med kostnad klagomål.

Jag förstår att för varje kärna man lägger till, blir det exponentiellt mer komplext och exponentiellt sämre "effektivitet". Men jag är fortfarande också medveten att kisel CPUn med X86, troligen bara har 10 år eller så till. Så... fix it or get a new job.

Min poäng är... lös det du kan, och när du träffar på olösliga fel, kvantmekanik och sporadiska energi-fluktrationer i din kod... så okej. Tills dess... är det lättare och mer troligt att lösa matematiska problem, än att lösa ekvationer med bruteforce. Säger inte att Intel/AMD kommer ge upp heller... men AMD tex har ju redan insett att om de ska kunna skala vidare, måste de också skala i antal "bitar" och just CCX klusterna och även pratet om att ta ut bryggorna mm till I/O är en del av detta. Mao... du konstant gnäller på att Intels lösning är mer effektiv I/O än AMDs... och jag håller med. Men snart är det den enda lösningen du har...

Och precis här slår du huvudet på spiket. Priset.
Men när CPU kiselpriset går upp till nya rekordnivåer, och prisvärd multi-core CPUer får en hel ny prisnivå om de är byggda i "blocks", så kommer det en dag där du måste sluta stirra på priset. Du har då två val... betala, eller stanna kvar på exakt den prestanda du har, för resten av tiden (eller tills någon hunnit mogna en ny teknik på något annat än kisel).

Du pratar om 15 år diskussioner... du vet att första transistorn 50+ år var inte på kisel, och man gick över till det pga lägre priset... ironiskt eller hur?

Jo.. här håller jag med.
Jag förstår att ni alla kan inte kunna assembler kod, rinnande i vatten i skallen. Men du måste också inse att... C++ eller vad du än väljer att koda med, är extremt begränsad i vad dessa utvecklare av kompilatorn valt att göra med den. Mao... du kanske löser ett problem på "hög nivå" på ett för dig logiskt sätt, men som kanske kan lösas mycket mer effektivt med helt annat sätt på låg-nivå. Och svåra här är inte att kompilatorn ska kunna hantera det... utan att den ska kunna förstå vad i helvete du vill att den ska göra. Så den kan "lösa det åt dig".

Faran med detta är ju att du faller i en... äh.. det får kompilatorn lösa.
Eller... det går inte bättre än med detta sätt, för det är just den värld av begränsning du är fast på.

Jo jag har läst och förstår att det är satans komplext idag. Utvecklingen går nästan bakåt för er när det gäller verktygen. Men det är åter igen... är det för man är lat/snål och inte vill lösa det, eller för det är ett så nytt problem, att man inte hittat bästa sättet än?

Med Ryzen tror jag mycket är att det är nytt och man har inte hittat bästa sättet att lösa det än. Intels iCore har trots allt funnits i nära 10 år nu, och det tog ändå så pass lång tid att hitta massor med farliga säkerhetshål i dem. Så trots så lång tid... verkar ingen ha "grävt i koden" tillräckligt. Först nu när man börjat göra detta, hittar man mycket som alla "antog".

Som OS-utvecklare måste jag det bestämdaste påpeka att det faktiskt är omöjligt för OS-kärnan att veta vad som är "rätt" optimering i varje enskilt fall. Här ser man också att olika OS gjort olika val, tänker man lite inser man att valet inte alls är slumpmässiga.

Ta t.ex. hur man lägger ut två trådar på en AMD CPU med sina två CCX.
Vad är optimalt? Tja, det beror på! Om dina trådar kommer dela data är det optimala att lägga båda trådarna på samma CCX, delar de väldigt mycket data vore det optimala faktiskt att lägga dem på olika CPU-trådar i samma fysiska kärna. Om de inte kommer dela data är det optimala att lägga dem på olika CCX, det ger bäst utnyttjandegrad av L3$!

Är helt omöjligt för OS-kärnan att veta vad som kommer hända i framtiden. Den enda som möjligen kan veta detta är applikationsutvecklaren, alla moderna "större" OS har funktioner som låter applikationer göra just detta (väldigt nära 0 % av applikationer gör dock detta, är väldigt lätt att ställa till det så prestanda på det stora hela blir sämre).

Linux standardval är att sprida trådar jämnt över CCX samt använda en tråd per CPU-kärna. Först när alla kärnor har en CPU-tråd aktiv börjar man lägga ut jobb på "andra" tråden. Att sprida mellan CCX är ett vettig standardval i UNIX då grundtanken är att skapa små enkeltrådade program som kan kombineras för att lösa större problem, ett större problem består då av separata enkeltrådade processer -> noll nytta av att dela CCX då de inte kommer dela speciellt mycket data.

Windows bryr sig inte om att skilja mellan CCX:er, men även där fyller man först på alla kärnor innan "den andra" tråden i varje kärna börja användas. Också vettigt då Windows mycket mer pushar för större multitrådade program som utför hela jobbet själv, ett multitrådat program är relativt sannolikt att dela data mellan trådar (i kontrast mot processer där adressrymden är privat).

Vilket OS har någonsin behandlat SMT som något annat än just SMT? Se hur schemaläggningen fungerar ovan. Möjligen gjorde inte Win2k detta när P4 med HT var aktuell, men det spelade heller ingen roll då det var en kärna med HT så fanns inget extra val att göra. Alla OS som var aktuella när Nehalem släpptes, där man hade både flera kärnor och HT, hanterade SMT som ovan.

Se ovan, finns överhuvudtaget inget "alltid bäst sätt" för OS att hantera CCX. Det är helt beroende på vad applikationer kommer göra, så den enda som kan göra någon optimering är applikationsutvecklaren. Men har man inte visat rätt många gånger nu att CCX problematiken är inte så stor? Man kan vinna kanske upp till ~5 % på att få det hel "rätt", finns mycket bättre saker att lägga tiden på som ger minst 5 %.

En helt annan sak på ThreadRipper, Epyc och Intel multisocket system. DÄR måste man verkligen se till att saker kör på "rätt" CPU-krets. Men även i det fallet kan OSet mest bara bistå med verktyg och ett vettig förval (vettig förval i alla OS som känner till NUMA är typ att hålla varje enskild process på en och samma CPU-krets / NUMA-zon), är bara applikationsutvecklaren som kan göra något bättre än så (och få till detta bra är skitsvårt!).

Tror du då åter igen missade poängen. Att utnyttja fler kärnor är bara ett sätt att få mer prestanda, denna metod fungerar bara på en delmängd av problemet.

SIMD är ett annat sätt, av en lång rad olika metoder, att få upp prestanda. Det som gör SIMD intressant är

• det har redan lagts rätt mycket resurser på att utnyttja fler CPU-kärnor, det är väldigt mycket dimishing returns på det utanför de triviala områdena (typ server där man naturlig har väldigt många oberoende sessioner), p.g.a. av svårigheten att använda SIMD på något enkelt sätt finns här extremt mycket outnyttjad potential

• flera kärnor är bäst när man har många oberoende uppgifter, klientapplikationer tenderar vilja lösa ett specifikt problem snabbare och fysikens lagar sätter gränser i hur lång kostnaden för synkronisering kan bli. SIMD har egentligen ingen synkronisering på det sättet, så bara man kan använda det på något sätt kan den delen av koden redan idag bli 2-~20 gånger snabbare (lite beroende på CPU-modell och vad man gör) på existerande CPU-modeller! D.v.s. det är möjligt att öka prestanda i en specifik applikation, inte bara öka prestanda om man kör samma applikation X gånger parallellt.

• energieffektivitet, effekten skalar rätt linjärt med antalet kärnor, det är orsaken till att man kör lägre frekvens när fler kärnor är aktiva. SIMD ger typiskt 20-30 % högre effekt fast flera gånger högre prestanda

Uppenbara nackdelen med SIMD är att långt ifrån alla problem kan utnyttja detta, totalt sett är det färre än antal fall som kan använda flera CPU-trådar. Sedan finns även fall där man kan kombinera CPU-kärnor och SIMD, då får man maximal kick!

Exakt. Och man kan därför inte snöa in på en specifik metod, som att allt måste köras på flera CPU-kärnor.

Det är slut på de enkla lösningarna man hade när enkeltrådprestanda ökade stadig. Vilket medför att det blir mycket dyrare att förbättra prestanda då varje specifikt fall måste analyseras och olika fall kommer behöva olika behandling (och vissa går inte att fixa).

Genidraget i spelmotorer för att skala dem med CPU-kärnor var att ha flera scener "in-flight" samtidigt. Nackdelen är högre input-lag då det första som måste hända är fysiken och därför måste man läsa input från användaren först av allt.

Så förut renderade man från start till slut, sedan tog man nästa scen. Vid 60 FPS gav det ~16 ms inputlag + tiden att få ut det på skärmen. Idag kör man fysiken/världen på några kärnor för scen N+2, preparerar grafiken för scen N+1 (detta är mer eller mindre enkeltrådat med DX11, är bara här DX12/Vulkan kan hjälpa så vinsten är mindre än många kanske tror) medan man renderar scen N.

Input-lag är nu 3*16 ms! Fast den stora fördelen är att det går mycket bättre att använda flera kärnor de varje scen kan hanteras väldigt oberoende av de andra då de befinner sig i olika delar av pipelinen. Vissa spel gör inte detta, t.ex. Doom/Wolfenstein just p.g.a. ökad input-lag. Men kolla hur dessa spel skalar med CPU-kärnor, eller kanske mer, kolla hur bra de presterar redan på 2C/4T CPUer!

Detta genidrag kom av att PS4/XBO är som de är, man var tvungen att komma på sätt att utnyttja de 6-7 svaga kärnorna som spelen kan använda (1-2 är reserverade). Fast finns också en gräns på hur många gånger detta kan appliceras. Efter det är man tillbaka till Gustavssons lag, större och mer komplexa världar ger lite bättre skalbarhet över kärnor.

Kompilator ska lösa det den idag är långt bättre än människor på att lösa: givet källkoden och dess hints som "detta är OK att farma ut på flera CPU-trådar alt. detta är OK att köra i SIMD-lanes" ska kompilatorn lura ut hur det ska översättas till aktuell CPU ISA.

Programmerare ska lura ut vad som överhuvudtaget behöver beräknas och i så fall vilken/vilka algoritmer är bäst givet vad jag vet om förväntad datamängd och datas befogenhet. Kompilatorn kan överhuvudtaget inte veta något om det, inte OSet heller.

DX12/Vulkan är nog ett rätt bra exempel på att spelprogrammerarna trodde sig veta mer om flaskhalsar än vad de egentligen gjorde. Överhuvudtaget är människor, även riktiga rävar, notoriskt usla på att ha en korrekt "känsla" för vad som kommer bli flaskhals. Bästa man kan göra är en bra grundläggande design och förlita sig på profilers om prestanda inte är vad den borde.

Kolla in denna video där en av Googles kompilatorexperter pratar om Epyc. Han nämner flera gånger att det finns egentligen inga relevanta skillnader för hur man optimerar för Zen jämfört med Core, likheterna mellan moderna out-of-order CPUer är långt större jämfört med skillnaden. Åter igen ett fall där folk haft totalt fel bild om hur mycket "optimeringar" som egentligen finns specifikt för Core.

Ta ett program och bygg det med GCC/Clang och växeln "-cpu=skylake -mtune=pentium3" (då optimerar kompilatorn för P3 fast den kan använda instruktioner från skylake). Bygg det sedan med "-cpu=skylake -mtune=skylake" beroende på om CPU du ska köra på är en Skylake (byt ut "skylake" mot "znver1" om det är en Zen).

Skillnaden i prestanda mellan det som är P3 optimerat och det som är Skylake/Zen optimerat kommer i majoriteten av fallen vara minimala.

Om du har kunskapen, kolla hur CPU-beskrivningen mellan znver1 (Zen1) skiljer sig mot Haswell/Broadwell (är den Core CPU som Zen är mest lik på denna nivå) i open-source kompilatorerna GCC och LLVM. Likheterna är långt större än skillnaderna.

När vi gick från "in-order" CPUer (Pentium för Intel och 486 för AMD) till "out-of-order" CPU blev i princip alla former av "handoptimeringar" för specifika CPU-modeller irrelevant. De enda optimeringar som är relevanta idag är de som är generellt bättre! Att strukturera koden så den kan utnyttja flera kärnor är en sådan, att strukturera koden så att den kan använda SIMD är annan och använda en bättre algoritm är en tredje (nog det man ska testa först av dessa!).