::: AMD Zen Samlingstråd :::

Hihi, byggsats!

Engineering sample?

För att vara helt korrekt säger hon "med samma energi-effektivitet".

"All right - with 150 samples, I get 4m10s, that is 250 seconds, on my 7850K at stock settings. That's with a freshly reinstalled copy of Blender 2.78a x64, just to be certain.
That's 7.14x slower than the Ryzen prototype, despite a slightly higher clock speed, with the only valid excuses being half the core count and no L3 cache. Damn, Steamroller sucks. (But we already knew that.)
Then I went to the BIOS and set up a fixed 3.4GHz clock speed, to match the Ryzen prototype as demoed. Result: 4m32s, or 272 seconds, 7.77x slower than the Ryzen prototype, on half the cores.
This indicates Zen has nearly double the IPC per thread, and nearly quadruple the IPC per core, versus Steamroller, on this particular benchmark. Piledriver is worse still, though I don't have exact figures for 150 samples yet."

https://www.reddit.com/r/Amd/comments/5ie7f0/summoning_uamd_r...

En ökning av IPC med nästan fyra gånger per kärna i Blendertestet.

Jag drog inte slutsatsen att de säkerligen har räknat en BD-modul mot en Ryzen kärna, jag menade att eftersom AMD har ökat så förbannat mycket i det test som jag sett, tyder det på, att de inte som de räknat per kärna utan räknat en Ryzenkärna per BD-modul.
Kan du inte se skillnaden mellan spekulation utifrån indicier och konstaterade av resultat utifrån fakta?

Ditt resonemang stämmer ganska bra, förutsatt att jag är nog imbecill att tro att AMD bara har koncentrerat sig på att få Ryzen så snabb som möjligt i Blender, eller tro att jag kan dra helt säkra slutsatser hur Ryzen presterar, utifrån ett enda test.
Ok du får tro vad du vill, men jag känner att vidare diskussion är fullständigt meningslös.

edit förstår inte varför du är så petig över vad jag skriver, vi måste väl kunna spekulera lite i en tråd som handlar om en CPU som inte släppts än och min spekulation har ju vissa fakta som pekar i viss riktning, även om det är långt i från bevisat, det är ju så en spekulation är.
Du får sista ordet, det bjuder jag på.

128- eller 256-bitar refererar här bara till den interna bredden på varje pipeline i FPUn. Både Zen och Bulldozer-serien kan endera köra två 128-bitars SSE/AVX instruktioner per cykel eller två 256-bitars AVX varannan cykel. Sandy Bridge och framåt man köra två 128/256-bitars SSE/AVX varje cykel. Det är vad skillnaden i bredd gör.

