Uppgradering från AMD till Intel

Ville bara inflika att jag just bytt upp mig från AMD 7850K och 1866mhz DDR3 till Intel 6700K, ASUS Z170 Pro gaming och 2400mhz DDR4.

Blev en rejäl skillnad i spel, alla störiga smålagg är som bortblåst. Körde bägge setuperna med ett MSi GTX980 4gb. Spelar mest typ GTA V,Tomb raider etc etc. Mycket högre fps i alla spel jag testat än så länge.

Jämförde i 3DMarks physics test där AMD:n orkade upp i ca 15fps, 6700k orkar ca 55fps. Så det är enorm skillnad i processorkraft

Fast när utgångspunkten är FX-8320 så kvittar det, i5-6600K är snabbare oavsett vad man gör.

Om man har två CPUer, en som utför X per kärna och med hälften så många kärnor som utför 2X per kärna så kommer den senare alltid vara minst lika snabb som den förra.

Finns i praktiken aldrig något fall där två kärnor med halva kapaciteten av en stark kärna är snabbare. Så finns helt enkelt inget fall där en FX-8320 är ett bättre val än en i5-6600K då den förra aldrig kommer vara snabbare. FX-8320 kan i de mest gynsamma fallen prestera bättre än i5-2500K och i5-3570K, men den rår inte på de snabbaste i5:orna från Haswell och framåt.

Det skrivet: finns ändå en stor anledning att välja i7-6700K över i5-6600K. HyperThreading har aldrig gett så mycket för "Core" serien som det ger i Skylake, så skillnaden mellan i5 och i7 har aldrig varit större.

Windows, Linux och OSX är alla operativsystem med s.k. preemptive multitasking. Har man då 4 CPU-trådar där varje tråd presterar dubbelt så bra som en annan CPU med 8 CPU-trådar så får man i normalfallet minst lika bra prestanda på systemet med få starka kärnor.

Gör man många saker som alla är begränsade av "throughput" kommer aldrig CPUn med åtta svaga kärnor prestera bättre, den kan som bäst prestera lika bra vilket blir fallet om det som händer på trådarna är helt oberoende av varandra.

Någon kanske tänker: men kontext-switchar kostar! Det är sant, men de är relativt billiga på x86 och de är väldigt billiga jämfört med effekter som cache-line-bouncing och cache-trashing vilket kommer vara sannolikare på en CPU där kärnor gör helt orelaterade saker som då inte alls delar "working-set".

Enda undantaget jag kan komma på för när 4 starka CPU-trådar kan ge en sämre upplevd prestanda är om det som ligger i förgrunden behöver uppdateras oftare än ungefär halva tiden OSet har för en "time-slice". I fallet Windows görs det en del "fulhack" för att ge det som har input-fokus (vilket kommer vara spelet i detta fall) extra CPU-tid och i praktiken verkar svarstiden för det som ligger i förgrunden vara max 5 ms (mer normalt 2 ms, d.v.s två klockperioder då Windows har timerticks på 1000 Hz).

D.v.s. så länge spel håller sig en bit under 100 FPS kommer det allt hinna få "sin" del av CPUn varje frame, vilket betyder att en CPU med 4 CPU-trådar ger samma upplevelse som en CPU med 8 CPU-trådar fast med halva prestanda per tråd.

Det förutsätter också att både spelet och det som går i bakgrunden vill ha 100 % av CPUn. Om spelet drar mindre än 100 % av "sin" kommer alla tre OSen direkt avbryta det som ligger i bakgrunden så fort spelet vill ha CPUn.

Jobbade specifikt med analys och design av programvara för multicore-system under flera år. Jobbade med allt från få starka kärnor (typiskt Intel Xeons) till hyfsat med svaga kärnor (ARM/MIPS) till massivt antal kärnor/trådar (nätverksprocessorer). Du kanske har mer erfarenhet än så, men är helt grön även på det praktiska.

En rolig del av detta var när en av mina designer, då helt teoretisk, kring hur man kan utnyttja två trådar som tillhör samma kärna på sätt som normalt inte är möjligt p.g.a. cache-effekter (trådar i samma kärna delar L1 så de har inte det problemet). Tog upp detta med ett av Intels arkitek-team, de sågade idén totalt med motiveringen: "det kommer inte fungera för det är inte så vi tänkt att man ska använda HT". Tog ett par veckor att knacka ihop det hela rent praktiskt, Intel-arkitekterna var inte helt nöjda med att bli bevisade att ha fel om sin "egen" arkitektur... Till deras försvar kan sägas att de är experter på HW, inte programvara och tog t.ex. Qualcomms och AMDs ingenjörer ett tag att fatta att man kommer aldrig lura ut hur många kärnor kan användas i interaktiva program, många svagare kärnor är helt enkelt värdelöst när problemet är begränsat av latens.

