::: AMD Zen Samlingstråd :::

Vi har diskuterat detta under lång tid i tråden, kommunikation mellan CCX vare sig det är trådförflyttning pga schedulern eller cache begäran så har det effekten av dels adderad latens men också lägre bandbredd mot l3 på andra CCX klustret.
Tyvärr verkar inte ryzen ägare här på SweC särskilt intresserade av att undersöka vad man själv kan påverka/tweaka. Vi har redan nämnt schedulern och där har vi två saker man kan göra, det ena är att förhindra trådförflyttning genom att låsa affinity, inte alltid lösningen om man behöver säg 6 kärnor, då kommer det flyttas runt trådar inom dom sex ändå. En annan tweak är timern som schedulern jobbar efter, denna är i win10 dynamisk mellan 0,5 och 15,625ms. För spel hamnar den nästan alltid på 0,5ms,vid detta låga värde sker det flest trådförflyttningar per sekund som i sin tur drar ner prestanda i onödan i vissa situationer. Timern kan dock göras statisk och med ett justerbart värde, problemet med denna tweak är att timern är ett trubbigt instrument som vid pillande på drabbar långt mer saker än man vill. En annan timertweak som inte pillar på timern men ändå har inverkan på just trådförflyttningar är quantum/quanta värdet i Windows, detta kan justeras från sitt vanliga 6 till server värdet 12, detta är effektivt den multipel som schedulern applicerar på timern. Enda nackdelen att justera q värdet är att alla bakgrundsprocesser får samma q värde som förgrund vilket det normalt inte är, standar är 6 förgrund och 2 bakgrund, för att då undvika att det i bakgrunden stjäl CPU tid så måste man manuellt korrigera prioritet till högre eller hög på saker i förgrund. Denna tweak ger i slutändan ett dubbelt högt q värde som i sin tur endast bör halvera antalet trådförflyttningar per sekund. Man dubblerar den tid som en arbetstråd får innan den forceras vidare till annan kärna av schedulern.

Edit: Angående bandbredd över infinity fabric, den har angetts till 22GB/s per 32bit vid 1066MHz, vid full bredd skulle det vara 176GB/s (256bit). Detta kan faktiskt höjas genom högre internminneseklock vilket enligt utsago ska öka även fabric hastigheten, vid 3500Mt minnen borde då bandbredden pressas upp till ~289GB/s (halva minnseklock) Nu är dock frågan hur pass brett inter CCX kommunikation sker, om det är bara 32bit eller dynamiskt upp till 256bit?

Skickades från m.sweclockers.com

Med en divider på 3500 som AMD skall uppdatera till så blir denna flaskhals mer eller mindre borta nu när man ser hur mycket det ger med snabbare ram. Dessutom slipper man pilla med BLCK och med de bekymmer det kan ge. NvME diskar gillar nog visst inte högre bussklocka har jag läst. Ska man bencha och pilla med blck så bör man nog ha en god gammal sata ssd eller sata m.2

Dessutom tror jag vi får se nya revisioner av moderkorten då. Vid 3500 på ram tror jag verkligen vi får se vad Ryzen går för och med möjligheter att ändra på subtimings så får vi också se vad latens på ram ger när flaskhalsen förhoppningsvis har flyttats.

Var väl ändå självklart att Infinity fabric minst måste matcha bandbredden för dual-channel RAM, eller? Om så inte hade varit fallet vore det omöjligt för CPUn att utnyttja full bandbredd för RAM då både CCX och minneskontroller är klienter till Infinity fabric.

Vidare får man tänka på att denna kapacitet delas även av all I/O, d.v.s. all PCIe-traffik måste också få plats i bandbredden som Infinity Fabric har.

Som @wowsers nämner ovan påminner just kopplingen RAM<->CPU-kärna i Zen rätt mycket om hur IBM designade POWER8. I båda fallen har man lyft ur minneskontroller från att vara en integrerad del av CPUn, i någon bemärkelse har man återinfört "north bridge" där NB nu representeras av en xbar-buss.

I både Zen och POWER8 resulterade det i högre latens mot RAM. Men fördelen är att man har en mindre tight koppling mellan CPU-kärnan och protokollet som RAM pratar. I fallet POWER8 har man ett helt eget protokoll, CPUn pratar överhuvudtaget inte med RAM utan med det man kallar Centaur som i första ledet består av en eDRAM-cache (L4$). POWER8 kan därför enkelt stödja både DDR3 och DDR4 utan att det påverkar designen av CPU-kärnan.

