Intels arkitektur "Ice Lake" på 10 nanometer hittar ut på Geekbench

Shit vad glömsk jag är, men vad hette 5XXX-serien som släpptes på våren strax innan Skylake? Hade inte den massor med cache?

Menar du broadwell med grafiklösningen?

Du tänker på 5775c och 5765c Broadwell, som var samma cache som dessa ovan, men de hade ett L4/sDRAM på 128MB också, vilket med tex DX11 får CPUn att få satans jämn och bra prestanda, trots ynka 1600Mhz RAM stöd och stock frekvens på 3,5Ghz

Är en underbar CPU btw i 4-4.2Ghz med den cachen

Jaaaa, nu vaknade en del hjärnceller som låst in sig i arkivet.

Vi säger att informationen låg långt ner i en hårddisk... tog tid för systemet att söka upp informationen

Ja du... går du till laptop så har du 2-core i7or, så varför inte?

Skillnaden mellan tex i5 8350u och i7 8550u är typ frekvensen, och 2MB cache.

Och pentium har ju blivit i3... i3 blivit i5.. och i5 blivit i7... och i7 blivit i9, och vi alla som köpt CPUer har blivit blåsta på pengar på ett eller annat sätt för samma mängd cache i nästan 10 år

Hmm, hade för mig 9600 var 8600 re-branded.

Att Intel gick från stor L2 till liten L2 + L3 berodde primärt på att de ville ha ner latency till L2. Den gick från 14 cykler ner till 10, vilket Intel tyckte var värt att den blev mindre (och de simulerade säkert saken ordentligt). Dessutom var det bra att det blev mindre snoop-trafik till varje kärnad L2, eftersom en inklusiv L3 kunde hantera detta.

Om du läser detaljerna om nyare processorer, ser du att latencyn krupit upp igen, och är (om jag minns rätt) uppe på 12 cykler igen. Detta kan bero på att Intel sparar energi i L2, men också på att designen nu är mer förlåtande iom att Skylake-X kan ha en mycket större L2. Skall man ändå ha en 12-cykels latency, kan man ju utnyttja att den kan bli lite större.

Sen finns det en allmän trend att alla cachar växer just nu. Zen har vi ju i artikeln, och Apples cache har vuxit för varje generation det senaste. I A12 är det ensligt Anandtech 128KB i både L1D och L1I. Uppenbarligen finns det prestanda att tjäna och energi att spara där.

Skickades från m.sweclockers.com

Om just cache-system är Wikipedia helt OK:

https://en.wikipedia.org/wiki/CPU_cache#Address_translation

Den typen av cache som han talar om här kallas för VIPT.

Är en bra fråga. Förr trodde jag 7600k var 8350k, men det kan inte stämma helt pga 8MB Cachen. Så den verkar vara någon mellanväg mellan 7700k och 7600k. Dessa är ju samma processor, men med saker avstängda eller inte.

Om du kan hålla samma latens och öka storleken... självklart gör det. Men frågan kommer ju om det var L3 i sig, eller minskningen av L2 som gjorde prestandavinsten. Mao... är 12->14 cykler, när man jämför 3-4Ghz så mycket förlust mot att göra en cache miss pga den var för liten att hålla det man behövde. Skulle tro att där är en fin balans att gå där, och det hänger mer på vad du beräknar, hur bra du kan förutspå data hämtningen (något som spectre/meltdown lär ha skadat en hel del) och hur designen av de omgivande L1 och L3 ser ut.

Jag har mao svårt att tro att en dubblering av L2 inte kommer ha en markant påverkan på både priset på CPUn, samt latensen på data i den. Men om det görs måste ju uppoffringarna som görs vara värda detta. Och som man kan se när man tittar på bara snabbare RAM latens påverkar dagens CPUer så vet jag inte... där kan du tjäna mycket på att få ner 1ns latens i rätt miljö.

Har dock svårt att tro det är energieffektivt... för minne äter ström. Dessa kretsar måste vara igång 100% när kärnan är igång. Och ska du starta upp och stänga av dem från IDLE, måste de antingen vara igång (med data redo), eller stängas av och sedan fyllas igen (vilket också tar resurser). Så det blir väl en fråga om du kan få upp effektiviteten på hela CPUn för att vinna det tillbaka.

