Tom's Hardware har kjørt en test for å overklokke core2 duo E6300. Dette er i og for seg interessant nok, men jeg synes det var mest spennende å se på grafene for overklokket E6300 vs 6800 Extreme. Hovedforskjellen mellom disse to utenom klokkehastighet er at sistnevnte har 4MB cache mot 2MB og koster rundt $1000

500 MHz FSB? Core 2 Duo Overtakes Core 2 Extreme | Tom's Hardware


"MainConcept H.264 Encoder v2 Version: 2.1
2:19 min MPEG2-source 1920x1080 to H.264
Profile: High
Audio: AAC
Stream: Program "

Det ser ut som om de her gjør en ikke-sanntid transkoding av MPEG2 HD til h264. Det er kanskje rimelig å anta at h264 encode utgjør betydelig mer enn en enkel MPEG2 dekoding her. Det er kanskje også dermed rimelig å anta at en ren h264 dekoding vil gi noenlunde samme skalering. Siden dette ikke er sanntid så får vi et uttrykk for gjennomsnittlig frame-rate, ikke minimum (altså sjansen for at cpu ikke rekker å dekode en frame i tide og vi får hakking)

Hvis vi bare var begrenset av cpu-ens klokke-frekvens så ville man anta at en dobling av cpu-frekvens gav halvering av transkodings-tiden. Altså at produktet (kodingstid)*(klokkefrekvens) ville holde seg konstant. Hva skjer om vi regner ut denne brøken?

10:58 (658 sekund) ved 1.86 GHz -> 1224
8:26 (506 sekund) ved 2.44 GHz -> 1235
7:07 (427 sekund) ved 2.93 GHz (X6800) -> 1251
6:12 (372 sekund) ved 3.4 GHz -> 1265

Vi ser altså at samme cpu på samme platform som kjører (3.4/1.86) = 1.83 ggr høyere klokke gir en reduksjon i prosesserings-tid på (658/372) = 1.77. Ikke så veldig langt unna lineær skalering.

Dette underbygger i mine øyne at cache er av underordnet betydning for akkurat denne applikasjonen, så lenge vi holder oss til Core2 arkitekturen så er klokkefrekvens direkte proporsjonal med ytelse.

Hvis vi sammenligner med winrar

Så ser vi et helt annet bilde. Blir 6300@3.4 båndbreddebegrenset av disk (300MB på ca 1 minutt), eller er det mangelenn på cache som gjør at den yter likt med x6800 som har lavere klokke?

-k