::: AMD Zen Samlingstråd :::

CMT är bara en form av SMT.

SMT är definierat som en design där två eller flera CPU-trådar delar minst en av "fetch", "decode" och "execute".

I CMT delades "fetch" och "decode" i de två första inkarnationerna och endast "fetch" i de två senaste. Det är fortfarande SMT, en dålig variant av SMT har det visat sig, dock ändå SMT.

På hög nivå implementerar Zen och Core SMT på samma sätt, båda designerna delar alla tre stegen. Men går man in på detaljer i varje steg finns delmoment som kan vara separat per tråd, helt delat eller delat med någon form av viktning för någorlunda jämn fördelen.

Så SMT i Zen är inte identisk med SMT i Core. Faktum är att Intel bollat runt med vad som är per tråd och vad som delas mellan flera gånger, något som har haft en (liten) påverkan på enkeltrådprestanda kontra prestanda när båda trådarna används.

Detta är bilden AMD visat kring hur Zen delar upp saker

"micro-op queue" är t.ex. inte delad i Sandy Bridge och Skylake, men den inte är det i Ivy Bridge och Haswell (osäker på Broadwell).

En frågan: hur skulle någon kunna optimera för CMT utöver att OS scheduler känner till detta (vilket alla OS gör idag)?

Problemet med CMT var att man fick fler av nackdelarna än fördelarna från både Hyperthreading (dela även back-end) och från oberoende kärnor (inte dela något av de tre stegen). HT går faktiskt att specifikt programmera för på ett sätt som inte är en bra idé med separata kärnor. Kan inte se hur man kan göra något motsvarande för CMT, man kan ha missat något!

Och har aldrig pushar för CPUer med en kärna. Övergången från en CPU-kärna till två gav just de fördelar du beskriver. Man trodde därför att fler kärnor var ett vinnande koncept och tog rätt kort tid för de fyrkärninga modellerna att hitta ut både för stationära och kraftfullare bärbara.

Tyvärr gav inte övergången från två kärnor till fyra kärnor alls samma vinst för gemene man, för bärbara var det tvärtom negativt för en väldigt stor andel av fallen. Idag är bärbara med fyra kärnor därför en extremt smal nisch, betydligt smalare än för 4-5 år sedan.

SMT är vettigt för det kostar nästan ingenting. Enda konkreta siffror jag sett är att det ökade transistorbudget med mindre än 5 % på Pentium 4. Så idag lär SMT kosta max 1 % av transistorbudget på high-end modeller.

Att ha mer än en kärna är bra just för interaktiva applikationer. Orsaken är att det interaktiva jobbet då får 100 % av en kärna för att göra sina saker, resten körs "i bakgrunden".

Precis som du säger kvittar det typiskt om det man kör i bakgrunden tar 10 sekunder eller 14 sekunder. Är också sällan som det man kör i bakgrunden verkligen maxar en kärna till, Windows har trots allt haft preemptive multitaskning sedan Win95 (Linux och OSX har alltid haft det)...

Så vad jag säger är att för den stora massan som använder en dator är idag den mest optimala designen för att lösa uppgiften två kärnor med så hög prestanda som möjligt. SMT bör slängas med då det ändå inte kostar något (i alla fall inte på något likt Zen och Core).

Spel har ändå kommit så pass långt att det idag faktiskt finns en poäng med fyra kärnor. Men allt över fyra kärnor med SMT presterar i praktiken lika eller sämre. Möjligen skulle en optimal spel CPU lägga fler transistorer på cache, fyra Core-kärnor tar idag mindre än 100 mm2 och Zen-kärnor lär i alla fall inte vara större på motsvarande tillverkningsnod. Så finns ju möjlighet utrymmesmässigt att stoppa in lite annat på kislet.

Om du nu hade andra länkar som visar att de skriver är korrekt, använd då de länkarna för det du faktiskt länkade visade att IPC absolut inte är samma. Och då Kaby Lake redan är lanserad i form av t.ex. i7-7500U (en modell som också visar att 14 nm+ gör precis vad som tänkt, hyfsad frekvensökning från 6500U med samma TDP) samt i5-7200U (som har exakt samma bas och boost frekvens som i7-6500U) så finns det en rad tester som visar att IPC är något högre, men visst kan man lita på en random kinesisk webbplats i stället...