Att dagens CPUer tvingas tömma cachen hela tiden pga dessa buggar har kanske ändrat förutsättningen för hur den mer effektiva nivån är?

Det är ju inte "en" CPU. Utan 2-core är 2-core med eller utan HT, med all cache eller delvis avstängd sådan.
4-core är 4-core, med eller utan HT med full cache eller inte...
6-core är... ja du förstår.

Sen i valideringen blir de ju den CPU de bli. Om de är effektiva i låg spänning, är de perfekta mobila kretsar. Om de klarar högsta frekvenserna blir de top "K" CPUerna. Har de defekt del så kan de stänga av HT och en bit Cache och göra en "i5" eller vad de nu ska kallas. Jag har dock börjat undra om de inte rullar ut mobila separat nu för tiden dock, eftersom deras GPU lösningar skiljer.

Sen är det säkert undantag, där Intel valt att göra något specifikt för att matcha marknaden.

Ja och då ska vi inte prata om den rostiga läsarmen

Kan någon förklara Intels och AMDs olika strategier kring L1d samt L1i? @Yoshman? =). De verkar ju tänka tvärtom på vilken man ska satsa på.

Fast innan Coffee Lake Refresh har Intel hunnit med Amber Lake samt Whiskey Lake (dock bara för laptops). Så Coffee Lake Refresh är Skylake 6.

L1D$

När det kommer till just L1d$ tänker de ju på exakt samma sätt. Både Skylake och Zen har en virtuellt indexerad fysiskt taggad (VIFT) L1D$ där man sett till att index-delen inte har några adressbitar som skiljer sig i den virtuella och fysiska adressen (vilket jag skrev om ovan). Detta är just för att kunna slå upp i L1D$ och TLB parallellt.

Gissningsvis ändras inget här med Ice Lake, mer än att man måste gå från en 8-set associativ L1$ till 12-set associativ för att fortfarande kunna slå upp TLB parallellt. Finns allt få mycket nackdelar med att köra virtuellt indexerad virtuellt taggad (VIVT) för att det ska vara värt det, ARM har testat det för ett gäng år sedan och övergett det (med VIVT försvinner kravet på storlek/associativitet = 4 kB för att kunna slå upp TLB parallellt, men man måste i praktiken flusha cachen mellan varje kontext-switch...).

L1I$

För instruktionscachen har man definitivt tänkt olika. Intel kör samma strategi som för L1D$, d.v.s. VIFT med 8-set associativitet så uppslagen kan gå parallellt med TLB.

AMD kör med 64 kB och 4-set associativ VIFT cache. Varför då?
Att ha en större cache är normalt bättre, framförallt en större L1 då den är så pass liten att ökningar ger procentuellt större utdelning. Är inte heller några problem att hålla latensen på samma 4 cykler vid 64 kB (Apple fixar det även med 128 kB, i alla fall på TSMC 7 nm).

Problemet är att utan andra optimering så betyder 64 kB 4-set associativ cache att man först måste slå upp TLB, sen kan man börja uppslagning i L1I$. Inte bra för latens!

Förklaringen jag sett här är att AMD förlitar sig väldigt mycket på att branch-predictorn (som sitter tidigare i pipeline, den är del av front-end medan load/store är back-end) har rätt. Endera utnyttjar man det så att den fysiska adressen är cachad i branch-predictor alt. så gör man en spekulativ TLB-uppslagning redan i front-end. Gissar på det senare, men vet inte vilket som är fallet.

Zen har också en relativt stor mikro-ops cache (kallas ibland L0i$) jämfört med Intel (som införde en sådan i Sandy Bridge). x86 instruktioner är en total katastrof för en front-end att hantera, vilket är orsaken att både AMD och Intel lagt massa kisel på mikro-ops cache. I den cachen kan man ju också ha stoppad in saker för att minska effekten av högre L1I$ latens.

Rent generellt verkar ju båda lösningarna fungera bra. Zen kan uppvisa helt fantastisk prestanda på väldigt små loopar som helt får plats i L0I$, men kan nog vara deras val av L1I$ som ligger bakom varför Zen presterar förvånansvärd dåligt i många script-språk (som typiskt har relativt stor huvudloop som inte på långa vägar får plats i L0I$).

Har sett många exempel på det senare, men inte hittat någon förklaringen i de prestandaräknare som x86 CPUer har. Man kan läsa ut cache-missar, TLB-missar, IPC etc, men går inte att alls få någon insikt i vad som händer i mikro-op cachen från dessa

