Skrivet av sAAb:
Visst finns det siffror att backa upp det med. Det är ju det som är problemet idag, det finns så många siffror att man kan visa vad som helst för att få rätt. Du ställde en fråga i början på december förra året:
Nu har den kommit.
Titeln på sidan är "Benchmarks bei 3 GHz: AIDA64", dvs de är alla ställda på 3.0 GHz.
http://www.planet3dnow.de/cms/wp-content/gallery/ryzen/305.png
Du ställde frågan: "Och hur kan man då säga att IPC för Ryzen är på Haswell/Broadwell-nivå när det bara är sant för skalära flyttal?"
AIDA64 och Queen är väl knappast skalära flyttal.
Haswell-E och Ryzen får praktiskt taget samma värde vid 3.0 GHz, vid 8C/16T vilket alltså tyder på likvärdig IPC.
Skylake ligger på drygt hälften i "punkter" med 4C/8T, vilket också ger ett värde i samma härad, vilket också visar på likvärdig IPC.
Vad jag kan förstå borde då resultaten på sådan indikator, branch-prediction, stämma bättre överens med spelresultaten. Men, det gör det inte, och som vi har sett är dessa någorlunda "lågnivå-indikatorer" ganska oberäkneliga för spel. Ibland, i ett fåtal tester så vinner Ryzen över allt vad intel har, men dessa resultat verkar varken stämma med mina tidigare gissningar om uppdelningar på kärn- eller GHz-begränsade spel.
Vad jag försökte säga är att spelen verkar följa helt obeskrivna, tidigare okända lagar, som gissningvis då mer beror på spelens egna algoritmer, där cache-storlekar, matrishanteringar, mm döljs av annan, ren spel-logik vilket jag uppfattar att du också är inne på.
Spel skiljer sig på en väldigt fundamental punkt mot saker som Queen-chess, 7-zip, kompilering och det mesta andra tester för heltal. Återkommer till det.
Kan först nämna att jag känner mig rätt mycket mer bekväm i att göra utsagor kring spel, saker som kretsar runt operativsystem, webservers och parsers då det är alla saker jag jobbat eller jobbar med programvaruutveckling kring. Har under senare år jobbat väldigt mycket med utveckling av program som INTE är "embarrassingly parallel" men där man ändå vill dra nytta av multi-core, har utvecklat väldigt många framgångsrika algoritmer kring just synkronisering så borde förstå detta område rätt väl (alt. ha extremt tur att lyckat göra rätt utan att förstå varför...).
Är däremot ingen hejare på schack, kan nätt och jämt reglerna och har än mindre skrivit en schack AI. Fick därför gå på beskrivningen av vad Queen-chess testar, där stod det att testet var en bra indikator på kvalité av branch-predictor. Att det är mycket villkorad körning i en AI är uppenbart även för mig, vad jag däremot inte kunde bedöma är om det faktiskt finns en mönster i dessa villkor som en CPU kan lära sig. Här borde jag kanske tänkt tillbaka på tiden som spelprogrammerare (men det ligger ~15 år bakåt i tiden för min del...), spel AI är ett exempel på något där CPUer normalt inte kan förutspå hopp för man vill ha ett relativt stort mått av slumpmässighet här!
Visade sig att Queen-chess absolut är något som testar villkorade hopp på en extremt nivå. Gillar sådana tester då de ger en renodlad bild av en specifik detalj. De är däremot inte representativ för någon form av genomsnittlig prestanda. Detta, ihop med vetskapen att det är en AI samt det du visar att det även skalar perfekt med antal CPU-kärnor, visar dock väldigt bra vad Queen-chess faktiskt testar
Det är ett perfekt test av branch-misprediction-penalty! SMT är lysande i fall där man får mycket "stalls", i det läget blir hela CPU-kärnan underutnyttjad vilket betyder att det finns massor med prestanda att använda för en extra CPU-kärna (detta är ett fall där POWER8 rimligen krossar Ryzen och Core med sina 8 trådar per kärna).
Vad detta visar är att Ryzen är precis lika bra som Core att hantera felspekuleringar, vilket tyder på att den effektiva längden på kärnans pipeline är väldigt snarlik mellan dessa designer. Var just då spel ofta innehåller relativt mycket villkorade hopp som inte kan förutsägas som Nintendo valde en CPU-design för GameCube, Wii och Wii-U som inte ens försökte förutsäga hopp utan den var optimerad för att ha extremt låg branch-misprediction-penalty i stället (vilket tyvärr gjorde designen hopplös att klocka högt).
Men tillbaka till spel. Vad är den fundamentala skillnaden här? Spel kan använda många CPU-kärnor men de är absolut inte "embarrassingly parallel"! DÄR ligger en enormt viktig skillnad jämfört med nästan alla andra saker som testas då det betyder att kostnaden för att synkronisera jobb mellan CPU-kärnor blir en väldigt relevant faktor. Detta är precis vad jag jobbat väldigt mycket med senaste åren, d.v.s synkroniseringsbiten inte spel.
Rätt säker att jag även kan förklara varför Ryzen tappar mot Core i DX12, men skulle vilja se lite mer tester här innan jag slår fast något allt för säkert här. Även detta har med synkronisering att göra.
Spel är inte på något sätt ett avvikande värde. Tittar man på JavaScript, som är primärt heltal då själva virtuella maskinen är enbart heltal men i testfallen använder JS-programmen i vissa fall skalära flyttal, så ligger ju Zen strax under Sandy Bridge i IPC. Tittar man på enkeltrådprestanda (d.v.s. IPC * frekvens) ligger faktiskt Ryzen lite mer efter Kaby Lake än vad Piledriver låg efter Sandy Bridge. I IPC är dock skillnaden mindre då Piledriver var högre klockad medan Kaby Lake är högre klockad idag.
Det som lyfter Ryzen i heltal, vilket också var helt väntat givet designen, är att man har 8 kärnor samt att SMT i de flesta fall ger en större boost än på Core.
För heltal verkar enkeltråds-IPC ligga strax under Sandy Bridge.
För heltal verkar multitråds-IPC för sådant som är "embarrassingly parallel" ligga på Ivy Bridge nivå (och just i detta fall är det hyfsat stor skillnad i IPC mellan SNB och IVB, den senare fick en del förändringar i front-end som boostade just detta fall).
Om man tittar bakåt i denna tråd är detta precis vad jag förväntade mig efter att man presenterade Zens mikroarkitektur. Är ändå positivt överraskad av Ryzen då IPC i sig är irrelevant, det som spelar roll är IPC * frekvens och frekvensen hamnade högre än vad jag själv trodde!
Men kanske dags för de som hävdat att Intel bra latat sig erkänner att de kanske inte var helt rätt ute. Intels och Apples CPUer har en heltals IPC som fortfarande är generationer före alla andra. Det finns en hård gräns för hur mycket IPC som kan extraheras ur en enskild instruktionsström, dessa två företag kan lägga obscena resurser på FoU men de ligger idag väldigt nära den teoretiska gränsen för IPC med skalära heltal. Det "positiva" (om man vill se det så) är att övriga lär närma sig med tiden då ledarna är väldigt nära väggen nu!
Skrivet av Oegat:
En liten kommentar om denna frågan bara - finns det verkligen inga benchmarks som syntetiskt testar heltalsprestanda? Jag levde i föreställningen att dessa saker var det lättaste att testa, tex SiSoft Sandras MIPS och FLOPS (där jag trodde att MIPS = heltal). Men det är alltså inte så enkelt? Jag menar såklart inte att dessa tester ska användas istället för spel- och nyttoprogramtester, utan tillsammans med, för att förklara skillnader mellan olika scenarier.
Ja det verkar som att mycket är obesvarat här. Jag funderade på hur man skulle kunna testa den praktiska betydelsen av att trådar ibland behöver hämta information från L3 på en annan CCX än tråden körs på. Tills någon kommer på bra sätt att testa latens och bandbredd generiskt för kors-CCX-accesser så skulle man på följande sätt kunna testa hur stor impact detta har för tex. ett specifikt spel. Såhär -
22 GB/s CCX<->CCX bandbredd kommer tydligen från AMD och nämndes vid GDC, länk. Och om man som mig inte begriper franska.
22 GB/s är inte en fix gräns, utan den faktiska bandbredden är exakt samma som bandbredd per kanal mot RAM då hela Infinity Fabric delar klockdomän med minneskontroller.
22 GB/s är då DDR4 2667MT. Jag skriver alltid MT (megatransfers) och inte MHz då klockan för DDR är halva denna siffra.
Att Infinity Fabric delar klockdomän med RAM kan nog också förklara varför det är så pass struligt att köra RAM på riktigt höga frekvenser, är inte bara RAM-bussen man klockar upp!
AMD visade upp denna bild på GDC
Den förklarar också varför latens mot RAM är relativt hög, högre än Core-serien med som använder RAM med samma timings. Minneskontrollen sitter inte i CPUn, den är kopplad till Infinity Fabric.
Varje CCX är en klient till Infinity Fabric. Varje access mot RAM måste därför gå både till den andra CCX-klinent samt RAM och faktiskt latens blir tyvärr latens av det anrop som tar längst tid. Man gör i alla fall båda anropen samtidigt, rent logiskt vill man egentligen först fråga den andra CCX om det ligger cache där, annars gå mot RAM.
"In practice, a memory access for the processor does not take place in isolation. When the processor needs a data, it will begin by querying its cache hierarchy to see if the data is up-to-date. If this is the case, it will be read directly and no memory request will be made. The double partition of the L3 of Ryzen complicates things however. When a data is required, and after checking inside the CCX, the core will send two requests simultaneously, one to the other CCX, and the other to the memory controller. The two operations take place simultaneously (waiting for the response of the other CCX would be much too penalizing), but they impose an additional cost. AMD engineers have confirmed that we probably need to look at this side to explain the latency, even if the manufacturer has remained rather vague."
Latensen mellan CCX blir därför samma som mot RAM, det finns ingen dedicerad CCX<->CCX kommunikation utan Ryzen är verkligen två st 4 kärnors CCX som delar RAM.
Är också detta som nog gör att L3$ latens inte blir korrekt i AIDA. Ryzen har inte 16 MB L3$, går inte ens att göra ett syntetiskt fall där en kärna ser 16 MB L3$. Man har 2x 8 MB cache, så när AIDA mäter latens måste den vara medveten om att L3$ ska behandlas som 8 MB.
Mätning av latens för L1$, L2$ och RAM borde däremot vara korrekt.
Finns det inte syntetiska benchmarks för skalära heltal? För att svara på den frågan måste man inse att det är ungefär som att ställa frågan: finns det inte exempel på hur man räknar matematik?
Svaret är absolut ja, finns massor med sådana benchmarks. Problemet är att flaskhalsen för skalära heltal är extremt mycket mer varierad jämfört med skalära flyttal och vektoriserade flyttal/heltal.
De fall som är mest äpplen mot äpplen är de fall som skalar perfekt med CPU-kärnor, d.v.s. de fall som "embarrassingly parallel". Några sådana är 7-zip, Win-RAR och kompilering.
Men spel och de flesta desktop-program som kan utnyttja många CPU-trådar är INTE "embarrassingly parallel", så ovan är ingen bra indikator på vad man kan förvänta sig där.
Samma sak gäller "multi-taskande". Det ligger någonstans mellan dessa två fall. LinusTech hade ju något fall som kallades för "heavy multitasking" och där låg E-serien i topp, var en bit ner till R7-1800X som bara låg en hårsmån före i7-7700K.
Multi-tasking är något som inte alls skalar så väl med CPU-kärnor som visa i denna tråd försöker påskina. "Heavy multitasking" fallet är onormalt CPU-bundet, i lite mer normala fall (d.v.s. fall som är mer I/O-bundna) kommer antagligen i7-7700K hamna i topp då högre enkeltrådprestanda normalt gör att I/O-enheter kan presterar något närmare sin maximala kapacitet.