Men för att hålla det konkret, kan du beskriva ungefär användarfallet du såg en FX-8350 hantera bättre än i5-4670K.

Detta är internet, t.ex. så såg folk såg ju alla möjliga problem efter att 3,5+0,5 uppdelningen i 970 blev känd. Trots det lyckades inte en enda teknikwebbplats göra ett reproducerbart test som kunde påvisa något problem överhuvudtaget.

Och just in detta fall känns det än mer udda när man ser resultat som detta. Här kör man först mplayer samtidigt som 7-zip, den senare använder alla tillgängliga CPU-trådar. Notera att till och med en i3-4130 är snabbare på detta än FX-8350 i stock clock.

Det än mer intressanta är vad som händer när man också lägger på gimp (typiskt CPU-intensivt på en tråd) och handbrake (kan typiskt använda många CPU-trådar). I detta fall ökar fördelen för i3-4130, vilket är precis vad min teori ovan skulle visa och det är något jag sett massor med gånger när jag jobbade med detta. FX-8350 blir ju demolerad av i5-4670K i dett fall, det trots att detta fall kan använda även mer än 8 CPU-trådar.

OBS: säger inte att du har fel, är däremot genuint intresserad av det fall du såg resultatet du nämner för det är ett resultat jag aldrig sett i verkligheten och skulle vara intressant att kunna förklara.

Förklaringen för 5775C är ju uppenbarligen att spel gillar mycket cache. Det är en effekt man också ser hos Intels E-serie (för spel har ingen nytta av 8-10 kärnor). Det ingen riktigt har en bra förklaring till där är varför det bara verkar vara spel som ser någon effekt av L4-cachen, för princip allt annat har L4-cachen noll effekt. Är nog bara spelutvecklarna och/eller grafikkortsdrivar-utvecklarna som kan svara på det.

Dock räckte det med att öka FCLK från 800 MHz (som var värdet i tidiga moderkort) till 1 GHz för att 6700K konsekvent ska slå 5775C även i spel.

Som sagt, med teorin du säger, borde det vara bättre med 6600k varje dag, varje gång, men jag kan inte förklara det vi observera på annat sätt.
Nu var detta ett tag sedan, men av vad jag minns så var det så här:

En vän till mig satt på en 8350 och ville (precis som TS) köpa en Intel istället, så vi byggde ihop en vettig maskin med det. Han bytte GPU samtidigt, men behöll minnet (han hade 16GB 1600Mhz då han körde VM mm så fanns inget behov att byta). CPUn var då en ny 4670k (var när Haswell hade kommit), GPUn var ett GTX 680 han hade hittat på rea.

När vi satte ihop maskinen och testade spel mm så fungerade allt kanon. Spelen flöt på bra och han var nöjd. Prestandan var exakt som du länkat... bättre än med hans gamla CPU, (men svårt att avgöra till 100% så klart pga nytt GPU också)

Men några dagar senare prata han med mig och undrade om jag kunde titta på ett udda problem han hade. Han kör nämligen ibland en VM (som då förr var låst till 2kärnor) till olika test projekt, och om han körde detta (som inte direkt var hård last, men ibland kunde komma spika av last) så kände han direkt lagget i spelen (vill minnas det var Battlefield som var en av dem). Samma sak när han körde fraps för att spela in, så fick han rätt stora problem att hålla vettig prestanda, och när man tittade på CPU lasten så såg man att den var i taket rätt ofta. Notera att snitt FPS var inte så dålig, men man kände lagget, så fps dropps var klart märkbara.

Så efter en rätt intensiv felsökning för allt från Virus till drivare, temp osv, så beslöt vi oss att testa nya sakerna på gamla moderkortet med AMD CPUn. Resultatet vi fann var att om du körde bara spelet så var prestandan sämre (pga klenare CPU trådar så klart), men han kunde ha VM eller fraps igång utan att det störde. Detta verkade vara då spelet inte tog de andra trådarna som satt IDLE, som nu VM eller fraps kunde använda. Spelet mao trycktes ner i prestanda pga den inte kunde använda alla trådarna, och lämnade denna till annat. (Den slutsatsen vi drog efter rätt många timmars pillande och jag vet... ironiskt nog så är 8350 sämre optimering av 8 trådar det som verkade göra nytta här, då spelet inte kunde använda allt).

