Intel Lakefield imponerar inte i prestandatest

Att tile-baserade renderare misslyckas med en så udda processorlösning är inte konstigt. Ungefär samma sak händer i t ex blender när man väljer blandad CPU+GPU-rendering. Grafikkortets enda "tråd" är ungefär 4-5 gånger snabbare än processorns (i mitt fall) 24 trådar, så är det få tiles kommer en väldigt stor andel av totalen att gå på "långsamma" trådar. I blender löser man det genom att ha väldigt små tiles, men i Cinebench är storleken låst.

Fast nu handlade det väl om det test som enbart belastar en kärna och att det ändå spreds över de klena kärnorna när det inte skulle gjort det. Säkert något som kommer korrigeras med windows patch eller drivare från Intel.

Allt har har nog runnit ut i sjön. 😉

Fast intel har ju varit tydliga med att det är dags att sluta titta på prestandasiffror... 🙄

Jag tycker i alla fall 14k är mycket pengar men visst det finns mycket dyrare bärbara datorer också. Nu har jag inte använt datorn själv så svårt att avgöra vad den bör kosta.

Vad har du för extrema krav om du knappt får en telefon för 12k? Skulle säga att telefoner för 5-6000 är riktigt bra
Exempelvis nya modellen av iPhone se.

Edit missade ett "inte"

Vänta bara. Snart kommer Intel ut med tester där de "bevisar" att denna minsann klår Ryzen 9 4900hs i "real world tests".

Ett icke-problem i processorer där alla kärnor har samma prestanda. Gigantiskt problem i processorer likt Lakefield där enbart en kärna finns för att dra de tunga lassen.

För bärbara enheter är designen i Lakefield det bästa sättet att skapa något som både reagerar bra på interaktiv användning (som nästan enbart behöver maximal enkeltrådprestanda) samtidigt som man har OK hantering av fall som kan skalas över kärnor (många långsamma kärnor är mer energieffektivt än få starka för dessa fall).

Ställer mig lite frågan till hur vanligt det ändå är att köra något som har någon större skalning över CPU-kärnor på ultra tunna bärbara, men finns säkert någon som ser ett fall. Gissar att PR-värdet är huvudpunkten, att försöka sälja en telefon som inte har 8 CPU-kärnor är tydligen rätt hopplöst i vissa regioner... (Testa monitorera en modern Android-telefon, försökte det själv och lyckades aldrig använda mer än 3 kärnor i något läge på en Samsung S10+ genom att använda de appar jag brukar köra, ofta används bara 1 kärna).

Att designa programvara för asymmetriska system är svårt. Att ha två typer av CPU-kärnor är ändå i detta kontext bland det enklare att få till, Linux löser det hela bl.a. genom att hela tiden försöka klassificera trådar som "compute-bound" eller "I/O-bound". Den senare klassen bör alltid få förtur till de CPU-kärnor med lägst svarstid, d.v.s. de "stora" kärnorna.

Windows verkar just nu köra OS-schemaläggarvärldens motsvarighet till sorteringsvärldens Bogosort med avseende på hantering av asymmetriska CPU-kärnor...

Cinebench har inget med saken att göra, det handlar om Windows schemaläggare. Kör jag enkeltrådfallet på Windows blir belastningen en jämn smet över kärnorna (vilket måste betyda att lasten hoppar runt flera gånger per sekund). Samma fall på Ubuntu (+Wine) så håller sig lasten på samma kärna nästan hela tiden, var 3-4 byten under hela körningen.

Det kan vara ett icke-problem, det beror på vad programmet gör samt hur systemet är designat. En av de absolut dyraste operationerna sett till energi är dataförflyttning. För Cinebench, där "working-set" är så litet att hela körningen nästan uteslutande körs från CPU-cache, är just denna aspekt irrelevant.

Men rent generellt vill man hålla en beräkning lokalt där data finns. Nvidia är väldigt medveten om detta, CUDA (programvaran) kräver att en beräkning som jobbar på ett viss datamängd stannar inom samma SM.

Det trista den här informationen också då säger är att Windows on ARM även lyckades göra en soptippsbrand av big.LITTLE, är det något man lyckats få rätt? Hade faktiskt förvänta mig att just den här aspekten inte skulle vara ett problem för Lakefield då Microsoft borde ha löst detta när man skapade Surface X, den har fyra "stora" kärnor och fyra "små" kärnor -> presterar sämre än den borde p.g.a. av detta problem.

Hur kan inte Microsoft få till detta när man kan titta på Linux där problemet löstest rätt tidigt i big.LITTLE eran? Gissningsvis har även Apple också löst detta då Iphone/Ipad kört en sådana konfiguration ett par generationer, vilket då betyder att man redan löst det för MacOS då iOS och MacOS kör samma OS-kärna.

Tvärtom faktiskt, att flytta runt beräkningar försämrar energieffektiviteten i det allmänna fallet (kvittar för just CB då det har ett minimalt "working-set" per tråd). Testade lite snabbt att låsa resp. inte låsa CB15 single-thread till en specifik kärna. På en SP4 (i7-6650U) gjorde det noll skillnad, vilket pekar på att värme är ett icke-problem i detta fall -> man borde få samma prestanda då alla kärnor är likvärdiga.

På 3900X ser man någon enstaka procent skillnad mellan att köra på den "bästa" kärnan vs låta det hoppa runt. 3900X har ju fyra CCX som inte delar någon cache, så där kan kostnaden i energi bli en faktor för vissa program om beräkningen skulle hoppa runt.

Går knappt att få en telefon för under 12k? Och 14k är ingenting?
Nu lugnar vi oss lite va.

Jag köpte då min Pixel 3a för ca 200 euro. Skulle aldrig falla mig in att betala en spänn över 4000 kr för en mobil.