Skrivet av Paddanx:
Men vilket skrivbordsapplikation är så pass segt att du måste köpa en värsting CPU, för att kunna använda det? Och... varför är du då så sabla omodern till att tvinga denna utvecklare att faktiskt koda om den?
MS själva har gjort under med mycket underliggande i Win 8 och 10 vs Win 7, där allt från WU till olika processer under faktiskt kan använda 2+ kärnor. Oavsett om du tar en i7 7700k @ 5Ghz vs en 2600k @4Ghz så kommer 2600k vinna om du kan använda 2 trådar med bara en på 7700k.
Så felet är... stengammal och föråldrad mjukvara, och du försvarar den? Så du vill ha Win XP/7 forever då eller?
Problemet du verkar besatt över är att du vill få det att framstå som att en 5 år gammal CPU knappt kan dra Windows längre. Kan lova dig att en gammal Core2Duo utmärkt kan dra Windows än idag.... Office och webb också.
Men starta ett spel... och du är på knäna direkt.
I de flesta fall fungerar vilken modern x86 som helst för att dra runt skrivbordsapplikationer, att en väldigt stor andel av marknaden allt mer går mot ultratunna bärbara är en stark indikator på det. D.v.s. det man gör går "tillräckligt snabbt" oavsett val av maskin, är då fullt rimligt att prioritera andra saker. Är fullt medveten om detta och har inte någonstans hävdat att man måste ha en värsting CPU för normal användning.
Vad jag hävdar här är främst två saker
gruppen "vanliga" skrivbordsanvändare här än mindre nytta av >4 CPU-kärnor om det medför sämre enkeltrådprestanda då majoriteten av programmen på skrivbordet inte skalar väl
självklart går det att jobba med en Core2 även idag, men t.ex. en sådan sak som den webbaserade Office 356 (för att ta båda dina exempel i en smäll) är märkbart mer responsivt på de senaste CPU-modellerna
Så är kravet: på något sätt hanka sig fram i mina program, alla x86 CPUer (med möjligt undantag för Atom/Jaguar) som lanserats de senaste 10 åren är fortfarande snabba nog (har själv kvar en MBP med 2,4 GHz Core2Duo, den är lite seg trots 8 GB RAM och SSD men visst går den att använda).
Är man ute efter bästa tänkbara respons eller bara vill ha lite guldkant på sitt surfande så är färre starka kärnor > fler svaga. Sannolikheten att det ändras inom överskådlig tid är väldigt nära noll, vissa problem är helt inneboende sekventiella och tyvärr finns det rätt gott om dessa på skrivbordet. Där är låg latens viktigare än total beräkningskraft, låg latens i CPU-fallet betyder hög IPC och hög frekvens.
Skrivet av Paddanx:
Kommer aldrig lägga ner den, då den CPUn är rena definitionen av effektivitet som jag velat se länge. Inte 10Ghz... inte bara 5% IPC, utan en riktig skillnad där man inte måste ha en kokande CPU för att kunna få bra prestanda.
Fast problemet är ju att eDRAM hjälper CPU endast i en väldigt smal nisch, för de flesta program går det exakt lika snabbt vare sig man har eDRAM eller ej. Faktum är att vissa program ser en (marginell) minskning på just Haswell/Broadwell då L4$ tar bort 2 MB L3$, detta är som tur löst i Skylake/Kaby Lake.
eDRAM verkar hjälpa CPU i samma fall där högt klockat RAM hjälper. Enda fördelen nu med eDRAM är att bandbredden mot den är 50-60 GB/s och så högt når man ännu inte med RAM + riktigt snabbt RAM är dyrt (men det är eDRAM också + det handlar om 64-128 MB som är riktigt snabbt).
eDRAM är absolut användbart i vissa lägen, men har själv riktigt svårt att se detta värde utanför låg TDP system som laptops där eDRAM dels ger en rejäl boost till iGPU (som i det läget faktiskt används) men också spar ström och ger viss prestandaboost då läsning/skrivning från eDRAM drar mindre energi jämfört motsvarande mot RAM, så att I/O kan använda eDRAM har fler fördelar än prestanda.
Skrivet av Paddanx:
Jag försöker göra mer än spana... jag försöker trycka på utveckligen där dinosarier som är besatta av IPC och entrådig prestanda sitter med sin gamla CPU och tänker... det var tider det.
Har följt forskningen på området eftersom jag jobbat med att optimera programvara för multicore-system i ~10 år nu. I början var tonen helt: "ok, det är svårt att utnyttja många kärnor men vi kommer på ett språk eller någon metod som fixar det snart".
Idag har man kommit till en insikt som så här i backspegeln man kan tycka borde varit självklart från början, men hur ofta känns inte saker självklara när man väl insett hur det hänger ihop? Huruvida något effektivt kan använda många kärnor beror främst på hur det problem man vill lösa är konstruerat.
Idag är i princip alla program där grundproblemet är "embarrassingly parallel" designade så att de utnyttja CPU-kärnor på ett lysande sätt. Trenden här är ändå bort från CPUer helt och hållet, finns betydligt effektivare sätt att bygga HW för många av dessa problem. GPU är ett typexempel för grafik, olika typer av ASICs för t.ex. bildbehandling är ett annat (används allt mer i mobiler), Intel (Nervana) håller på att bygga en krets specifikt för "machine-learning" (en GPU är OK här, men den innehåller ändå en hel del som är onödigt och man kan nå betydligt högre prestanda per transistor).
Nästa grupp av problem är de som har viss parallellism men där det inte är helt trivialt att få fram den. Här ligger t.ex. spel och de flesta desktop program som ändå drar nytta av flera kärnor. Men i denna grupp finns också hårda begränsningar på hur mycket parallellism som är möjligt att extrahera.
Många algoritmer delar ofta rekursivt upp data i allt mindre delar och slår sedan ihop resultatet, divide-and-conquer. De mindre delarna kan oftast hanteras oberoende av varandra -> går att köra parallellt, problemet är bara att man får en hård begränsning på teoretisk möjlig parallellism som är proportionell mot logaritmen av storleken på indata.
Ovanpå det har man rent empiriskt noterat att den mest effektiva mekanismen för att sprida ut sådan över kärnor (work stealing scheduler) kräver runt en tiopotens i vad som kallas "parallel slackness". D.v.s. om teoretisk maximal parallellism är x100 så kan man förvänta sig en bra skalning till ~10 CPU-kärnor, sedan kommer det rätt snabbt börja plana ut.
Vad allt detta brukar koka ner till är att de storlekar på datamängder man rimligen kommer se på skrivbordet skalar sällan speciellt mycket förbi 2-3 CPU-kärnor. Rätt skrivet ger ett program som utnyttja detta viss skalning till både 6, 8 och kanske fler kärnor. Men om man är så mån om effektivitet som dig borde man riktigt rynka på näsan åt ett program som använder ovan och försöker använda säg 8 kärnor. Vad som inte helt sällan händer är att alla 8 kärnor kommer vara belagda till nära 100 % men det kanske går 10-20 % snabbare jämfört med att göra samma beräkning på 4 kärnor.
Sista gruppen är problem som är inneboende sekventiella. Vissa av dessa kan rent teoretisk innehålla moment som skulle kunna köras parallellt (är ju det som alla superskalära CPU-designer bygger på, d.v.s. att man kör fler än en instruktion per cykel). Men p.g.a. rätt fundamentala fysikaliska begränsningar, som att hastigheten på en signal inte är oändligt hög, går det typiskt långsammare om man börjar blanda in flera CPU-kärnor. Här tittar ändå forskningen på SIMD (SSE/AVX på x86), det är ju en form av parallell körning och man slipper kommunikationskostnaden då alla SIMD-lanes på en viss kärna är på samma ställe som övrig data i den CPU-kärnan (AVX ger ju åtta 32-bitars lanes).
Tittar man på servers kan man konstatera att man i många fall använder liknande algoritmer där som på skrivbordet, så hur skalar det så bra över flera kärnor då? Vad som händer här är att man har massor med oberoende sessioner. Tittar man på hur varje enskild session hanteras är det nästan alltid mest effektivt att köra den som ett enkeltrådat program. Få saker är så effektiva på många kärnor som massor med helt oberoende uppgifter.
Till viss kan man göra motsvarande på skrivbordet, i alla fall på UNIX-system. En van UNIX-användare kommer kombinera flera små program till en "pipe" där utdata från ett steg är indata till nästa steg. I väldigt nära 100 % av fallen är varje enskilt program enkeltrådat men uppgiften kan som helhet ändå använda flera CPU-trådar. I praktiken skalar även detta ytterst sällan speciellt väl förbi två CPU-kärnor (i bemärkelsen, 1->2 kärnor ger en närmast fördubblad prestanda, 2->massor med kärnor ger kanske några 10-tals procent till). Detta beror oftast på att några steg kan inte gå helt parallellt med varandra, i vissa lägen måste man ha tillräckligt eller till och med all data (t.ex. sortering) innan man gå vidare.
Skrivet av Paddanx:
Testa 2 trådar, och återkom med din prestanda.
Jobbar du på ett rimligt sätt så fungerar 8 svagare kärnor också
För det jag dagligen gör, d.v.s. koda, skriva test, bygga, köra test, så är 1 stark kärna ALLTID bättre än flera svaga. Nu är det ett exempel, men det exemplet är långt vanligare än vad som verkar vara uppfattningen här på SweC.
Däremot pushar jag absolut inte för CPUer med en kärna. Övergången från 1->2 kärnor gav en rejäl boost, det då det ofta finns bakgrundsuppgifter och är ju viktigt att få bort dessa från kärnan som utför huvuduppgiften. Även SMT ger en klar boost, framförallt om man bara har två CPU-kärnor. SMT har fördelen att kommunikation mellan CPU-trådar i samma CPU-kärna är väldigt billig + om den ena tråden gör något som "stallar" finns ju massor med resurser som inte gör något utan SMT.
Skrivet av Paddanx:
Yes och nu är vi åter på minoritet frågan igen.
Jag vågar påstå att det utan tvekan finns fler Win XP användare idag, än folk som är så låsta i att de behöver just detta du beskriver ovan, och är så desperat att de tror hela världen måste ha enkeltråd-prestanda pga detta.
Ofta är det pga en mjukvara som är stengammal, eller inte anses viktig nog för att koda om. Men här är en tanke... vad sägs om att koda om mjukvaran du testar med så att den kan använda fler trådar? Det lär ske när ni inser att sista högfrekventa Intel CPUn är kommen, och det är dags att precis som man övergav Ghz kriget, överge IPC kriget, och börja på "parallella kriget" <3
Det svåra här är inte att köpa en CPU som har kraften, utan det är att få gamla hundar att lära sig nya trix... men det kommer det med
Vet inte hur jag ska "bevisa" detta, men är helt hundra på att gruppen som har någon relevant nytta av >4 kärnor på skrivbordet är en långt mindre grupp än de som har en relevant nytta av absolut maximal enkeltrådprestanda på 2/4-kärnig CPU med SMT.
Här kan jag tyvärr bara se till mig själv. Råkar gilla att mäta saker och har tillgång till en väldigt stor mängd olika datorsystem med kraftigt varierande antal CPU-kärnor. För majoriteten av vad jag gör är t.ex. i7-7660U (4,0 GHz max turbo, 2 kärnor, speedshift, eDRAM det med 15 W TDP) snabbare än 2x Xeon E5 2699v4 (3,6 GHz max turbo, totalt 44 CPU-kärnor, ingen speedshift och 2x 145 W TDP).
Däremot är sen senare ett långt bättre val till de system jag utvecklar programvara för, men det är inte riktigt desktopanvändning... För de som absolut måste rendera på CPU är den senare snabbare, men lägger man i stället det jobbet på en GPU så får det systemet stryk av GTX 1060 (vilket ger en vink hur enormt mycket bättre prestanda man kan få i vissa fall med en krets som är specialdesignad för ett smalt område).
Så handlar inte om stengammal programvara. Det handlar främst om egenskaperna hos det problem man vill lösa. Här har spel en lite speciell ställning, det är inte helt fixerat problem då det handlar om simulering av något helt fiktivt. Dagens speldesign kommer aldrig skala superbra till speciellt många CPU-kärnor (är inte i närheten linjärt ens till 4 kärnor), men fullt möjligt att man kan komma på nya typer av spel där grundproblemet (t.ex. superavancerad AI) lämpar sig riktigt väl att köra på många CPU-kärnor.
Men för oss som inte spelar utan försöker lösa problem som på något sätt bottnar i fysiska ting får man nog acceptera att om problemet råkar vara sekventiellt eller ha begränsad parallellism så kommer det aldrig gå att skala speciellt väl över CPU-kärnor. Det kommer dock alltid skala perfekt med högre IPC * frekvens produkt.