För att hålla sig till Zen spåret (det var trots allt du som drog in Kaby Lake, men för att sätta Zen i ett kontex måste man rimligen jämföra med andra modeller). Du är alltså, på de som av någon outgrundlig anledning förväntade sig gigantiska IPC-förbättringar i Kaby Lake vägnar, upprörd för att så inte blev fallet? Men det finns ändå en stor lättnad i luften i form av Zen, som i bästa fall matcha ett par år gamla Intel modeller när det kommer till IPC och absolut prestanda. Är det rätt tolkat?

Zen kan absolut bli en framgång, framförallt på serversidan (min gissning från vad som framkommit så här långt, vilket inte är mycket).

Men är man ute efter bästa tänkbara prestanda på skrivbordet och bärbara kommer man bli besviken på Zen.

Eller besviken är kanske fel ord, sedan mikroarkitekturen för Zen blev känd borde man aldrig ha förväntat sig mer än absolut maximalt Haswell IPC. Även Haswell IPC är att ställa förväntningarna väldigt högt p.g.a. av en del designbeslut i Zen. Designbeslut som ändå har fördelar i enklare och därmed mindre kärnor, något som kan utnyttjas i servers till att ha fler kärnor på en given ytan.

"Alla" vet att om man med en given transistorbudget gör fler enklare kärnor blir prestanda per tråd lägre medan aggregerad prestanda blir högre. Många enklare kärnor har, inom rimlighetens gräns, också betydligt bättre aggregerad prestanda/W. Däremot har både Apple och Intel visat att för interaktiv användning ger väldigt hög IPC med lite lägre frekvens klart bäst upplevd prestanda/W.

Finns vissa områden där Zen borde prestera väldigt bra givet dess mikroarkitektur, i teorin ganska mycket bättre än Skylake/Kaby Lake. Detta är program som skalar perfekt över CPU-kärnor, som främst är begränsade av flyttalsprestanda och där flyttalsoperationerna är x87 eller SSE (inte AVX).

Det faktum att i princip alla läckta prestandasiffror kring Zen just spelar på dessa styrkor ger mig känslan att detta är "läckor" helt sanktionerade av AMD. Absolut inget fel i det, tvärtom ett exempel på att AMDs PR-avdelning inte är helt tappade bakom en vagn.

Det trista är att man ännu har liten känsla för var Zen hamnar då prestanda vid heltalsberäkningar är betydligt viktigare, både på skrivbordet och för servers. Här finns överhuvudtaget inget läckt, i alla fall inte vad jag kunnat hitta.

Du drar för stora växlar på Intels IPC-förbättring och "upplevd prestandaförbättring". Visst har väl kommande Kaby Lake lite bättre IPC än föregångaren som har lite bättre IPC än föregångaren och så småningom Haswell. Jag kollade lite tester och senaste aktuella Intel CPU är snabbare i vissa tester än Haswell, men jag hittade också tester där det var obetydliga skillnader.

Om AMD Zen kan vara i närheten av Haswell är det tillräckligt bra för deras del. De kommer vara billigare än Intel så länge inte Intel prisdumpar om de nu äntligen får lite konkurrens. En prisvärd AMD Zen kan mycket väl bli en bra produkt, trots din negativa inställning.

Sen gissar du också att det går att bygga oerhört komplexa få-core CPU som bara blir snabbare och snabbare överlag. Jag gissar själv att det finns ett tak där - när komplexiteten i en enskild core blir så hög att det blir oerhört svårt att öka IPC så att det märks för användarna.

@Buio och @Enigma

För att vara riktigt på det klara här: min förväntning på IPC ökning hos Kaby Lake är inte högre än ett par procent. Vad det ser ut som är att det just handlar om 0-5 % beroende på fall. Kombinerat med alla förbättring, inklusive frekvenshöjningar så verkar 6700K -> 7700K ge ungefär 10 % när CPU-delen är flaskhals, vilket är mer än vad jag skulle gissat innan men absolut inget man uppgraderar för.

Intel själv hävdade mellan 12-19 % i7-6500U -> i7-7500U, varav 8 % (multitrådat) 12 % (enkeltrådat) kommer från högre frekvens. Det är också vad tester visat är fallet i praktiken, t.ex. 16 % i enkeltrådad Cinebench