När man talar om trollen, TechReport postade en artikel just om i7-5775C igår.

Tog ju ett bra tag även för Intel själva att riktigt fatta varför L4$ var i det närmaste värdelös för CPU i majoriteten av alla program, men den gav ju enorm boost i spel.

L4$ har väldigt låg bandbredd för att vara en cache. Den är dual-portad, en för läsning och en för skrivning, båda med kapacitet på 50 GB/s.

Dual-portad design är perfekt för GPU då ofta gör båda parallellt, t.ex. kräver uppdatering i Z-buffer både läsning och skrivning vilket även är fallet för många shaders. Däremot är läsning normalt långt vanligare för en CPU jämfört med skrivning, så 50/50 är rätt obalanserat och i praktiken blir det mer som en cache med ~50 GB/s kapacitet.

L4$ har inte heller alls lika låg latens som L3$, den ligger betydligt närmare RAM än L3$.

Totalt sett uppför sig därför i7-5775C som ett system med väldigt snabbt RAM med väldigt låg latens. 50 GB/s var det inte tal för main-stream om när den här CPUn lanserades, nu är det mer eller mindre standard då det är var man får med DDR4-3200.

Detta har självklart även Intel insett. På desktop blir därför eDRAM väldigt mycket pengar för något som i praktiken inte har något större värde då hastighet på RAM gått upp så mycket.

Däremot har det ett väldigt stort värde på bärbara då snabbt RAM kraftigt ökar "idle" förbrukning, så där vill man inte köra snabbare än 2133/2400 MT/s + iGPU används i långt större utsträckning där. I Skylake designades därför eDRAM om från att vara en L4$ till att just vara en buffert mot RAM. Fördelarna är att man slipper offra 2 MB av L3$ (användes för L4 cache-taggarna i 5x77C) samt att ALLA RAM accesser nu kan nytta eDRAM, d.v.s även disk, nätverk etc.

Numera ligger i7-5775C i genomsnitt efter en i5-8400 i spelprestanda, så inte längre fullt så imponerande. Ändå ingen CPU man kan klaga på (har kvar min som spel CPU), laserad 2015 har 65 W TDP och drar ändå jämnt med 2700X (som utrustas med DDR4-3200) i spel!

Meltdown är ju löst redan i CFL-R. Lösningen var väldigt lätt och effektiv då all information redan fanns tillgänglig, lär ha lagt på lite latens för fixen är att validera privligeringsnivån (information som måste finnas i det TLB får tillbaka) INNAN man drar in något CPU-cache.

För en cache-träff kan detta ske parallellt med uppslagning i L1D$, vid en miss kommer ändå latensen dra iväg då man tidigast kan ha en träff i L3$ (Intel har i princip exkluderande policy mellan L1$ och L2$).

Att öka L2$ latensen gjordes antagligen av tre primära skäl:

• man ville minska strömförbrukningen, i Skylake minskades även associviteten från 8 till 4 (det är en klar fördel för strömförbrukning)

• AVX var ofta bandbreddsbegränsad innan, Skylake fick dubbel L2$ bandbredd, latens och bandbredd har ofta icke-förenliga designkrav

• högre latens tillåter högre klockfrekvenser, kan man öka frekvensen 17 % har man ju kompenserat för latensen

Vidare, för varje högre cache-nivå spelar dock latensen allt mindre roll. Är ju bara det som missar L1$ som påverkas av förändringar i L2$.

Zen har ju 64 kB L1I$ och 512 kB L2$, så någon gigantisk skillnad på priset lär det inte göra.

Cache är väldigt energieffektivt. Kostar långt mindre ström att hantera en minnesaccess från cache jämfört med att hantera den ur RAM.

SRAM drar i princip ingenting (mikrowatt) när det inte används då det inte behöver skrivas om hela tiden. Är bara i de djupaste C-state (tror det är C4 och uppåt) man flushar cache, skulle vara kontraproduktivt både för prestanda och strömförbrukning att göra det i C1/C3 där CPUn spenderar majoriteten av sin "idle" tid när den används.

Problemet är att en uppslagning kommer parallellt läsa på lika många ställen som caches associativitet, det är ett potentiellt problem.

