Intel "Tiger Lake" visar stark enkeltrådad prestanda i tidigt test

Core i7-1065G7 har ett konfigurerbart TDP-värde mellan 12 och 25 watt, varför det är rimligt att även efterträdaren håller sig i det spannet. Detta är dock en av flera detaljer kring testet som är okända, så det återstår att se.

Var det inte Sysmark som grollet gällde? Är det en benchmark som någon använder längre?

Angående "APU" (eller, CPUer med integrerad GPU som det faktiskt är) tror jag AMD haft rätt om tekniken hela tiden. Problemet är att än idag (14 år efter att AMD köpte ATi) finns fortfarande inget vettigt sätt för applikationsutvecklare att faktiskt koda för AMDs APUer utanför 3D grafik.

Apple lär pusha stenhårt för att utnyttja alla de specialkretsar de lägger in sitt "Apple silicon". Där finns redan färdiga systembibliotek för att använda allt från GPGPU (Metal Compute), till SSE/AVX på Intel och NEON på ARM (Apple SIMD) till att använda NPU för maskinlärning (CoreML).

Intels oneAPI kan bli motsvarande för PC-sidan, detta då man nu redan innan släpp av Tiger Lake stöd för att inte bara använda Xe via oneAPI utan allt från gen 8 (broadwell) fungerar, Nvidias aktuella GPUer har redan stöd. Har sett någon blänkare om att det finns preliminärt stöd för de Radeon GPUer som stöds av AMDs ROCm i oneAPI.

Men tror Apple kommer köra över PC-laptops rejält redan första året. Förhoppningsvis leder det till att PC-sidan inser att de måste jobba ihop och få lite ordning i leden!

30 % upp från Ice Lake är i den högre delen inom det förväntade spannet för prestandaförbättring. Undrar ändå hur långt det räcker givet hur Apples mobil CPU står sig mot i7-1065G7 (länge den snabbaste Ice Lake modellen, nu finns marginellt snabbare i7-1068G7 också). Även här kan något gott komma ur det hela om Intel/AMD blir totalt överkörda av "Apple silicon", det lär få Microsoft att vakna och inse att man måste våga all-in på en seriös ARM64 satsning. Har skrivit det tidigare, är allt mer övertygad att Microsoft har handen rejält i syltburken runt Cortex X1 (ARMs första CPU-design som verkar lite väl overkill för att bara sitta i mobiler, utför ~60-65 % mer per cykel jämfört med Skylake, dock maxfrekvens på ~3,3 GHz).

Att benchmarks för desktop-laster tenderar vara så totalt värdelösa när de försöker sätta en siffra på värdet av flera kärnor ... Hade väldigt dålig koll på vad Passmarks "CPU-mark" innefattade, men föga oväntat läser man detta i beskrivningen

"To ensure that the full CPU power of a PC system is realized, PerformanceTest runs each CPU test on all available CPUs."

D.v.s. man testar överhuvudtaget inte hur bra ett system är på att köra multitrådade program utan man testar hur bra systemet kör flera enkeltrådade program samtidigt. Det är en totalt orealistisk arbetslast, vilken bärbar dator kör 8-16 enkeltrådade program där varje program vill ha 100 % CPU?

Att köra den typen av test är relevant för vissa typer av server-laster, där är det hyfsat vanligt att man designar systemet så varje separat session i praktiken är enkeltrådad -> flera kärnor utnyttjas när man har flera samtida sessioner aktiva. För desktop är nog spel den klart bästa motstocken på hur väl en CPU hanterar multitrådade program, fall som skalar bättre än spel med kärnor är typiskt de som se ännu större boost från GPGPU-acceleration, som t.ex. Adobe Premier där senaste versionerna sett heltalsfaktorer bättre prestanda när man lagt in OK GPGPU-stöd.

Däremot verkar ändå detta benchmark ha en OK mix av saker man testar, kanske lite små "working-set" om målet är att testa hur olika CPUer skulle uppföra sig under vad som kan anses vara realistisk "tunga" fall. Här körs i princip alla test-fall helt ur CPU-cache, vilket för normalanvändaren i.o.f.s nog är precis vad som händer i praktiken.

Det man testar är

• Generella heltalsberäkningar (detta är något som testar alldeles för lite i typiska CPU-tester då heltalsprestanda är det enda som spelar roll för normalanvändaren väldigt nära 100 % av fallen)

• Komprimering, ett form av kombinerat heltals och minnestest (även om man här bara jobbar på 4 MB data så i praktiken kör man helt mot CPU-cache)

• Primtalsberäkningar, ett form av heltalstest som också testar hur CPUn hanterar villkorade hopp. Få lär sitta och räkna primtal, men detta test säger ändå något som hur en CPU uppför sig (JavaScript-prestanda och liknande beror också rätt mycket på liknande faktorer)

• Krypteringstest, detta är för normalanvändaren i praktiken totalt irrelevant och påverkar bara slutresultatet på ett sätt som har noll bäring på en klar majoritet. Än värre är multitrådfallet av detta, inte ens en NAS lär komma nära fall där alla kärnor samtidigt primärt jobbar med kryptering. Extra illa här då det är 1 test av 8, katastrof om man sedan använder aritmetisk medelvärde (i GB5 är krypteringstestet 1 av 21 och eventuellt avvikande värde minimeras än mer av att där kör geometrisk medelvärde)