Det enda som spelar roll i slutändan är faktisk prestandaförbättring, d.v.s. frekvens * IPC där "IPC" här är ett ganska löst begrepp som innefattar alla former av förbättringar som påverkar prestanda. Ett exempel som rent tekniskt inte ökar IPC, men ändå ökar faktiskt prestanda i vissa applikationer, t.ex. många webbapplikationer, är om en CPU kan nå sin maximala frekvens snabbare.

Så låt oss sätta detta i kontext mot Zen. AMD själv hävdar 40 % högre IPC jämfört mot Excavator. 40 % är ju ett väldigt mycket större siffra än Intels 12-19 %, eller hur?

IPC är i sig irrelevant, det som spelar roll är som sagt IPC * frekvens. Den snabbaste Excavator modellen jag hittar resultat för är A12 9800 i form av denna stationära dator från HP.

A12 9800 har en maximal frekvens av 4,2 GHz, exakt samma som FX-8350. Tittar man på enkeltrådprestanda i Geekbench 3 (typ det enda jag hittar A12 9800 resultat för) så har IPC faktiskt bara ökat med 5 % från Piledriver till Excavator (förbättringarna verkar större för multicore men är svårt att jämföra då det är olika antal CPU-trådar).

Geekbench 3 har en rad brister, Geekbench 4 har fortfarande en lång rad brister men är ändå ett klart lyft. I Geekbench 4 så har A10 9800 och 5 % högre IPC jämfört med FX 8350, så båda fallen är i alla fall överens på den punkten.

Ergo, Zen har ungefär 47 % högre IPC jämfört med FX 8350, låt oss säga 50 % högre.

SweClockers test av i7-6700K, låt oss ta Cinebench då det är första test och körs med en tråd (A10 7870K, Steamroller, är med i testet men har av någon anledning 2 % lägre IPC jämfört med FX 8350 här, så låt oss använda det för Zen mest gynnsamma fallet: Piledriver).

Här får 8350 99 i resultat, Zen har 50 % högre IPC men toppar enligt de senaste ryktena på 3,5 GHz. Så ett fiktivt resultat för Zen är 25 % högre enkeltrådprestanda jämfört med Piledriver. Det placerar den på en fiktiv poäng av 124, vilket är en bit bakom i7 2600K på 133.

i7-7700K har enligt detta runt 50 % högre enkeltrådprestanda jämfört mot den fiktiva Zen modellen, vilket jag tycker låter väl högt. Finns jämförelser mellan 8-kärnor Zen och 6-kärnors Broadwell som pekar på att dessa presterar likvärdigt i multitrådade Cinebench, det handlar då om ca 33 % högre prestanda per kärna för Broadwell.

Det som jag tycker gör diskussionen kring vad som är imponerande och vad som är patetiskt rätt udda är att: ~25 % boost i enkeltrådprestanda (baserat på vad AMD sagt om Zen kontra Excavator och givet vad som är läckt kring frekvenser) är alltså fantastiskt, det mot en design AMD själva klassat som dålig och som lanserades hösten 2012. Medan 12-19 % (Intels siffror för i7-6500U -> i7-7500U) är dåligt medan de ~10 % man verkar få 6700K -> 7700K är patetiskt, det är mot något som lanserades hösten 2015 och var de snabbaste modellerna pengar kunde köpa inom respektive område då.

Hoppas verkligen beräkningen ovan inte alls är korrekt. Men kanske finns en orsak till varför inga heltalsresultat läckt.

Kan också vara så att jag gjort några rejäla tankevurpor: om någon ser en sådan, ser med glädje att hen tar ett sådan tillfälle i akt och ställer mig i den offentliga skamvrån!

Haha, ser att du redan lever i drömmarnas värld när jag ser din nya signatur

Just cache-designen finns ju en hel del konkret information kring, direkt från AMD själva.

En sak som förvånade många, inklusive dig givet vad som skrivs i första post i denna tråd, är att AMD fortsätter med en icke-inkluderande policy för LLC. Eller rent konkret säger AMD "L3 is mostly exclusive vs L2".

