Fusket består av två delar, den ena har redan nämns här och består i att man kör GPUn i en något högre frekvens än vad den annars någonsin skulle använda, ökningen man får i prestanda från denna del är nog under den nivån där man överhuvudtaget märker något.
Den andra delen i fusket belyser däremot ett mycket mer intressant problem: CPUer med (för klassen) hög prestanda med en väldigt låg TDP kräver ett ganska stort spann av olika CPU-frekvenser, vad betyder det för upplevd prestanda?
I Samsungs fall så gav den senare delen av fusket en rejäl boost, framförallt på deras eget Exynos Octa som använder två typer av CPU-kärnor i vad som kallas big.LITTLE, en Cortex A7 (LITTLE) och en Cortex A15 (big).
På pappret ser big.LITTLE ut som en perfekt teknik, man kör med en liten strömsnål CPU-kärna när lasten är låg och en snabbare med "törstigare" CPU-kärna när lasten är hög. I fallet Qualcomm, Intel och AMD har man i stället ett större spann av frekvenser och matarspänning till CPU-kärnan.
Att byta frekvens på en CPU-kärna, något Intel kallar byta P-state, tar faktiskt väldigt lång tid. Haswell är nog den CPU som kan byta frekvens snabbast av alla och där tar det ~10µs, kanske inte låter mycket men kör man på 2GHz så är det 20.000 CPU-cykler.
På Snapdragon tar ett frekvensbyte ~100µs, kör man i big.LITTLE så kostar ett frekvensbyte som också involverar byte från LITTLE till big (eller tvärs om) många millisekunder. Vi pratar nu om att ett program hinner köra ett par miljoner CPU-cykler innan frekvensbytet genomförts.
Ju längre tid det tar att hoppa mellan frekvenserna, desto mer tröghet lägger Linux in för att faktiskt genomföra bytet. I fallet benchmarks så kan det mycket väl betyda att resultatet man får är på en lägre frekvens (eller på en långsammare CPU i fallet Exynos Octa), vilket då avspeglas i sämre resultat.
Visst, men vem bryr sig om benchmarks? Rätt många verkar det som, men om man tänker lite längre och funderar vilken påverkan detta har på vardaglig användning av enheten så inser man snabbt att en så pass långsam ökning av frekvensen att man som människa hinner märka det kommer resultera i en enhet som känns relativt seg trots att enheten faktiskt har väldigt mycket maximal kraft.
Så allt prat om mobiler på >2Ghz är egentligen rätt mycket varmluft. Dels utvecklar CPUerna mer effekt än TDP i det läget, så man kan bara köra den frekvensen några sekunder, sedan kommer man i många fall inte använda denna höga frekvens när den väl behövs för typ "touch-event" och andra interaktiva laster är typiskt väldigt korta, enheten sover före och efter händelsen så man startar typiskt i lägsta möjliga frekvens och hinner ofta inte skala upp till max frekvens innan man är klar...
Frågan om inte Apple tänkt mest rätt här: i stället för att ge sig på MHz och CPU-kärnor race:et har man i stället utvecklat en CPU-kärna med väldigt hög IPC, något som i.o.f.s. betyder att man inte kan ha så många kärnor då de är komplicerade, men man klarar sig med väldigt låg frekvens. Låg frekvens betyder lägre spänning, något som betyder låg strömförbrukning (lite av denna fördel förloras i att CPU-kärnan är mer komplicerad). Låg frekvens betyder också mindre frekvensspann, så problemet beskrivet ovan är mindre.
Edit: LOL, lyckades skriva en wall-of-text men missade att skiva hur Samsung fuskade här
Man låter helt enkelt CPUn alltid använda högsta frekvens när man ser att det är en (känd) benchmark som körs.
Det betyder INTE att det drar tokmycket ström hela tiden, man har forfarande kvar möjligheten till att "clock-gate:a" CPU-kärnan, d.v.s på ren svenska stoppa CPUn och på så sätt spara massor med ström när den är "idle". Detta är något CPU-tillverkarna kallar för C-state, bara i C0 man faktiskt kör program. Alla andra C-state är olika former av "idle", att kliva ur C1 ("lättaste" formen av "idle") tar ~1µs.
