Benchmark your computer with Handbrake

[monstercameron]

Genuine Intel® CPU T1300 @ 1.66GHz ubuntu 12.10

x264 [info]: using cpu capabilities: MMX2 SSE Cache64
x264 [info]: profile Main, level 3.0
[01:53:24] reader: done. 1 scr changes
[01:53:38] work: average encoding speed for job is 5.182079 fps

 

[mrle]

Intel Atom N270 (single core with HT) @ 1.60 GHz
Arch Linux i686
HandBrake rev5474 (2013062499)

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowCTZ SlowAtom
x264 [info]: profile Main, level 3.0
[09:39:56] reader: done. 1 scr changes
[09:40:07] work: average encoding speed for job is 7.469536 fps

 

[monstercameron]

Intel Atom N270 (single core with HT) @ 1.60 GHz
Arch Linux i686
HandBrake rev5474 (2013062499)

custom compiled?

 

[mrle]

custom compiled?

No, just generic i686 from https://www.archlinux.org/packages/community/i686/handbrake-cli/

I think it does not have to be custom compiled to get the best results, because it selects optimal code path for the particular cpu at runtime.

I have been doing some experiments with newest gcc, and the Atom, being in-order, is actually not that slow once it has its instructions ordered just the right way by the compiler.

 

[JoeRambo]

"Custom" compilation won't help much, at the heart of handbreak there is x264 that is famous for incredible hand tuned assembly code. Since x264 is where most time is being spent, I don't think even ICC compiled handbreak can achieve substantially faster results.

 

[SPBHM]

"Custom" compilation won't help much, at the heart of handbreak there is x264 that is famous for incredible hand tuned assembly code. Since x264 is where most time is being spent, I don't think even ICC compiled handbreak can achieve substantially faster results.

well, it looks like just going for the last version or the "nightly build" gives a 5% gain with all the rest unchanged...



my result should be included on the list
http://forums.anandtech.com/showpost.php?p=35201481&postcount=28

I tested with the version from the OP and Nightly build, I don't know which version should be used to be included, but both are there.

 

[NostaSeronx]

OpenCL version didn't increase my speed, probably because I had a 480 GTX.

 

[blotto]

2500k @ 4.6ghz
8GB 1600mhz

0.9.9.5530
199.58 Avg FPS

Nightly
211.73 Avg FPS

Nightly with OpenCL (GTX670)
217.19

 

[Edgemeal]

UPDATE:
I removed the results because some used a nightly build and it really didn't make much sense for comparison anymore.

See the OP here.

 

[Edgemeal]

AMD Phenom II X2 550 @ stock (3.1GHz) DDR3-1333 9-9-9-24-33-1T
HandBrake 0.9.9.5530 - 64bit Version
OS: Microsoft Windows NT 6.2.9200.0 (Windows 8.1 Pro Preview)

[14:36:40] starting job
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSEMisalign LZCNT
x264 [info]: profile Main, level 3.0
[14:41:18] work: average encoding speed for job is 51.558769 fps

 

[JoeRambo]

well, it looks like just going for the last version or the "nightly build" gives a 5% gain with all the rest unchanged...
.

It does, actually it gives even more epic increase for Haswell, but that is due to the fact that nighly build of Handbrake is running newest version of x264 that supports AVX2.

if you look @ http://x264.nl/x264/changelog.txt, you will see that all AVX2 and plenty of other optimizations were done after 0.9.9 handbreak (with x264 r2273) was released.

Ofc "native" compilation can still help, but low hanging fruit is already eaten long ago.

 

[BallaTheFeared]

Latest score chart update...

If you want my ram timings they're here: http://forums.anandtech.com/showpost.php?p=35201583&postcount=36

2400MHz 11-13-12-28 1T

 

[gbeirn]

HandBrake svn5618 (Nightly Build) - 64bit Version
OS: Microsoft Windows NT 6.1.7601 Service Pack 1
CPU: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz
Ram: 12278 MB, Screen: 1920x1080

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: profile Main, level 3.0
[18:23:14] reader: done. 1 scr changes
[18:23:14] work: average encoding speed for job is 170.469330 fps

 

[MrPickins]

Reran using the latest stable version:

HandBrake 0.9.9.5530 - 64bit Version
OS: Microsoft Windows NT 6.1.7601 Service Pack 1
CPU: Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz (really 4.2GHz)
Ram: 8079 MB DDR31600

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI1 BMI2
work: average encoding speed for job is 232.463257 fps

Previously (using Nightly build 5616):


using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
[14:01:24] work: average encoding speed for job is 253.857376 fps

Nightly build is definitely faster.

 

[Edgemeal]

Reran using the latest stable version:

Nightly build is definitely faster.

I didn't pay any attention to what versions people were using, some posted using released version and others used night builds!

Hmmm looks like you gained about 9% on a night build! :sneaky:

 

[avatar82]