Enda buggen som krävt att cache ska tömmas är väl "L1 Terminal Fault" (som för övrigt är fixad i CFL-R)?

Både Windows och Linux har valt allt INTE applicera motmedel mot denna som förval då den i bara kan utnyttjas i väldigt speciellt lägen som i praktiken bara existerar i vissa server-fall.

Att en CPU som klassades som värdelös, 3 år senare kan i stock (vilket åter är vad de mäter) hänga med 3 generationers nyare CPU, med 6/6 kärnor vs 4/8 där nyare CPUn har högre frekvens är faktiskt rätt imponerande. Alla 2600k, alla 4790k osv måste ju klockas djuret ur för att hänga med. Denna kan du köra med stock kylaren, även i 4Ghz+, och du slipper dyrt DDR4 RAM.

Att Intel inte designat dens cache "optimalt" är ju förklarligt... ingen visste att den skulle göra det den gjorde. Men det jag har svårt att begripa är... varför göra en 8-core, 16 trådig 200W CPU för "spel-optimering" för 6000kr... istället för att ta en 8400, med HT, och faktiskt göra en optimal SRAM lösning på den. Nu vet man ju var som sker, och kan optimera det. Hade gärna varit intresserad av en 65W upplåst 12 trådig, L4 bestyckad Coffee Lake med denna fördel. Betalar gärna för det, men inte för en 9900k kokplatta.

Lustiga är att jämför folk AMD kort vs Nvidia, klagas det jämt på att du får sämre prestanda med mer värme ur AMD korten. Men tydligen är det en "bättre" lösning när man tittar på Intel CPUer, istället för att göra dem mer effektiva på en specifik del... Känns... väldigt kapp-vändande i blåsvädret.

Jag vidhåller att detta är utan tvekan den bästa Intel CPUn på 5+ år... enda saken som slår den i vettig investering i övrigt är 2600k, men då är det mer än 5 år sedan. Men Skylake och allt efter... är inget mer än P4 Prescott kokare imho.

Därför intresserade dock lite cache förändringen mig, för det låter som att Intel åter jobbar på att effektivisera, istället för att överklocka det man har.

Om nu det är fördelaktigt... och inte skiljer på priset... varför har man inte gjort detta tidigare?
Någon förklaring finns där ju.

Okej, antog att det ändrats mycket. För jag minns diskussioner för läääänge sedan om att cache var problem för hur törstig en CPU var. Detta var ju dock på tidigt x86 tid, och mycket ha ju ändrats i power-states.

Buggen finns dock ändå där... och man valt att inte laga den pga man bedömer prestandaförlusten vs risken

Fast eDRAM är väl ändå rätt meningslöst på desktop numera? Fördel är ju att man får samma effekt som snabba minnen. Under lång tid hände väldigt lite med hastigheten på RAM, under de senaste tre åren har vi haft en rasande utveckling.

i7-5775C stod sig bra i spel (men i princip bara i spel) mot i7-6700K när den senare körde DDR4-2133. Med DDR4-3200 lär redan i7-6700K vara lika bra eller bättre oavsett last (förvånande hur många som missade hur mycket IPC gick upp för heltalsberäkningar med Skylake...).

Så vad vore poängen med eDRAM på desktop idag? eDRAM är relativt dyrt, om det inte ger något i majoriteten av applikationer (vilket är fallet, har just nu totalt 3 CPUer med eDRAM och jämfört dem mot versioner utan eDRAM)?

Stora fördelen eDRAM är för iGPU samt i fall där man har väldigt mycket I/O (vilket är fallet för mig i jobbet). Ovanpå det får NUC/bärbara fördelen av att kunna använda DDR4-2133/2400 och ändå uppföra sig som om man utrustat dem med typ DDR4-3200 fast man slipper strömförbrukningen (många NUC:ar har lägre maxförbrukning än de flesta stationära har i "idle" förbrukning).

Tja, jag är då inte allt för glad över utvecklingen på desktop. Blir en NUC med i7-8559U som ny "jobba-hemma-maskin" (så min fjärde CPU med eDRAM), få se om Zen2 eller Ice Lake medför något roligt.

Men hoppas innerligt att x86 så fort som möjligt blir förpassat till historien, det är just nu en rejäl bromskloss för att ge oss högre prestanda per kärna (och vill man gå multicore finns ännu mer fördelar med 64-bitars ARM).