Det som är förvånande med detta är att nästan alla har övergett icke-inkluderande cache-hierarkier. Så länge CPUer hade en kärna var inte valet alls självklart, det finns fördelar med icke-inkluderande cache i form av högre hit-rate och finns fördelar med inkluderande cache i form av lägre latens och mer flexibilitet kring i antal sektioner (d.v.s. mer flexibilitet i att välja "n" för "n-Way Set Associative").

När man går till multicore tillkommer en fördel för inklusive cache förutsatt att man har en LLC som delas av alla CPU-kärnor: LLC kan användas som snoop-filter vilket kraftigt minskar latensen för att hantera cache-missar i CPU-lokal cache.

Har kan man eventuell spekulera i att Zen ändå inte fått denna fördel då LLC endast delas mellan de fyra kärnor i samma CCX (CPU CompleX). En annan förklaringen är att man helt enkelt inte hade resurser att göra en helt ny design, AMD har ju kört icke-inkluderande cache sedan Athlon.

Designen Zen har nu kommer ha rätt hög latens när man måste slänga ut en cache-line i L2 då det man slänger ut först måste kopieras till L3 (inte ett hårt krav men är så Zen fungerar enligt AMD)

Vad det gäller bandbredd är den väldigt låg för främst skrivning i hela Bulldozer-serien. AMD säger att Zen ska ha ~x2 högre L1/L2 bandbredd och upp till x5 aggregerad L3-bandbredd

Frågan är vad "total L3" bandbredd exakt betyder då varje CCX lär linjärt öka detta värde. Så hur många CCX är inkluderad i x5 siffran?

Jämfört med FX 8350 har i7 6700K ungefär (enligt AIDA64)

• L1 x2,0 läs, x5,6 skriv och x2,1 kopiering

• L2 x1,4 läs, x3,4 skriv och x2,5 kopiering

• L3 x2,1 läs, x6,7 skriv och x5,1 kopiering

I praktiken är cache-bandbredd sällan en flaskhals. Som exempel dubblades L2-bandbredd mellan Ivy Bridge och Haswell utan att ge något gigantisk effekt.

Ett problem med jämförelsen ovan är att det är summan över alla CPU-trådar, så blir alltid ett problem hur man ska räkna 8350 (A10-7860 har ungefär halva L1/L2-bandbredden mot FX 8350).

En effekt av CCX designen borde i alla fall bli att alla Zen-modeller med flera än 4-kärnor kommer få ett visst mått av NUMA-problematik. Det är högre latens mellan två kärnor i olika CCX jämfört med två kärnor inom ett CCX. Helt omöjligt att säga exakta effekten av detta i praktiken, det lär vi heller knappast få veta innan Zen-testerna börjar ramla in i januari.

Din matte är inget vidare. Du verkar ta de fall där Kaby Lake har sin allra högsta IPC-ökning för att räkna ut hur snabb Kaby Lake är. Men för Excavator så plockar du ut ett test som verkligen inte är best case scenario. Sedan lägger du på de omtalade 40% i prestandaökning i ett test som råkar vara den svagaste punkten för AMD i dagsläget, och en punkt där vi antagligen kommer få se betydligt mer än 40% prestandaökning. Det blir väldigt sned matte av det hela.

T.ex. så är Steamroller i 7850K hyfsat jämn med Piledriver i 6800K trots 400MHz lägre frekvens i både bas och turbo-frekvens. Så jag skulle vilja påstå att Excavator är 10% snabbare än Piledriver redan där. Och sedan verkar Excavator ha nästan lika stora prestandaförbättringar över Steamroller:
http://excavator.looncraz.net/

Sedan då att du lägger din låga guesstimate på 50% över Piledriver i just Cinebench. 40% över Excavator ska av allt att döma inte vara best case scenario. Men av allt att döma så kommer prestandaförbättringarna i Zen i just flyttal vara just best case scenario. Alltså tror jag att i just flyttal så kommer vi se betydligt högre än 40% över Excavator. Och eftersom just Cinebench är något där AMD presterar riktigt dåligt med dagens processorer så lär ökningen där i och med best case scenario vara mycket högre.

Jag gissar att 40% och under avser heltal och när cache håller tillbaka, medan i flyttal och flertrådat så är ökningen markant högre. Jag skulle inte vara förvånad om vi ser best case på 60-70% högre IPC.