Lösning var att helt enkelt byta till en 4770k, vilket löste alla problem (vilket det också borde göra för TS). Nu fick han bättre spelprestanda, men hade nog med kraft kvar att köra de andra sakerna vid sidan om, utan att ändra något annat.
Liknande sak har jag faktiskt märkt mellan min 2600k och en 4670k jag hade ett tag (är nu en 4790k dock pga det).

Om du har en annan förklaring till detta, så snälla kom med den, för jag hitta ingen annan efter rätt mycket testande.

Med det sagt... Skylake har bättre cachehantering och bättre optimeringar, så kanske den hade klarat detta bättre. Det vet jag inte. Men i detta fallet så räckte inte i5ans prestanda, då spelet helt enkelt verkade äta så mycket av det att där inte fanns något kvar till det andra.

Just det är min poäng. Att teorin och praktik ibland inte ger vettiga förklaringar. Och du om någon vet mycket av teorin bakom, men jag kan omöjligt tro att du inte hamnat i situationer efter X antal år med datorer och elektronik där logik och teori inte fungerar. (För efter 20+ år har jag flertalet gånger iaf)

Men det är ju trevligt att en OC av 6700 BCLK gör att den kan slå en 0,5Ghz långsammare, svalare CPU
Tror dock hellre jag avstår från den än... med tanke på att jag bara denna veckan svarat i 3 trådar med problem om Skylake och minnesproblem/instabilitet. De är äckligt instabila om man inte tar exakt rätt delar och BIOS... (eller har tur).

Fallet du beskriver är en variant av det jag ovan beskrev som det enda fall där det ens teoretiskt kan bli bättre fler CPU-trådar.

Det man ska ha klart för sig att det är ett extremt specialfall och finns minst två uppenbara sätt att komma runt det. Detta var också ett fall jag testade innan mitt andra svar postades, kunde bara få fram ungefär det som beskrivs när saker kördes i bakgrunden med två kärnor + två trådar per kärna aktiva (testade både Linux i en VM med lite saker igång samt Cinebench).

En förutsättning för att man överhuvudtaget ska kunna trigga detta är att spelet måste bli CPU-bundet. Normalfallet för PC-spel är att de inte ens är CPU-bundna med i3 parade med Titan X Pascal om man kör med någorlunda vettiga grafikinställningar. BF i multiplayer sägs ändå vara rätt CPU-intensivt (kan inte testa då jag bara har BF3 och 4 på konsol).

Hur fixa problemet då?

Det kanske mest uppenbara är nog: varför kör man saker i bakgrunden när man spelar om man bryr sig om låg varians? Men visst, kanske är så att det är en total omöjlighet att köra det på en annan maskin.

Du nämner att genomsnittlig FPS inte var ett problem, utan det var FPS-variansen. Hög FPS-varians är absolut ett problem, att konsoler ger en så upplevelse i de flesta fall trots låg genomsnittlig FPS är just att man tenderar ha väldigt låg varians. Enda anledningen att det inte skulle vara ett problem på FX-8350 är i så fall att ett sådant system får konsekvent låg FPS. Så lösningen med i5 är då helt enkelt att köra med vsync på, i det läget blir spelet garanterat inte CPU-bundet och då spelet inte heller använder CPUn 100 % av tiden kommer Windows skruva upp den dynamiska delen av processprioriteten så att spelet snabbare får tillgång till CPUn vid behov.

Vilket leder till det tredje, kanske lite mindre självklara sättet: sänk prioriteten på processen för VM:en. Det ser till att spelprocessen snabbare får tillgång till CPUn när det behövs.

De problem ni såg måste även finnas med FX-8350 och med i7 då dessa modeller faktiskt bara har fyra oberoende kärnor precis som desktop i5. Det faktum att de ändå har 8 CPU-trådar leder ändå till att man inte kan fixa eventuella problem genom att göra saker som ändrar relativ processprioritet i fall där spelet inte använder alla CPU-trådar. Ur Windows synvinkel finns ju då lediga CPU-trådar och oavsett hur lång prioritet en bakgrundsprocess har kommer den då får köra.

Påverkan på en i7 är då att enkeltrådprestanda sjunker från typiskt 60 % av prestanda när bara en CPU-tråd används medan en CPU-med Bulldozer-modul sjunker till ungefär 80 %.

Så säger inte att det inte finns fall, vad jag vände mig mot är detta:

"Det är Intels lilla förbarmelse, att de kan göra jävligt snabba och effektiva CPUer, så länge du inte behöver mer än 4 trådar. När du behöver mer än det så blir det dyrt som F (6700k/6800k osv), eller så får du problem."

Eller är egentligen inte det som står där som jag har en invändning mot, är det som inte står. D.v.s. de fall när man får problem är extremt udda och ovanliga fall, så för 999 av 1000 personer är det överhuvudtaget inget att bry sig i.

