Tom's Hardware have been running an article describing overclocking of the intel Core2 E6300 processor showing that it can generally outperform the $999 Core2 X6800 cpu in a number of tests. The two cpus differ in clock frequency, cache size (4MB vs 2MB shared) and price.
This is interesting in itself, but I think that the results for MPEG2->h264 1080 transcoding is very interesting for HTPC applications.
http://www.tomshardware.com/2007/01/...eme/page8.html
"MainConcept H.264 Encoder v2 Version: 2.1
2:19 min MPEG2-source 1920x1080 to H.264
Profile: High
Audio: AAC
Stream: Program "
This seems to be a transcoding of 1080 HDTV material (unknown bitrates) from MPEG2 to h264. OTOH, I would guess that h264 encoding takes the bulk of processing time, and that scalability should apply to a h264 pure decoder as well?
For the special case of a pure cpu-limited application, one would suspect there to be a 1:1 scaling between cpu clock and exececution speed. Normally, this isnt so because normal applications may be limited by graphics card performance (games), harddrive performance, memory performance etc.
If we calculate (processing time)*(clock frequency)
10:58 (658 seconds) at 1.86 GHz -> 1224
8:26 (506 seconds) at 2.44 GHz -> 1235
7:07 (427 seconds) at 2.93 GHz (X6800) -> 1251
6:12 (372 seconds) at 3.4 GHz -> 1265
It is evident that for this particular task, increasing the cpu clock leads to a near linear increase in video performance, and that 4MB of cpu cache seems to have no impact.
One can only speculate whether this extends to other similar tasks such as real-time decoding of high-bitrate h264/VC1 material.
If we compare with WinRAR (a zip-like utility for lossless compression of general data files):
The 3.4GHz overclocked E6300 give virtually no improvement compared to the 2.93GHz X6800.
Possible reasons:
1. Cache size is important for this application
2. At >~3 GHz, this platform cannot improve Winrar performance due to other bottlenecks such as harddisk latency/bandwidth
-k
This is interesting in itself, but I think that the results for MPEG2->h264 1080 transcoding is very interesting for HTPC applications.
http://www.tomshardware.com/2007/01/...eme/page8.html

"MainConcept H.264 Encoder v2 Version: 2.1
2:19 min MPEG2-source 1920x1080 to H.264
Profile: High
Audio: AAC
Stream: Program "
This seems to be a transcoding of 1080 HDTV material (unknown bitrates) from MPEG2 to h264. OTOH, I would guess that h264 encoding takes the bulk of processing time, and that scalability should apply to a h264 pure decoder as well?
For the special case of a pure cpu-limited application, one would suspect there to be a 1:1 scaling between cpu clock and exececution speed. Normally, this isnt so because normal applications may be limited by graphics card performance (games), harddrive performance, memory performance etc.
If we calculate (processing time)*(clock frequency)
10:58 (658 seconds) at 1.86 GHz -> 1224
8:26 (506 seconds) at 2.44 GHz -> 1235
7:07 (427 seconds) at 2.93 GHz (X6800) -> 1251
6:12 (372 seconds) at 3.4 GHz -> 1265
It is evident that for this particular task, increasing the cpu clock leads to a near linear increase in video performance, and that 4MB of cpu cache seems to have no impact.
One can only speculate whether this extends to other similar tasks such as real-time decoding of high-bitrate h264/VC1 material.
If we compare with WinRAR (a zip-like utility for lossless compression of general data files):

The 3.4GHz overclocked E6300 give virtually no improvement compared to the 2.93GHz X6800.
Possible reasons:
1. Cache size is important for this application
2. At >~3 GHz, this platform cannot improve Winrar performance due to other bottlenecks such as harddisk latency/bandwidth
-k