Förövrigt så anser jag att det är väldigt vanskligt att försöka räkna med svepande och luddiga prestandaökningsanspråk som bas på arkitekturer med vitt skilda prestandaprofiler.

Tyckte jag skrev klart och tydligt: Geekbench 3/4 var det enda resultat jag kunnat hitta för någon Excavator modell. Intels modeller presterar inte speciellt bra i Geekbench, överhuvudtaget presterar x86 rätt dåligt jämfört med ARM men spelar ju liten roll när jämförelsen är mellan x86 CPUer.

Skrev också varför jag inte tittar på flertrådat, man hamnar direkt i en rad problem. Främsta problemet är: vad jämförs då Bulldozer-moduler och Zen kärnor är rätt olika.

Sedan skrev jag också att kvoten Skylake/Zen känns lite väl, men enda referensen som jag känner till är att i7-6800K och toppmodellen av 8-kärnors Zen tydligen ska vara jämna i multicore Cinebench och i så fall har Broadwell en 33 % prestanda-per-kärna fördel.

Sedan vet jag inte om single core Cinebench är så dåligt för AMD relativt annat. Geekbench 4, A12 9800 vs 6700K säger att den senare är 99 % snabbare i enkeltrådprestanda (båda har 4,2 GHz som maxfrekvens), vilket ger mer eller mindre exakt samma relativa prestanda mot Zen som jag fick med Cinebench.

Notera att Kaby Lake inte fick speciellt hög IPC ökning i Cinebench. 7500U har 13 % högre klockfrekvens jämfört mot 6500U i enkeltrådade fall, så 16 % totalt betyder en IPC-ökning på endast 2-3 %. Finns fall i TomsHardware där man verka nå 5-6 % högre IPC (noter att "IPC" är en väldigt lös definition här, misstänker att Kaby Lake U-serien får en del av sin "IPC" ökning från att snabbare nå maxfrekvens).

Tycker du själv 60-70 % verkar sannolikt för heltal då Excavator har 2 ALU och 2 AGU medan Zen har 4 ALU och 2 AGU. Är ju inte ens teoretiskt möjligt om minnesoperationer är minsta flaskhals.

Är det ens möjligt med 60-70 % för flyttal när man pratar enkeltrådprestanda? Är ju faktiskt lika många FPU-pipelines per Excavator modul som per Zen kärna. Tittar man i GCC-patchen för FPU-schemaläggning (som är gjord av AMD) så verkar ju Excavator och Zen i princip ha samma FPU. Enda skillnaden (och den är naturligtvis relevant) är att Zen kan ha upp till 96 i stället för upp till 60 instruktioner "in-flight" i scheduler-kön.

Här kan man jämföra med att Skylake har ungefär dubbla djupet över Sandy Bridge (97 mot 54, men är för alla typer av instruktioner) + att Skylake har en 33 % bredare back-end, 25 % bredare front-end och 100 % högre max sustained IPC (där "IPC" här refererar till interna micro-ops). Är ju inte en gigantisk skillnad ändå.

Edit: oavsett vilket, heltalsprestanda är långt viktigare än flyttalsprestanda. Det både för servers och skrivbordet.

Att öka antal ALU har då inte varit linjärt på någon annan CPU utom möjligen när man går från 1 till 2 ALUs, över det är blir det snabbt "diminishing returns". Och det innan man väger in att Zen har distribuerad schemaläggare för heltal medan Bulldozer-serien (och Athlon-serien innan det) samt Core-serien har en global schemaläggare för heltal.

En global schemaläggare är mer komplicerad och äter därför fler transistorer, men fördelen är att man i genomsnitt för högre nyttjandegrad på ALUs med en sådan.

Test som skulle vara långt mer värd för att göra en bra jämförelse här är JavaScript benchmarks som Google Octane eller Mozilla Kraken. Kompilatortest skulle vara guld, SPECInt helt OK. Posta gärna sådana resultat i denna tråd om de finns för Zen.

Vilket trots allt är relevant då det mesta som är prestandaintensivt för en SweClockare använder åtminstone 2 kärnor. Vi snackar spel, grafiskt skapande och videoredigeringar.

Geekbench verkar ju också ganska ofta vara just FPU-intensivt om man tittar på delmomenten. Så om det inte skiljer så mycket jämfört med Cinebench-resultat så kanske det inte är jättekonstigt.

