15" MacBook Pro 2.33 GHz C2D 5400rpm

Post your testing results with HandBrake.
Post Reply
Posts: 14
Joined: Thu May 03, 2007 9:10 pm

15" MacBook Pro 2.33 GHz C2D 5400rpm

Post by kdv »

Just thought I'd post my results after following the instructions in this torrent:

Handbrake 0.8.5b1 finished in 2m16s and averaged 17.78 fps.

I ran the test a second time with Activity Monitor open and noticed that Handbrake never went above 124% (or 62% per core) CPU utilization.

Does anyone know why Handbrake doesn't utilize all the CPU resources available?
Posts: 886
Joined: Tue Jan 02, 2007 8:21 am

Post by baggss »

The best answer I can give you is below, it came from this thread:

http://handbrake.m0k.org/forum/viewtopi ... =cpu+usage

w00t wrote:Yup I'm aware of that, but it still doesn't explain why 20-30% of the CPU is idle...

Infact, that's an entire 2Ghz Xeon core sitting there twiddling it's thumbs :P

The thing is that in order for any given CPU Core to be busy it must have some 'unit of work' to perform. For a threaded application like HandBrake (and ignoring for the moment any other applications that may be running) if there are fewer threads with work to do than cores that means one core will be busy.

From my brief examination of the Handbrake threading model (and it's not something I've looked at in detail - so please correct me if I'm wrong), it looks like handbrake creates threads to handle :

a) Reading Data
b) Decoding the original format (ie decoding MPEG-2)
c) Encoding the new format (ie encoding H.264)
d) Writing the data

That would appear to be 4 threads but really only 2 (b & c) are actually busy. a & d have relatively little work to do, in fact so little (by comparison) that they may quite easily 'fit' on to a single core. Hence you'll see a scenario where a core is un/under utilized.

More cores only means more performance if there's work for them to do. For Handbrake that means breaking up (b & c) to more threads but this is really pretty tricky since both H.264 and MPEG-2 leverage the commonality of data between frames to gain compression - so breaking things up is not as trivial as just saying 'Frame 1 here, frame 2 there, frame 3 here etc. etc.' Since Frame 3 can't be worked on without data from frames 1 & 2, we now how have a dependancy between threads that means one will wait for the other and there's no longer any gain.

Designing algorithms for effective use of multiple cores is tricky, but it's getting a lot of thought - especially since we're seeing desktop machines with 8 cores. Having paid for them you really don't want them idle.

Andrew 8-)

P.S. Look on the bright side though - if you have a core not working on Handbrake threads it's a core you can use for something else like surfing the web, reading email etc etc.
Posts: 14
Joined: Thu May 03, 2007 9:10 pm

Post by kdv »


Thanks for your answer. I hope the developers implement a way to use all of the cpu in later builds. They've done a great job so far.

Just for kicks I duplicated handbrake.app and ran two instances simultaneously off the same source. The total time to encode both videos was only 3m03s and both cores were maxed out. This is about 33% faster than if I had ran one instance of Handbrake to encode the video twice (which would take 4m32s). This make sense since all the processing power of the CPU is utilized rather than just 64%.

Anyways, good to know. :lol:
Posts: 14
Joined: Thu May 03, 2007 9:10 pm

Post by kdv »

using the latest build in svn (2007051101) i got much better speeds since both cores are being maxed out:

old (2007042001): 2m 16s - 17.78 fps

new (2007051101): 1m 32s - 26.61 fps

that's about a 32% improvement in encoding time. that correlates to the increase in cpu utilization from 65% to 99%.

kudos to the devs.
Posts: 4
Joined: Wed May 16, 2007 6:56 pm

Post by mgriffin34 »

Greetings all...

C2D 2.33 15" MBP with 160GB 5400RPM, 3GB RAM

Using 08.5b1 (2007042301)

H.264 (iPod), 640x368, 1450kbps, 2-pass

27.25fps after 8th item in queue.

Processors sitting around 137%

Awesome product!
Post Reply