Jag hade väldigt mycket hellre sett att man lade dubbelt så mycket transistorer per kärna än att man dubblade antalet kärnor. Vet inte vad alla som gapar över att de behöver 8C gör med sina datorer gör på sina maskiner. Kör Cinebench? Har nytta av 8C i mitt jobb, har dock ännu mer nytta av 20-30 % mer prestanda per kärna både hemma och på jobbet.

Tyvärr man börja slå i lite väl många x86-relaterade flaskhalsar, övre gränsen för vad fler transistorer per kärna kan ge är ungefär: prestanda ~ roten-ur(antal transistorer)

Men det är just "upp till". Apple har ändå visat att det är möjligt att få långt högre IPC än vad Skylake har, A12 verkar ju ligga på ~50 % högre IPC. Svårt att veta hur mycket av det som kommer från ARM64 ISA, men en hel del är mikroarkitektur för A12 är 50-100 % "bredare" i både front-end och back-end jämfört med Skylake/Zen.

Optimala i min värld är ju 2-4 riktigt feta kärnor samt 6-8 enklare kärnor för det som skalar riktigt bra + sådant man vill köra i bakgrunden. Här börjar man se uppvaknande i branschen då Apple kört denna och helt dominerat CPU-prestanda på mobiler/pekplattor sedan man släppte sin första "big-core" ARM.

Också svårt att veta vilken frekvens CPUn i artikeln vi kommenterar kör på, men om det är 2,6 GHz så ser IPC ut att ha ökat 15-20 %!

Att L1$ inte ökas har ju att göra med att x86 fortfarande använder 4 kB "pages". Förutsätter att Intel fortfarande kör med VIFT L1D$ även i Ice Lake, får se hur det påverkar strömförbrukning då det kräver 12 set associativ cache.

Om man hade droppat 4 kB "page" stödet borde vi sett patchar i Linux-kärnan för detta. Ice Lake har ju i övrigt rätt fullständigt stöd redan.

I övrigt måste man fundera hur transistorbudget ska användas. Dubblad storlek på L2$ lär i genomsnitt maximalt ge några procent högre IPC, det är därför bara vettigt om man inte har någon annanstans att lägga dessa transistorer med bättre utdelning. Åter igen, jämför Apples CPU.

Är först i senaste vändan man riktigt drog upp cache-storleken, ändå är denna generation en av de mindre ökningarna Apple haft i prestanda per kärna på många år. Man börjar nog se slutet på hur pass hög IPC ARM64 rimligen kan ge, eller i bästa fall tog man bara en paus i sin förbättring av mikroarkitektur och passade på att justera saker som cache.

Största problemet med cache tror jag är att det tar relativt stor kretsyta, så att öka cache är en av de sista saker man tar till. Första steget ska alltid vara att optimera front-end och back-end. Från Nehalem till Skylake fördubblades storleken på out-of-order fönstret, det är långt bättre användning av transistorer jämfört med 256 kB -> 512 kB L2$.

Men allt ser i något läge dimishing-returns, rätt säker att front-end börjar bli en rätt rejäl flaskhals på Intels x86. Problemet här: är extremt svårt att avkoda x86 instruktioner p.g.a. av variabel storlek, prefix som ändrar betydelsen av efterföljande instruktion, nästan alla instruktioner ändrar flag-fältet (för de som programmerar, ungefär som konstant skriva till en delad variabel i multitrådade program...).

Jämför med problemet ARM-nissarna ska lösa här. Alla instruktioner är fyra bytes, så trivialt att avkoda upp till 6-7 instruktioner per cykel vilket är var Apple numera gör. Zen tar upp till 4 st, Skylake tar upp till fyra 4 i normalfallet samt 5 i speciella fall). De flesta ARM instruktioner påverkar inte flag-fältet, samt de är icke destruktiva (d.v.s tar ett separat register för resultatet, x86 skriver över ett av indata registren).

Buggen är ju lagad i CFL-R (samt Whiskey Lake, Cascade Lake fixar även spectre variant 2).

Rätt säker på att du fånar dig i det här läget.

Du kan få >= prestanda i precis allt för 65 W TDP med i5-8400. eDRAM ger ingen vettig boost nu när RAM-hastigheterna har ökat så pass mycket. i5-8400 är ju med i TechReports nya jämförelse av i7-5775C, tänk då på att man bara testar spel. i7-5775C var långsammare än i7-6700K i de flesta "vanliga" applikationer även när den senare körde DDR4-2166.

