Skrivet av sAAb:
Jag har varken citerat Core Mark eller Pass Mark som också nämts av andra.
Vi har diskuterat vad som är majoritet tidigare, men, hamnade inte i konsensus vad jag kommer ihåg.
Det förändrar inte att en stor del av de heltalstunga applikationerna (programmen) faktiskt är behovsmättade. Vi "behöver" inte snabbare Word, för att ge ett tydligt exempel. Vår fingerfärdighet är begränsningen och man vinner inte något på "majoriteten" av program. Man gör inte det.
Däremot finns det specialprogram som vinner på det, t.ex. Photoshop. Ser man på ett tungt Photoshop-arbete ("tungt" eller heavy enligt tomshardware.com) så vinner man uppemot 0,2 sekunder.
http://media.bestofmicro.com/O/J/585379/original/pcm8-photoshop-heavy.png
På enklare utföranden vinner man enligt samma studie kanske 0,02 sekunder, vilket är försumbart oavsett hur mycket man arbetar med Photoshop per dag. En kopp kaffe, en fikapaus, ett toalettbesök gör eventuell vinst ogjord. Effektstorleken på skillnaderna är försumbara, vilket du vet. Det är inte inom "felmarginalen" som tidigare påståtts, men i princip försumbart.
Jag kan inte komma ihåg att du gett något exempel på kritisk effektstorlek när det gäller "prestanda i heltalstunga program som inte är vektoriserade och där bara en tråd per CPU-kärna används".
Spel är ett exempel där det finns en balansgång mellan heltalsprestanda och flertrådat, oavsett om det är flyttal (double eller idag orimliga long double) eller heltal (integer); vi sitter i en brytpunkt där mer server-liknande processor vinner allt fler tester.
Du har har synnerligen rätt i att det går skriva program som använder fler kärnor innan alla kärnor är aktiva på sin första tråd. En av tänkbara metoder vore en schemaläggningsalgoritm där man tillåter det; det finns flera att leka med och de har olika prestanda under olika fall.
Civilization är ju en serie där man skulle kunna ha använt schemaläggningsalgoritmer som utnyttjar flera CPUer med fördel; nu har man ju minskat storleken på kartoerna i stället, kanske för att undvika att AI blir svältfödd på tillgängliga fyra hårdvarutrådar. Här är kartstorlekarna enligt https://steamcommunity.com/app/289070/discussions/0/350540780...
Storlek | Civ V | Civ VI |
|---|
Dual | 40x24 | 44x26 |
Tiny | 55x36 | 60x36 |
Small | 66x42 | 74x46 |
Standard | 80x52 | 84x54 |
Large | 104x64 | 96x60 |
Huge | 128x80 | 106x66 |
Men, vi har ju diskuterat även det.
Notera att det är en skillnad på "enkeltrådprestanda" och "prestanda för applikationer som bara kör på en enda tråd". Det är hela tiden den förra jag pekat på är kritiskt.
Men finns faktiskt en hel del saker i den senare gruppen som är prestandakritiskt än idag
saker där flaskhalsen är I/O, ju mindre tid man lägger i CPU-delen för att mata in nästa jobb, ju närmare 100 % av sin kapacitet kommer I/O utföras. Tiden som spenderas på CPU-delen här skalar med enkeltrådprestanda, men det har inte helt sällan noll eller svagt negativ skalning med fler kärnor (går att undvika genom att låta bli att slänga fler kärnor på problemet, så bara det faktum att man har många kärnor är i sig inte dåligt)
webben. Allt fler applikationer körs i webbläsare. Vad som är möjligt att göra i en webbläsare har ökat enormt de senaste åren och det märks i hur pass komplicerade webbbaserade applikationer som nu finns. Dessa applikationer skrivs i JavaScript som i skrivande stund är helt enkeltrådat (finns hack/trick för att sprida ut JS program över flera CPU-kärnor, men används inte jättemycket)
Respons i interaktiva applikationer. Detta är var Core M och dagens mobila CPUer är helt designade kring, d.v.s. arbetslast där användaren ger någon form av input och förväntar sig "omedelbar" respons. Tidsspannet här är på millisekundskala (upp till som värst låga 100-tals millisekunder), kan låta irrelevant men är tvärt om kritiskt för att man inte ska uppleva "lagg" i sin användarupplevelse. Bästa exemplet här är: Iphone med sina två väldigt starka kärnor totalt demolerar konkurrenterna som har både fyra och åtta kärnor, det senare vinner benchmarks det förra ger en överlägsen användarupplevelse
Personligen har jag väldigt många fall i just det sista segmentet. Sökningar på lokala datorn, inkrementell kompilering och test vid programutveckling, halvstora beräkningar (för små för att man ska orka lägga krut på att göra det parallellt, för stora för att de ska hända omedelbart).
Men är som sagt inte det jag främst pekar på. Vad jag säger är att den bästa CPU-design för skrivbordet är normalt den som har högsta prestanda per CPU-kärna, om det sedan är två, fyra, sex eller åtta kärnor är sekundärt. OBS, sekundärt, inte irrelevant. Så allt annat lika är det självklart bättre med åtta kärnor än fyra, men fram till nu har fler än fyra kärnor medfört en allt för stor minskning av enkeltrådprestanda.
I praktiken har därför de högst klockade fyrkärninga modellerna gett bäst upplevelse för den stora massan. Man kan nog ta en viss försämring av enkeltrådprestanda för att få fler kärnor, men hamnar minskning över 15-25 % för att gå från fyra kärnor till åtta så kommer man i praktiken få ett långsammare system.
Angående "prestanda i heltalstunga program som inte är vektoriserade och där bara en tråd per CPU-kärna används" så var det i kontext av CPUer med relativt många kärnor, idag sex till tio stycken. För i praktiken alla dagens spel gäller detta, det finns en viss skalning över fyra CPU-trådar i vissa spel men undantaget Civ och AoS lär det knappast finnas en vinst bortom sex CPU-trådar (som inte är en slump, sex CPU-trådar är vad spelmotorer är optimerade för då det är så många kärnor som dagens konsolspel använder).
Då spel och andra applikationer som inte trivialt parallelliserbara kräver kommunikation mellan CPU-kärnor så är SMT väldigt effektivt. För spel ligger i5-7600K i de flesta fall närmare i3-7350K (båda har fyra CPU-trådar) än i7-7700K, för saker som skalar perfekt med kärnor ligger i5-7600K klart närmare i7-7700K.
Tittar man på saker som skalar perfekt med CPU-kärnor finns ju lite olika klasser
stora dataparallella problem, ett exempel är Blender. Här är ju "problemet" att GPUer är specialdesignade för detta, så varför köra detta på en CPU?
medelstora dataparallella problem, typexempel är det som ofta körs Matlab, Matematica och till viss del i Excel. Här blir kommunikationslatensen en för stor flaskhals för att köra på GPU (potentiellt möjligt för vissa av dessa att i framtiden köras på iGPU dock), detta är domänen där SSE/AVX/FMA skiner och på denna punkt är Haswell och framåt dubbelt så stark som Zen per kärna och cykel
den största och nog viktigaste gruppen är uppgiftsparallella problem, finns inte jättemycket exempel på skrivbordet men det kryllar av dessa på servers. Här är icke-vektoriserad heltalsprestanda kung och det är absolut en fördel med många CPU-kärnor, i de flesta fall även om fler kärnor medför lägre prestanda per kärna
I grunden gäller alltid att en CPU-tråd med kapacitet 2C kommer alltid att att utföra uppgifter lika snabbt eller snabbare än två CPU-trådar med kapacitet 1C. I praktiken ligger servervärlden närmare "lika snabbt" medan desktopvärlden tenderar att kraft väga över mot "eller snabbare".
Skrivet av Enigma:
Som Yoshman skriver så är en del av det mest coola namn av marknadsföringsskäl som redan existerar i Intel's Core funktionsmässigt. Dock inte allt!
Intel's arkitekturer från Sandu Bridge till dagens Kaby Lake har sina tråkiga linjära likheter, men också klara skillnader prestandamässigt, men kanske man inte borde bortse helt från dom nyheter som plattformarna fått genom åren heller. Skrev lite mer om det nedan i svaret till Yoshman:
Både ja och nej, i dom flesta fall (dvs för dom flesta användare och dom vanligaste applikationer) så är hoppet från Sandy>Ivy>Haswell>Broadwell>Skylake relativt jämt. Samtidigt har dom större skillnader i en del normala fall där Haswell gjorde det större klivet, och där Broadwell tack vare sin e-DRAM gav en jäkla skjuts i CPU-intensiva spel per klockcykel.
Skylake är också tvärtemot det du säger ett ganska stort lyft när vi pratar CPU-intensiva spel om man tittar på min-fps:
https://www.youtube.com/watch?v=4sx1kLGVAF0
Mest anmärkningsvärt är att man spridit ut dessa "upp till 30% bättre prestanda" på hela 5 så kallade "generationer" där den sistnämnda Kaby Lake knappast är en ny generation om man pratar om förändringar i arkitekturen. Zen's kommande efterträdare lär däremot öka IPC betydligt snabbare än vad Core gjort där man säger att den första iterationen av Zen (Zen+) skall ha 15% högre IPC, och att vi ska få se Zen++ och Zen+++ med liknande ökningar. Anmärkningsvärt här också är att alla kommande efterträdare ska fungera på samma AM4 plattform (fram till man går över till DDR5) också utan att byta moderkort efter varje liten CPU-gen som Intel gjort, bara för att mjölka pengar på sina kunder.
Kul fakta: När AMD socketen och monteringslösningen för AM4 så gav dom sken över att dom var "ledsna över" att dom var tvungna att byta plats på hålen några millimeter, detta på grund av att Socket'en ökat i pins och fler ledningsbanor behövde nå fram. Intel är rädda för att göra större förändringar, och det är faktiskt en av anledningarna till att man stannat upp utvecklingen rent prestandamässigt.
AMD tog en mycket stor risk med en ny arkitektur på en ny tillverkningsprocess och verkar ha lyckats, nu är det fritt fram att göra desto större förändringar i arkitekturen, där Intel mjölkat ur så mycket det går ur Core. Därför påstår jag samtidigt att Zen kommer öka i IPC mer. Om det slutar med att den spöar Core i IPC i slutändan eller ej får vi se, men den kan också ha en stor potential att köra över den med frekvens, speciellt om AMD kommer lyckas på 7nm, där Intel har stora problem och förseningar med 10nm.
Laptop SKU's bygger på exakt samma grund som desktop SKU's som är nerklockade och binnade för att köras på låg spänning med lägre programmerad TDP. Oavsett om dom kliver över TDP på den så är knappast kislets gräns någon giltig faktor här, utan den uteslutande gränsen här är med hänsyn till driftslängd som är vitalt på en laptop/batteridriven enhet. Skillnaden är att XFR sträcker sig över vad arkitekturen normalt som högst specificerats för med hjälp av sensorer utplacerade i hela kislet i princip varenda enhet vilket är en förbättring av AVFS som i sin tur är en förbättring utav DVFS.
AMD tog patent på en ny typ av mycket responsiv och minimalistisk termisk oscillator som förmodligen används i Zen ihop med SenseMI och Precision Boost. Det hela är betydligt mer likt funktionen "GPU-boost" som du tyckte var en befängd jämförelse. Jag hade inte sett någon annan göra den liknelsen när jag gjorde det men numera är det så många andra också tolkar funktionen, och nu senast SweClockers fredagspanel. Här var mitt första inlägg om detta till dig:
#16562691
http://www.relaxedtech.com/reviews/amd/athlon-x4-845/amd-excavator-l1.jpg
http://images.anandtech.com/doci/10907/AMD%20Zen%20December%202016%20Update_Final%20For%20Distribution-page-015.jpg?_ga=1.126655181.155802493.1485354906
http://images.anandtech.com/doci/10907/AMD%20Zen%20December%202016%20Update_Final%20For%20Distribution-page-016.jpg?_ga=1.126655181.155802493.1485354906
http://images.anandtech.com/doci/10907/AMD%20Zen%20December%202016%20Update_Final%20For%20Distribution-page-017.jpg?_ga=1.163886463.155802493.1485354906
Fast du vrider du helt på vad "befängt" faktiskt refererar till. Du får det att låta som om jag tyckte det var befängt att XFR fungerar som boost hos GPUer. Det var inte alls vad ordet syftade på, något som borde vara uppenbart om du tagit med raderna under den du citerade.
"Och du tror att Nvidias GPUer någonsin kliver förbi en frekvens de själva aldrig testat kretsen med i standardläge? Jag är så nära 100 % säker man kan vara utan att ha förstahandsinformation att så inte är fallet på Maxwell och Pascal i alla fall, det finns en hård maxfrekvens även om den inte är explicit specificerad (och för i alla fall Maxwell är det samma maxfrekvens på alla kort av en viss modell)."
D.v.s. "befängt" refererar till att det på något sätt skulle vara möjligt för GPUer (och XFR som du anser fungerar på liknande sätt) i det att högsta frekvens bara begränsas av kyleffekten.
Även om man kyler en GPU med flytande kväve så kommer den inte klocka sig högre än vad den gör med en eftermarknadskylare (pratar bara fallet utan överklockning). Orsaken är att tillverkaren bara validerat kretsen upp till en viss maximal frekvens och över den frekvensen har man ingen aning vad som händer.
Så enda tekniska skillnaden då mellan XFR/GPU-boost och boost i CPUer är att de senare listar den maximala frekvensen medan Nvidia listar en "förväntad genomsnittlig boost-frekvens" (AMD listar maxfrekvens för sina GPUer, så exakt samma som för CPUer). I Nvidias GPUer och i kommande Zen finns en hård maximal frekvens, den står bara inte i produkbladet.
Nu kan Zen mycket väl ha sensorer som reagerar snabbare, men är det ingen fundamental skillnad i funktion mot Core M och GPUer som också har sensorer som registrerar temperatur och strömuttag kontinuerligt.
Om det är responstiden som är magin i XFR är det rätt analogt med speed-shift. D.v.s. man gör exakt samma sak som gjorts tidigare, men med lägre responstider kan man ligga mycket närmare den absoluta gränsen för vad som är möjligt.