Nu gör du en klassisk Yoshman och förvränger det man säger till att innebära något helt annat. Jag var mycket tydlig med att 60-70% var best case och skulle gälla flyttal vid flertrådat där Zen har dubbel teoretisk prestanda per Hz över BD-derivaten. Heltal var som sagt worst case i mina gissningar där förväntar jag mig under 40%.

Ja du kan ju fabulera att jag sa enkeltrådsprestanda, men jag sa tydligt att best case för prestandaökningarna är flyttal vid flertråd.

Att låtsas som att 60-70% skulle gälla heltal och enkelttråd är bara fult och oärligt. Förstår inte varför du alltid ska sänka dig till sådana diskussionsmetoder.

Ja, jag har inte hävdat någonstans att Zen kommer vara mycket starkare på heltal. Sedan så tänker jag att bara för att en normal användare surfar runt mycket betyder inte det att det är där man behöver prestandaökningar. Din förkärlek för heltal och kompilatorprestanda speglar nog ditt egna användarmönster mer än andras. Hittills är nog du den enda jag vet som hävdar att flyttal är oviktigt i moderna spel förövrigt.

Men hursomhelst. Det är vanskligt att försöka räkna på sånt här. Min poäng var att du tycktes aktivt söka sätt för att få matten att peka åt ett förutbestämt håll.
För många här är det inte prestanda mot Kaby Lake som är det relevanta, utan att man får riktigt bra prestanda för pengen samtidigt som man kan få stödja en underdog. Saknas klockbara mellanalternativ idag. Mycket av det som var roligt med hårdvara förr var ju att man kunde köpa billigt men få bättre prestanda i slutändan med lite pulande. Idag så är det så att om man vill pula alls så är det bästa i5 eller i7 som gäller.

Det är ju dock ett lite konstigt sett att se på det.

Visst hade det varit intressant om Intel inte hade tagit sig så långt som de gjorde med Nehalem/Sandy Bridge men vad hade det varit för roligt med ett 5-6 år långt intensivt priskrig i prestandaklassen som FX-serien legat i?

Jag är glad att spelen inte behövt stanna upp sin utveckling av fysik i spelmotorer bara för att AMD inte lyckats producera något imponerande på flera år.

Skickades från m.sweclockers.com

Jag är intresserad av vad AMD kan göra med Zen eftersom det för min del inte finns något alternativ. Hoppas och tror att AMD ska kunna toppa Bulldozer med råge för då blir det intressant på riktigt!

Inga benchmarks testar två trådar, vet man däremot prestanda för en CPU-tråd går det alltid att extrapolera med bra träffsäkerhet.

Eftersom jag bara skrev om enkeltrådprestanda så förutsatte jag att eventuella jämförelser är mot det. Kommentaren kring 60-70 % var därför helt rimligt att ifrågasätta då det hela handlade om enkeltrådprestanda.

Tänk själv: hur ska man kunna göra några vettiga jämförelser överhuvudtaget mellan Intels Core, AMDs Bulldozer-serie och på något överhuvudtaget relevant sätt extrapolera det till Zen?

FX 8350 är och presterar i de flesta fall som en fyrkärning CPU, därför blir även 60-70 % helt orimligt även mot 8-kärnors Zen. Om inte SR7 presterar minst 100 % bättre än FX 8350 är Zen i heltal när alla kärnor används så har AMD ett stort problem. I det läget ställer man en 4-kärnig CPU med SMT mot en 8-kärnig CPU med SMT mot varandra, med 50 % högre IPC i Zen ska den vara ~150 % snabbare.

Jag söker aktivt efter alla testresultat jag hittar kring Zen och läser all information som går att komma över. Det finns inte så många testresultat, de få som finns så här långt med undantag för Blender visar ungefär samma sak (och ungefär samma sak här är plus/minus 20-25 %, d.v.s. rätt stort spann men inget säger än att ovan är helt fel).

Tittar man på Blender så är ju problem #1 att AMD begränsade frekvensen på Intels CPU.
Problem #2 är att Blender är så mycket "best-case" som går att hitta om man tittar i källkoden, specifikt matematikbiblioteket.