Däremot skiljer sig Zen och POWER8 i hur de hanterar L3$, inte allt för vågad gissning att detta kommer av att IBM hade långt mer svängrum i sina val då minneskonsistensmodellen i POWER ISA är långt mindre strikt än vad som är fallet för x86. Många hänger upp sig på att x86 har CISC-rötter, det är totalt irrelevant idag då designen ändå är en RISC internt.

Om det är något som är ett problem för x86 så är det den onödigt strikta minneskonsistensmodellen, den är tyvärr något som gör x86 mindre lämpad för SMP än t.ex. POWER och ARM. Blir ingen jätteskillnad i prestanda, men detta är något som AMD/Intel tyvärr måste kasta rätt mycket mer kisel på jämfört med andra och det begränsar hur "bred" design som är vettigt att göra. Apple har ju en "bredare" design i sin mobil CPU än vad AMD/Intel har i sina high-end designer...

Hur reder du ut att schemaläggaren faktiskt kör oftare än var 15,6 ms? Det enda jag ser i dokumentationen är att en högre upplösning på system timern gör det möjligt att få bättre upplösning i anrop som WaitForSingleObject och liknande.

I normalfallet kan man bara blir uppväckt med var 15,6 ms. Vad spel och liknande verkar göra är att ökar upplösningen via timeBeginPeriod/timeEndPeriod. Detta gör det möjligt att sova med ner till millisekundupplösning.

Dock verkar fortfarande schemaläggaren köra var 15,6 ms då OS-tick värdet verkar uppdateras med samma frekvens oavsett vilken upplösning man begär. I alla fall enligt detta program (resultatet blir alltid 15 eller 16 ms oavsett upplösning på tick-timer).

// ticktock.cpp : Figure out the resolution of the Window tick-counter.

#include "stdafx.h"
#include <windows.h>
#include <iostream>

#pragma comment(lib, "Winmm.lib")

using namespace std;

int main()
{
    DWORD y;
    for (int i = 0; i < 100; i += 10) {
        UINT uPeriod = i + 1;
        if (timeBeginPeriod(uPeriod) != TIMERR_NOERROR) {
            cout << "Failed to change tick resolution" << endl;
        }

        y = GetTickCount();
        DWORD z = y;
        while (z == y) {
            z = GetTickCount();
        }
        cout << z - y << endl;

        if (timeEndPeriod(uPeriod) != TIMERR_NOERROR) {
            cout << "Failed to revert tick resolution" << endl;
        }
    }
    cin >> y;
    return 0;
}

Angående bandbredd: finns ju inget sätt att med x86 kod beskriva något som utför CCX-till-CCX kommunikation, så att prata om bandbredd för detta blir meningslöst.

Däremot kan man göra minnesoperationer och i Zen går dessa både till andra CCX och RAM i fall där man missar lokal cache. Bandbredd för en viss minnestransaktion dikteras då av single-channel bandbredd då varje enskild access går till en av de två minneskanalerna.

En minneskanal är 64-bitar bred (8 bytes) och data läses både på stigande och fallande flank, vilken man kan se som en effektiv minnesbredd på 128-bitar (alt. kan man se det som 64-bitar med dubbla frekvensen).

Vid DDR4-2667MT får man då en bandbredd på: 1,333 (frekvens) * 16 (effektiv bredd i bytes) = 21,3 GB/s som AMD verkar runda uppåt till 22 GB/s. Så det är vad 22 GB/s siffran i CCX-till-CCX bandbredd som bl.a. hardware.fr nämner.

Total kapacitet på Infinity Fabric är dubbla, d.v.s. 43 GB/s, detta då bussen är 256-bitar (32 bytes) bred. Hela bandbredden kan absolut utnyttjas i lägen där flera CPU-kärnor samtidigt gör access mot RAM, men varje enskilt anrop går bara mot en minneskanal.

Tror just denna uppdelning av minnesaccesser över kanaler är en stor förklaringen till varför E-serien inte ser större nytta av sin minnesbandbredd. Det krävs att minst fyra minnesanrop kommer samtidigt och att de går mot minnesadresser som råkar sprida sig över alla fyra kanaler. Händer ofta i serverlaster som har enorma "working-set", händer väldigt sällan i desktop-laster som tenderar ha väldigt hög datalokalitet (så det mesta hamnar på en enda kanal).

Ryzen borde se samma effekt som Core. D.v.s. snabbare RAM fast bara en minneskanal kommer i de flesta fall vara snabbare än lite långsammare RAM med dubbla kanaler (där aggregerad bandbredd är väsentligt högre). Är alltså inte aggregerad bandbredd som är flaskhals utan bandbredd per kanal.

@Enigma: Väldigt intressant, Tusen tack för kunskapen och en bra förklaring!
Att välja 2 moduler över 4st var tack och lov ett självklart val för mig