Och man kan också vända på det, går absolut att skapa specifika fall där man låser bakgrundsprocesser till specifika CPU-trådar, den "andra" tråden i en CPU/modul, som kommer skapa precis lika stora problem på i7 och FX-83xx.

TL;DR
Min poäng är främst, i extremt nära 100 % av fallen kommer en i5 vara bättre än FX-83xx. I de extremt sällsynta fall där FX-83xx är "bättre" är den det genom att vara konsekvent långsam
Invändningen jag har är att försöka kalla detta för ett problem (vilket är vad du skrev i det jag först svarade på).

1,0 GHz BCLK är den frekvens som Skylake designades för, var 800 MHz de första veckorna (då alla tester gjordes) och som jag förstått det korrigerades via en BIOS-uppdatering. Så ingen OC. Däremot räckte enbart den lilla förändringen för att 6700K skulle ta sig förbi 5775C i spel.

Vidare tror jag inte BCLK är största orsaken till att Skylake dragit ifrån. Förklaringen här ligger nog i att DDR4 var väldigt omoget förra året, alla tester utfördes med DDR4 2166 alt. lite högre bandbredd med hög latens. Idag finns DDR4 med både lägre latens och med högre bandbredd.

Normalt sett spelar bandbredd för RAM väldigt liten roll utanför iGPU. Men vissa spel visade sig få en positiv boost inte bara av L4 utan även av snabbare DDR4, då främst på i3 (tror Eurogamer har haft en del artiklar kring detta). Varför just på i3 och specifikt på i3-61xx? i3-61xx har endast 3 MB L3-cache, i3-63xx har 4 MB och i5/i7 har 6/8 MB.

Vissa spel (långt ifrån alla spel ser en positivt effekt av L4$) verkar vara en av de få saker man kör på skrivbordet som har ett "working-set" större än L3. Problemet med L4$ är att bandbredden inte är jättehög (60-70 % högre än DDR3 1600, dock är L4$ s.k. dual-ported så man kan läsa och skriva samtidigt i full hastighet, inte speciellt användbart för en CPU men väldigt användbart för en GPU) och framförallt är latensen betydligt högre än L3$, den är ungefär 75 % av latens mot RAM! (latens är i stort ett icke-problem för GPU, det är kritiskt för CPU).

Så de fall där L4-cachen faktiskt hjälper är samma fall där även DDR4 med hög bandbredd hjälper. Något som syns i hur 6700K och 5775C står relativt varandra numera (här kör 6700k med DDR4 2666, notera att i3-6100 är konsekvent snabbare än FX-9590 i spel med dessa minnen).

Men det är ju en skillnad i klockfrekvens! Här finns ett par spel-tester med 5775C @ 4,2 GHz mot bl.a. 6700K @ 4,2 GHz. Den senare är i genomsnitt ändå snabbare idag.

Hade jag gjort valet idag av CPU för kompakt bygge hade valet inte hamnat på 5775C (det var vettigt vid den här tiden förra året), i7-6700 (utan "k") har också 65 W TDP och är både billigare samt i genomsnitt snabbare än 5775C med rätt val av minnen.

Och att inte kunna förklara. Jag kan inte förklara varför L4-cachen har en effekt i vissa spel. Det betyder inte att ingen kan göra en sådan förklaring. Rätt säker att jag skulle kunna helt förklara fenomenet om jag hade tillgång till källkoden till spelen samt drivarna. Med detta samt lite instrumentering kan man helt lägga fast hur "working-set" ser ut och med källkoden kan man då exakt räkna ut dess storlek för varje givet fall. Rimligtvis blir svaret att det finns en del av "working-set" som inte används super ofta, men som är väsentligt mycket större än L3 men mindre än L4.

En rätt rimlig gissning är att detta handlar om informationen kring "draw-calls" som alla moderna drivers "spelar in" i RAM upp till någon punkt när man skicka allt i en smäll till GPUn. Är just detta som är helt explicit i DX12/Vulkan, men även DX11 gör detta "under huven" och exakt hur detta görs för ett specifikt spel är typiskt vad man justerar i drivers som har specialoptimeringar för vissa titlar.

Precis sådana här beräkningar gjorde jag, fast då på antal samtida sessioner/strömmar genom routers/deep-packet-inspection-boxar. Gick med detta är med otrolig noggrannhet förutsäga hur många sessioner/strömmar man kunde hantera innan började ramla ur en viss nivå cache och därmed fick en klar minskning i kapacitet per tidsenhet.

Teori och praktik stämmer i praktiken alltid bara teorin är baserad på en korrekt modell av verkligheten!