Enligt AMDs presentationsmaterial har Zen FPU 4 pipelines, vilket också stämmer vad som står i GCC. Tidigare slides pekade på att Zen skulle få 256-bitars FPU pipelines, men det var tydligt fel, det är 128-bitars så AVX-operationer tar dubbla tiden.

Matematiken i Blender använder endast skalära SSE operationer och verkar mest vara SP (32-bitars flyttal), exemple

void mul_m3_m3m3(float m1[3][3], float m3_[3][3], float m2_[3][3])
{
    float m2[3][3], m3[3][3];

    /* copy so it works when m1 is the same pointer as m2 or m3 */
    copy_m3_m3(m2, m2_);
    copy_m3_m3(m3, m3_);

    /* m1[i][j] = m2[i][k] * m3[k][j], args are flipped!  */
    m1[0][0] = m2[0][0] * m3[0][0] + m2[0][1] * m3[1][0] + m2[0][2] * m3[2][0];
    m1[0][1] = m2[0][0] * m3[0][1] + m2[0][1] * m3[1][1] + m2[0][2] * m3[2][1];
    m1[0][2] = m2[0][0] * m3[0][2] + m2[0][1] * m3[1][2] + m2[0][2] * m3[2][2];

    m1[1][0] = m2[1][0] * m3[0][0] + m2[1][1] * m3[1][0] + m2[1][2] * m3[2][0];
    m1[1][1] = m2[1][0] * m3[0][1] + m2[1][1] * m3[1][1] + m2[1][2] * m3[2][1];
    m1[1][2] = m2[1][0] * m3[0][2] + m2[1][1] * m3[1][2] + m2[1][2] * m3[2][2];

    m1[2][0] = m2[2][0] * m3[0][0] + m2[2][1] * m3[1][0] + m2[2][2] * m3[2][0];
    m1[2][1] = m2[2][0] * m3[0][1] + m2[2][1] * m3[1][1] + m2[2][2] * m3[2][1];
    m1[2][2] = m2[2][0] * m3[0][2] + m2[2][1] * m3[1][2] + m2[2][2] * m3[2][2];
}

Om AMDs slides stämmer (får inte riktigt ihop det med GCC-information) så kan Zen göra 2 "add" och 2 "mul" per cykel för upp till 128-bitars vektor register.

Jämför med Intel, specifikt Broadwell de jämförde med. Den har 3 flyttals pipeline, men helt optimerade för vektoroperationer. Blender kör skalärer, så en pipeline blir i det fallet i praktiken meningslös. Broadwell har 256-bitars FP-pipelines, men Blender använder bara 32-bitars operationer (det pratas en hel del i utvecklar trådar om att man bör lyfta Blender, fanns AVX exempel som ökade prestanda med upp till en faktor 10, men finns alltså inte i skarpa versionen än). Så Broadwell kan bara göra 2 st 32-bitars skalära flyttalsoperationer per cykel.

Så om AMDs slides stämmer har alltså Zen ett teoretisk övertag på 100 % för beräkningar i Blender. Zen kan utföra 4 skalära flyttalsberäkningar per cykel, förutsatt att det är 1:1 mul/add vilket ungefär vad får vid matrismultiplikation (som typiskt är extremt vanligt i sådana beräkningar, varje CUDA/stream-core i GPUer är i praktiken en FMA ALU, d.v.s. kapabel till att göra en mul och en add per cykel).

Känns då resultaten ovan så totalt ute i spenaten om man i Blender matchar IPC för Broadwell?

Edit: för att sätta i relation. Använder man i stället AVX så kan Haswell och framåt utföra 32 SP per cykel mot 16 SP för Zen, vidare får då också den 3:e FP-pipeline som Intel har en viktig poäng i att arrangera data i vektorregister (shuffle and blend). Zen får utföra dessa operationer (som alltid måste göras både i SSE och AVX när man jobbar med vektoriserad data) i samma pipelines som också gör beräkningar (enligt GCC data så kan två av fyra Zen FP-pipelines används för shuffle/blend).

Och spänn av lite

Detta är en diskussion. Givet mängden konkret information vi har så är i princip allt mer eller mindre vilda gissningar. Men är inte hela syftet med tråden just att spekulera och diskutera vad Zen kan tänkas bli?