Om du inte märker någon skillnad på CPU-byte säger det mest något om vad du använder din dator till. Själv märkte jag skillnad mellan de R5-1600 och i7-6770HQ jag hade tidigare i fall där enkeltrådprestanda gör skillnad, det är kanske ~30 % mellan dessa (till den senares fördel).

Finns faktiskt de som jobbar på sin dator. Är väldigt på det klara med av en i7-8559U kommer göra bättre och vad den kommer göra sämre än den R7-2700X jag nu använder för motsvarande uppgift (kommer behålla AMD-systemet, men ställer det nog på jobbet, avskyr desktop PC).

Gör även saker där en Optane-disk kan vara vettig, man får ju in en NVMe disk + SATA disk i Bean-canyon NUC:arna.

Ångrar inte heller 5775C, är lysande som speldator. Framförallt då den sitter i en relativt litet chassi.

Du vill inte ha en 6-kärnors version därför att när du stoppar i DDR4-3200 är eDRAM helt meningslöst

eDRAM, så som det används i Skylake, är vettigt om man vill ha riktigt låg strömförbrukning (NUC eller laptop nivå) eller om man har hyfsat extrema I/O-krav (extrema jämfört med svensson, inte jämfört med en större server).

Nu säger definitivt inte listpriset hela sanningen, t.ex. så listas i7-8559U för 431 USD, vilket känns rätt orimligt då en NUC med den CPUn går att köpa för ~5500 SEK inklusive moms.

Men eDRAM på dagens desktop-modeller är rätt dyrt räknat i förväntad prestandaökning per krona, förutsatt att du inte tänker köra med DDR-2400 eller långsammare.

Finns absolut snabbare eDRAM, flaskhalsen är nog mer hur eDRAM kopplas till CPUn idag. Självklart skulle man kunna ta fram en speciellt modell med eDRAM, men DET blir rejält dyrt om man inte kan lägga ut FoU-kostnaden över relativt många sålda enheter.

Det var ett riktigt lågvattenmärke...

Det vi haft åsiktsskillnaden om tidigare är om Intel behöver designa om Core (som har DNA tillbaks till PentiumPro). Finns fortfarande ingen annan x86-design som matchar Skylake i utfört arbetet per klockcykel och maxfrekvens.

Av det lilla som läckt ut finns ju indikationer på att Ice Lake kan komma att få en större ökning i IPC över Skylake än vad Zen2 får över Zen.

D.v.s. står fortfarande fast vid att Core är rätt mycket så "perfekt" en x86 design kan bli. Apple har dock med brutal övertydlighet visat att tar man bort "x86" ur ekvationen kan man göra något väsentligt bättre.

Intel lär nog knappast släppa en 64-bitars ARM, men de verkar inte försöka gömma allt för mycket att man jobbar med RISC-V. RISC-V och ARM64 lanserades båda runt 2011 och är båda en så "perfekt" instruktionsuppsättning vi är kapabla att designa just nu. AMD bör nog kraftigt överväga att ta upp sitt ARM-spår igen, Zen var ju tänkt att både bli en x86 och en 64-bitars ARM (K12) initialt (finns en del designval i back-end på Zen som känns lite udda för en x86 men helt logiska om man även skulle gjort en ARM).

Bara ett mindre problem med detta... Priset för att ta fram en krets har inte haft någon trevlig utveckling de senaste noderna, allt pekar på att det kommer bli väsentligt värre för varje nod framöver.

Ett exempel är att Qualcomm faktiskt _backade_ ett halvsteg i deras senaste Snapdragon, man gick från TSMC/Samsung 10 nm till Samsungs 11 nm (som i praktiken är för deras 14 nm vad Intels 14 nm++ är för Intels 14 nm). Inte sett något officiellt från Qualcomm kring detta, men gissningarna ligger på att man inte ansåg prislappen motiverande eventuella fördelar.

Men precis det du skriver ser vi ju hända på bred front i systemkretsarna för smarta mobiler, rätt säker att det kommer leta sig in i bärbara relativt snart.

Apple, Qualcomm, Huawei, m.fl. har stoppat in ett par "high-end" CPUer för interaktiva laster, ett gäng "efficiency cores" för bakgrundsuppgifter, iGPU för grafik, NPU (neural network processor) för maskininlärning samt DSP för bildhantering.