Går inte att använda en 256-bitars FPU pipeline till att utföra 4 st skalära ("vanliga" flyttalsoperationer så som de används i traditionell C++/C#/Java) 64-bitars operationer, går däremot att utföra 4 st vektoriserade (SIMD) 64-bitars operationer.

Zen verkar har två stycken 128-bitars pipelines för flyttal (i GCC ser det som sagt ut som de två andra FPU-pipelines också är 128-bitar men dedikerade för SSE/AVX-heltals). Det är i så all exakt samma sak som i Bulldozer-serien, men där är det totalt tre pipelines varav två verkar vara för både flyttal och heltal medan den sista är saker som shuffle/blend och lite annat smått och gått.

En 256-bitars pipeline kan bara köra en skalär 32-bitars eller 64-bitars operation, så för skalära storheter är det endast antalet pipelines som spelar roll. Jämför man då Zen (två 128-bitars pipelines) och Broadwell (två 256-bitars pipelines) så finns ingen kapacitetskillnad för skalära operationer.

Är därför som det finns ett stort tryck på att hitta en vettigt sätt att uttrycka sitt problem i högnivåspråk på ett sätt som effektivt kan översättas till SIMD-instruktioner. För GPUer (som i stort sätt är jättebreda SIMD CPUer) knäcktes detta med CUDA och OpenCL. Går att generera hyfsat effektiv SSE/AVX kod från CUDA/OpenCL, men de är främst designande för GPUer och utnyttjar därmed inte styrkorna fullt ut i SSE/AVX (som överlappar en hel del med GPU, men finns områden där SSE/AVX fungerar bra men GPU fungerar dåligt och vice versa).

Just att man vid single precision flyttal utnyttja 1/4 av en 128-bitars SIMD-enhet och bara 1/8 av en 256-bitars gör att man vill hitta vägar att frigöra den potentialen. Har man sedan något som kan utnyttja FMA (varje CUDA/stream-kärna i en GPU är definierad just som en FMA-enhet) fördubblas potentialen.

Det betyder att Zen skulle kunna köra t.ex. Blender upp till åtta gånger snabbare och Haswell-> upp till sexton gånger snabbare per kärna om man kunde vektorisera flyttalsoperationerna.

@anon159643: För mig känns det som SBS är den vanligaste flaskhalsen idag. Jämför man vad datorerna klarade av 1986 med idag och tittar på tätheten per effektiv kod så sklle det gå 10 ggr fortare om programmet var lika optimerat som det var på 80-talet. Idag har vi helt enkelt för mycket bling bling just bara för att vi kan.

Intel Core i7-3770k (Ivy Bridge 4c/8t) 
3.5 GHz (Turbo 3.9 GHz), DDR3-1600, 1 MB L2, 8 MB L3
491

Intel Core i7-4770t (Haswell 4c/8t) 
2.5 GHz (Turbo 3.7 GHz), DDR3-1600, 1 MB L2, 8 MB L3
489

Intel Core i5-4670k (Haswell 4c/4t) 
3.4 GHz (Turbo 3.8 GHz), DDR3-1600, 1 MB L2, 6 MB L3
487

Intel Core i5-4690 (Haswell 4c/4t) 
3.5 GHz (Turbo 3.9 GHz), DDR3-1600, 1 MB L2, 6 MB L3
476

AMD FX-8350 (Vishera 8c/8t) 
4 GHz (Turbo 4.2 GHz), DDR3-1866, 8 MB L2, 8 MB L3
473

Intel Core i7-4770s (Haswell 4c/8t) 
3.1 GHz (Turbo 3.9 GHz), DDR3-1600, 1 MB L2, 8 MB L3
436 

Intel Core i7-980x (Gulftown 6c/12t) 
3.33 GHz (Turbo 3.6 GHz), DDR3-1066, 1.5 MB L2, 12 MB L3
425

Intel Core i7-4770k (Haswell 4c/8t) 
3.5 GHz (Turbo 3.9 GHz), DDR3-1600, 1 MB L2, 8 MB L3
414

Intel Core i7-4790 (Haswell 4c/8t) 
3.6 GHz (Turbo 4 GHz), DDR3-1600, 1 MB L2, 8 MB L3

Intel Core i7-3960x (Sandy Bridge-E 6c/12t) 
3.3 GHz (Turbo 3.9 GHz), DDR3-1600, 1.5 MB L2, 15 MB L3 
385

Intel Core i7-4790k (Haswell 4c/8t) 
4 GHz (Turbo 4.4 GHz), DDR3-1600, 1 MB L2, 8 MB L3 
364

Intel Core i7-5960x (Haswell-E 8c/16t) 
3 GHz (Turbo 3.5 GHz), DDR4-2133, 2 MB L2, 20 MB L3
242

Har inte tittat i källkoden för Handbrake och kan inget om x264/x265. Google fram ett par presentationer, verkar främst vara heltalsberäkningar vid kodning/avkodning (känns rimligt då man verkar kunna göra väldigt billiga fixed-function kretsar för avkodning av x264/x265).

Vet vi exakt vilken codec AMD använde sig av? Kollade som hastigast i x264 koden, där finns rätt mycket handoptimering för MMX (lär knappast användas på dagens CPUer) och SSE3/4 (vektoriserade heltal), de gamla flyttalsinstruktionerna (x87) är i praktiken pensionerade idag.

Om vi antar att AMD körde någon codec som är vektoriserad med SSE3/4 så handlar det inte om "vanlig" heltalskod. Vad vi i stället fått en vink om är att FPU-delen i Zen nog är väldigt kapabel.

FPU-delen borde kanske bättre kallas för SSE/AVX-delen. "Vanlig" skalära flyttals hanteras i 64-bitars x86 via speciella SSE (32-bitars) och SSE2 (64-bitars) instruktioner.

FPU-delen i Zen har fyra pipelines. Om jag läst gcc-specifikationen för Zen rätt är två pipelines specialiserade för flyttal (både skalära och vektoriserad) och två är specialiserade till vektoriserade heltalsoperationer samt lite smått och gått som att formatera data inom vektor-registren (shuffle/blend).

Om ovan är någorlunda korrekt vet vi tyvärr inte alls något om hur "vanliga" heltalsdelen står sig samt hur pass väl cache-designen står sig (både blender och handbrake har extremt hög data-lokalitet, så cache-hit rate i L1/L2 är väldigt nära 100 %). Men kommer om inte annat vi skarp lansering, med lite tur får tech-siterna förhandsexemplar snart.

Av det jag lärt mig om Blender så här lågt skulle jag ändå säga att de fina resultatet i Handbrake känns betydligt mer betryggande än resultatet i Blender...

Exempel på hur vi halvt om halvt pålästa är tacksamma att dina kunskaper finns med på tåget.

Att Intel skulle sänka priset på något är väl ungefär lika troligt som att min katt får vingar och flyger iväg

Deras ställning på marknaden har varit ohotad alldeles för länge för att de skulle paniksäkna några priser i första taget tror jag.