Eller är syftet med tråden att ryggdunka varandra kring hur awesome Zen kommer blir och hur mycket *-Lake suger. Det oavsett vad annan information säger?

@sAAb: alla tester utom Queen och Geekbench är mer ett test på RAM latens/bandbredd än något annat.

Sedan verkar Geekbench resultatet helt fel. Min gissning är att de tog den frekvens som Geekbench rapporterade när de beräknade för IPC, just X4 845 får konsekvent en rapporterad frekvens på 1,91 GHz vilket när man jämför med 4,2 GHz FX-8350 är totalt orimligt.

I stället lär den gå på de 3,8 GHz som den ska gå på enligt specifikation.

Ställer man den då mot i5 2500K är Sandy Bridge modellen ca 61 % snabbare i enkeltrådfallet, vilket kompenserat för frekvens ger en IPC-fördel på 85 63 % (tänkte i3, är ju i5 så är 3,7 GHz maxfrekvens) för Sandy Bridge över Excavator.

Enligt Geekbench har m3 7Y30 (Skylake Core M) högre enkeltrådprestanda än X4 845.

D.v.s både Queen och Geekbench visar precis på de resultat jag räknade fram ovan.

Enda man med säkerhet kan säga idag kring detta är:

• Latens på LLC kommer vara sämre än Intel, ren fysik och fakta kring en LLC som är icke-inkluderande med en lägre nivå cache som inte delas av alla kärnor. Däremot kan man inte säga något om bandbredden relativt något annat bara för att det är olika typer, d.v.s. finns inget fysiskt hinder att bandbredd är högre än vad Intel har.

• interconnect kommer, åter igen av rena fysiska begränsningar, ha högre latens än mot lokal LLC. Däremot kan man med väldigt nära 100 % säkerhet säga att latens blir väsentligt mycket lägre jämfört med mellan CPU-sockets i NUMA-system. Jaguar designen i konsolerna kan nog vara en fingervisning, där är latens mellan de två 4-kärnor öarna ~190 cykler (finns ingen L3 här, latens mot L2 är ~26 cykler vilket är ungefär var Core-designen har mot L3). Bandbredd kan i teorin vara samma inom LLC som i interconnect, men inte speciellt sannolikt

Trots att vissa tagit fram högafflar och facklor för att protestera mot det jag gissat ovan så säger ändå den gissningen att SR7 borde ha en enkeltrådprestanda motsvarande i7 2600K. Vilket då betyder att SR7 presterar ungefär 100 % bättre jämfört med i7 2600 och FX 8350 i program som skalar perfekt med CPU-kärnor.

Det man får tänka på är att gruppen program som skalar till något större antal CPU-kärnor har ungefär samma marknadsandel än program som kan dra väsentligt nytta av AVX/FMA. "Alla" moderna matrisbibliotek har stöd för detta då AVX och FMA var för sig dubblar prestanda för matrismultiplikation. Vidare har GCC/LLVM fått stöd för autoamtiskt vektorisering via Cilk+ och LLVM kommer få CPU-arkitekturoberoende SIMD stöd (att det saknas har hela tiden varit tekniken akilleshäl) via ISPC som så här långt stödjer SSE, AVX, AVX2, FMA på x86 och NEON för ARM.

Verkar som många tycker "IPC motsvarande Sandy Bridge" låter horribel dåligt, men om man säger effektivt säger samma sak så här: upp till dubbla prestanda mot 2600K / FX 8350, så inser man nog ändå att det är en rätt bra boost.

Däremot betyder det att prestanda för saker som använder en till två trådar faktiskt hamnar i nivå med m3 7Y30 (Skylake Kaby Lake Core M, borde veta bättre då jag själv har en laptop med Skylake Core M...). Absolut tillräckligt för en klara majoritet av det normalanvändaren kör, men är "normalanvändaren" verkligen en sannolik köpare av en 8-kärnig CPU?

RedGamingTech spekulerar kring New Horizon Event.

Mer kärnor till folket!
Finns i redan dag spel, och andra program, där CPU:r med många kärnor premieras.

Det är en fördel att ha ett överskott av antal kärnor, likasom mängden arbetsminne, swaparea, effekt från nätaggregat, lagringsutrymme, hastighet på nätet, "you name it!".

Verkar inte bli så jämra dyrt heller.