Där är en vettig framtid. CPU-delen ska göra så lite som möjligt, den ska hantera uddafallen, de fall man inte tänkte på innan samt det som är latenskänsligt. Det är styrkorna i en CPU. Men allt som kan köras på mer specialiserad kisel ska lyftas bort från CPU, blir väsentligt högre beräkningseffektivitet på det sättet.

Problemet innan har varit att kunna programmera sådana system. Är fortfarande ett problem, men man gör trots allt verkliga framsteg inom detta (jämfört med tidigare där det mesta var varmluft).

Att ta fram en fungerande high-end x86 är ett jätteprojekt. Finns en anledning varför AMD försöker täcka alla marknader med en enda design, något som kommer ge kompromisser. Inte ens Intel anser sig ha råd med mer än tre spår,
Atom för NAS, mikroservers samt bärbara i budgetsegmentet.
S, H, U och Y-serien som alla är samma CPU för olika konsumentsegment.
X-serien samt Xeon som riktar sig mot servers (X-serien känns just nu rätt meningslös, än mer så efter 9900K).

Även här finns stora anledningar till att skrota x86. Både AMD och Intel var chanslösa från start på mobilsidan, inte för att x86 inte kan göras energieffektiv utan därför tiden att designa och validera en x86 krets tar så mycket längre tid än att designa och validera en krets med en "vettig" ISA (fast är gränsfall om 32-bitars ARM är "vettig", 64-bitars ARM och RISC-V är definitivt vettiga) att inte ens Intels FoU hade någon chans.

Om det visar sig att Ice Lake trots allt har 15-20 % högre IPC har jag svårt att tro man kan riktigt hålla frekvenserna på 10 nm. Och det må vara en imponerande ökning för dagens x86, men på ARM sidan såg man Apples A12 som lite "meh" då den bara hade ~15 % högre prestanda per kärna än tidigare.

ARM själva lovar ju ~30 % ökning i enkeltrådprestanda per år de närmaste tre åren. Man ligger numera någonstans mellan Zen och Skylake i IPC med Cortex A76. Är fortfarande en bit kvar då man räknar med klockfrekvenser på 3,0-3,5 GHz.

Jag bytte nyligen, ofrivilligt, från Haswell-E till Coffee Lake och tycker det är en påtaglig uppgradering. Det är kanske inte vad jag sett som värt pengarna, men när gamla systemet pajade så... en definitiv uppgradering.

Skickades från m.sweclockers.com

Nej. Jag fånar mig inte.
Jag har bara andra önskemål än du har.

Och om inte mer cache spela någon roll, hade inte Intel ökat den heller.
Med tanke på att det görs eDRAM CPUer även med Kaby, så förstår jag inte varför du anser dig veta bättre än Intel nu.
Men du älskar dina vanliga applikationer som argument, trots att de är noll roll, meningslösa och inget som intresserar mig. Köp en AMD om du vill köra dessa prisvärt....

För du använder enkelttråd prestandan... jag gör det inte.
Inget jag kör är tungt 1-tråd. Antingen är det flertrådigt, eller 1-tråd lätt jobb som tom en 3Ghz gammal C2Duo klara av. Finns ingen vinst för mig.

Lite det där "värt pengarna" som är problemet. Ingen tvekan på att en graf, eller 1 FPS eller 2 kan ges mer, men det är inte värt pengarna. Problemet med 5775c är eg dens låga frekvens i stock. Men det är enkelt att dra upp till 4Ghz. När du gör det, är du i samma lika i IPC som både 8400 och många andra CPUer. Och även om du inte håller 65W när man gör det, så är det inte svårt att kyla vs en stock 4790k eller nyare. Det är trots allt 14nm i broadwell också, så skillnaden är inte så stora i praktiken.

När väl eDRAMet kommer in i bilden dock, får denna CPUn fortfarande sin boost, och att man åter jämför tester med den i stock, säger bara att man inte insett fördelen den har över tex 8400... den kan klockas

Kan tillägga @Yoshman att vill du sälja din, blir du förvånad hur mycket du kan få och hur enkelt det är. Folk gapar efter dessa CPUer... så antingen behåll den och va gla, eller sälj och köp dina dyra nya meningslösa leksaker.