• Generella flyttalsberäkningar, som 1 av 8 test är det en rimlig viktning, kanske lite väl högt just om man tittar på U-serie CPU (d.v.s kretsar tänkta för ultratunna bärbara)

• SIMD-tester, för desktop-datorer är det fullt rimligt att 1 av 8 tester kör detta. För bärbara kan man diskutera det hela, men då maskininlärning börjar hitta in i allt fler program är det ändå en punkt som kommer bli allt viktigare med tiden (om man nu inte i stället börjar stoppa in NPU-kretsar, vilket redan hänt på mobilerna och som Apples kommande laptop-kretsar därför också kommer ha)

• Sortering av strängar, ännu en variant av heltalstester. Denna är definitivt en vettig sak att testa, här kör man ett lite större "working-set", 25 MB per kärna, då man använder en cache-snäll algoritm körs detta ändå i praktiken ur cache (vilket ändå är vettig i detta fall, även med väldigt stort "working-set" får man bra cache-hit rate i detta fall tack vare hur moderna CPUer fungerar)

• Fysiksimulering, ett flyttalstest som visserligen är relevant på skrivbordet, fast bara för en extremt liten grupp

Mellan tummen och pekfingret brukar man säga att i valet mellan ~20 % högre prestanda per kärna och dubbla antalet kärnor med bibehållen prestanda per kärna så är det förra i praktiken mer värt för en klar majoritet av desktop-användarna. Intel behöver verkligen sina 30 % upp för att Tiger Lake inte ska se patetiskt ut jämfört med "Apple silicon", men tror ändå det inte kommer räcka (d.v.s. är gissar om att Apple kommer matcha enkeltrådprestanda hos Tiger Lake U). Och då ryktena pekar på att Apples krets kommer få 12 kärnor lär den få löjligt höga resultat i dåligt designade benchmark likt Passmarks CPU-mark...

Är inte riktigt helt med på hur Passmark räknar ut sitt "Cross-platform Mark", men givet beskrivningen får jag känslan att det värdet är det minst dåliga resultatet att använda här om man vill ha ett mått på "generell CPU-prestanda". Det överskattar fortfarande värdet av många kärnor (att köra flera enkeltrådade applikationer skala löjligt mycket bättre än vad man typiskt kan få till i ett enskilt multitrådat program), uppsidan är att där saknas framförallt krypteringstestet (testar heltal, flyttal, sortering och primtal).

Markerade är urtypen för vad man måste hantera när man skriver program där man löser ett och samma problem och vill accelerera det genom att använda flera kärnor.

Visst finns det problem som är embarrassingly parallel, men de är typiskt exakt den typ av problem som i.o.f.s. skalar perfekt med CPU-kärnor fast just därför passar de nästan alltid GPGPU som hand i handsken, i det läget är GPU >> CPU.

Finns ändå undantag, kompilering är ett sådant. Grejen är att även om jag själv använder det är det ett nischfall, framförallt då även väldigt många som jobbar med programmering har liten nytta av detta. T.ex. de som jobbar med scriptspråk + även de som jobbar med kompilerade språk använder förhoppningsvis inte tunna bärbara som byggservers. Kvar är då inkrementella byggen, då är vi tillbaka på krävande enkeltrådade fall!

Databaser: absolut, men har man verkligen stora databaser på ultratunna? Är det inte sannolikare att det man har på sin bärbara är mindre testfall, de tunga delarna lär ändå gå på någon form av server.

Videoredigering är ett lysande exempel där man absolut kan utnyttja flera kärnor med bra utdelning, fast vi har just i detta är exempel där GPGPU kan ge heltalsfaktorer högre prestanda (så GPGPU >> multicore CPU).

Säger inte att spel är perfekt, långtifrån då de nästan alltid är GPU-bundna. Men av det som testas är spel vettiga att titta när de testas i låg upplösning då man är väldigt snabb att anamma de tekniker som tagits fram just för att använda flera CPU-kärnor på fall som inte är "embarrassingly parallel" (d.v.s. majoriteten av alla arbetslaster på skrivbordet).

Kolla ramverken i C++, Java, C#, Rust m.fl. för att använda flera trådar för att lösa ett specifikt problem, de vettiga varianterna bygger nästan uteslutande på någon form av work stealing. Och är exakt den tekniken spel använder, DX12, Vulkan och Metal är alla designade för underlätta och effektivisera "work stealing" (är den delen som gör dem "optimerade för flera kärnor").

Men så fort man försöker lösa ett och samma problem med flera kärnor, där problemet inte är trivialt att parallellisera, så slår man i Amdahls lag (det är i praktiken en fysisk barriär, inte bara "usla programmerare"). D.v.s. effekten man kan få ut ur flera kärnor har en övre gräns som beskrivs av work/span laws, det är lika omöjligt att bryta den lagen som att accelerera något förbi ljusets hastighet. D.v.s. slöseri med tid att försöka.

Bästa sättet att testa är självklart att köra många olika program, så vill verkligen se TechPowerUp (som testar betydligt fler applikationer jämfört med de flesta och framförallt testar man inte 50 % renderingsprogram som tyvärr majoriteten gör) och framförallt Phoronix (som tack vare en helt automatiserad test-suite brukar få upp tester med hundratals fall, men de testerna kommer ofta en tid efter produktsläpp).

Sågar inte heller CPU-mark totalt, givet vad de testar är nog deras enkeltrådtest helt OK test av fall som är just enkeltrådade. Sämre än GB5 då det testar långt fler fall, men ändå helt OK.