HandBrake svn5618 (Nightly Build) - 64bit Version
OS: Microsoft Windows NT 6.2.9200.0

vintage 2009 D0 i7-920 @ 4.2Ghz
ancient OCZ 3x2=6GB 192bit channel @ 1600Mhz CAS 888 1T
Windows 8-64bit

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2
x264 [info]: profile Main, level 3.0
[23:02:38] reader: done. 1 scr changes
[23:02:38] work: average encoding speed for job is 230.800461 fps

 

[ZOXXO]

AMD Opteron 175
Windows XP

x264 [info]: using cpu capabilities: MMX2 SSE2Slow SlowCTZ
x264 [info]: profile Main, level 3.0
[00:48:42] reader: done. 1 scr changes
[00:48:46] work: average encoding speed for job is 22.679539 fps

 

[bbhaag]

Bummer my version of Handbrake doesn't have the Android preset. I was looking forward to posting up my results.

 

[inf64]

Update, downloaded latest Nightly build:

750K @ 4.3Ghz (2 PD modules/4 threads),8GB DDR3 @ 1600Mhz
windows 7 x64

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
[12:21:37] work: average encoding speed for job is 126.983131 fps

 

[monstercameron]

Update, downloaded latest Nightly build:

750K @ 4.3Ghz (2 PD modules/4 threads),8GB DDR3 @ 1600Mhz
windows 7 x64

x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 SSEMisalign LZCNT BMI1
[12:21:37] work: average encoding speed for job is 126.983131 fps

interesting, my 965BE is only clocked at 4GHz, doesnt use [SSSE3 SSE4.2 AVX XOP FMA4 FMA3 BMI1] has slower ram yet, I beat your 750k [although I was using ubuntu].

anyone know why this is? is it just operating environment? or cpu itself?

 

[inf64]

interesting, my 965BE is only clocked at 4GHz, doesnt use [SSSE3 SSE4.2 AVX XOP FMA4 FMA3 BMI1] has slower ram yet, I beat your 750k [although I was using ubuntu].

anyone know why this is? is it just operating environment? or cpu itself?

Your 965BE has 4 FP units, my PD has 2 that are dual threaded (still doesn't make up for the fact there is 2x the disparity in unit count) . I think its impressive that 2 dual threaded FP units can come so close to 4 dedicated ones. I'd say if workload could potentially benefit from FMA3/4 that my lowly PD would just crush that 965 with 50+% delta (as it would be able to *potentially* execute 2x ops per cycle with FMA). x264 is AVX tuned so in this case peak throughput of PD core remains unchanged (well maybe +5% due to SSE->AVX).

 

[SPBHM]

Your 965BE has 4 FP units, my PD has 2 that are dual threaded (still doesn't make up for the fact there is 2x the disparity in unit count) . I think its impressive that 2 dual threaded FP units can come so close to 4 dedicated ones. I'd say if workload could potentially benefit from FMA3/4 that my lowly PD would just crush that 965 with 50+% delta (as it would be able to *potentially* execute 2x ops per cycle with FMA). x264 is AVX tuned so in this case peak throughput of PD core remains unchanged (well maybe +5% due to SSE->AVX).

AMD calls a dual module CPU "Quad Core", and dual module CPUs replaced "native quad cores CPUs" in price (AII X4, PII X4 955)

still, is no surprise that PII and C2Q can do well in this.

 

[inf64]

I know what they call it, I'm just stating the facts of what's inside of the design . The fact is it's 4 dedicated FP units (128bit add+128bit mul each) Vs 2 shared units that can do 2 threads each ( each having 2 multipurpose pipes that either do muls,adds or FMAs). So effectively in legacy code , with X4 Deneb vs 2M PD you have : 4 mul+4 add 128bit pipes Vs 4 128bit mull/add pipes. The performance in the end is somewhat similar (still Deneb is ~15-20% faster) which tells you that shared SMT unit in PD is much more efficient than the dedicated one in Deneb (~50% more ops/cycle roughly in legacy code and much more in FMA). This is due to the fact that fully loading the dedicated FP unit in "normal" code (non Linpack) is very hard thing and PD takes advantage of this.

 

[lamedude]

Video encoding is mostly (entirely?) integer though. My guess its the front end that's the bottleneck as a quad core Ph2 can decode 12 instructions compared a 2 module FX's 8.

 

[inf64]

Video encoding is mostly (entirely?) integer though. My guess its the front end that's the bottleneck as a quad core Ph2 can decode 12 instructions compared a 2 module FX's 8.

There is no bottleneck as FX8xxx just crushes every other AMD chip ( OCed X6 included). You can see in the table that 1st gen BD based FX6100 @ 4.1Ghz scores ~170pts vs ~184pts (average ) of X6 @ 4Ghz. That's basically ~10% difference while having 2x less dedicated FP hardware-an amazing showing by BD/PD .

PS Anything SSE (packed integer) is still done on FlexFP unit.