Which Mac Pro To Get for Transcoding: 2008? 2009? (or iMac?)

[Hjiorst]

I am a moderately informed user but not as fast or informed as needed to understand all of the tech specs and alphabet soup I read in this forum (a lot, but not all). So I am seeking some advice on my particular quest and a check on the conclusions I have come to so far.

I have to start a brand new process: transcoding video from digital HD files to MPEG-1 files. Until now I have been using DV tape and encoding cards, a slow but simple process with few things to think about. But it's time to move up. I will be recording in AVCHD files and sometimes SD AVI files. I need to end up with MPEG-1 files between 90 and 120 minutes in length. My research has led me to Sorenson Squeeze 7 as the transcoder, but, in order to join the many 2GB files created while recording these long takes, I need to load them into Final Cut Pro timelines (currently using FCP 6) and export through Squeeze. So I need to get a new Mac instead of a PC.

I will normally have to make 3 - 4 timelines per day's work, but very occasionally getting up to 12. I figured I would set up all the timelines and run them through Squeeze overnight. Sorenson says that it can make use of multiple cores and do simultaneous encoding with them, so that means more cores means all the work gets done faster, right? This will be a vast improvement over my one-tape-at-a-time system, right?

Note, I did test Squeeze 7 on my laptop (a dual-core PC), and found that it does, indeed, use both cores at fairly high capacity.

So, given that, and given that I cannot afford the newest 12-core Mac Pros, I am looking for a used system. But should I get an 8-core 2008 version, or should I try to find a 2009 Quad-core?

I've heard it said that the newer quad core processors are faster than the 2008 8-core systems. Is this true?

Or, better still, should I dig in and get a 2009 8-core? Will I really need that much power? Or are all these overkill, and should I just find an iMac and save some $ and space?

On a side-tack: I've also read that FCP will not make use of multiple cores for editing. Will that be the case with exporting through a third-party application like squeeze? Will it only let me access one timeline at a time?

Any assistance you may render would be most appreciated. Thanks!

-Hjiorst

 

[fluidedge]

If time is not of absolute essence (ie you can do all your work over night =10 hours or so) I'd certainly go for an 8 core 2008.

The 2009 machines were a bit of a let down and dont warrant the extra price IMO.

Alternatively what about a mac mini render farm

 

[derbothaus]

Really? So hyperthreaded cores + turbo boost, effectively almost doubling each core is not a worthy speed bump. Test scores confirm otherwise.

Fastest models for 2008, 2009. Numbers from Mactracker Geekbench averages.

3.2GHz 2008 8-core: 8565
2.93GHz 2009 8-core: 14904

Even the single 2.93GHz Quad gets it over the 3.2GHz 8-core 2008: 9112

And yes, using geekbench for general transcoding performance gives a good representation.

 

[Transporteur]

Really? So hyperthreaded cores + turbo boost, effectively almost doubling each core is not a worthy speed bump. Test scores confirm otherwise.

Fastest models for 2008, 2009. Numbers from Mactracker Geekbench averages.

3.2GHz 2008 8-core: 8565
2.93GHz 2009 8-core: 14904

Even the single 2.93GHz Quad gets it over the 3.2GHz 8-core 2008: 9112

And yes, using geekbench for general transcoding performance gives a good representation.

I honestly doubt that geekbench gives a reasonable, yet good, representation of the system's actual performance.

The boost from Hapertown to Nehalem was about 20 to 30% clock per clock (real world performance test, not a 5 second run of Geekbench), not even close to the 100% increase Geekbench reports for the 3.2 quad vs. 3.2 octad.

Sure the 3.2 quad Nehalem will be faster in single threaded tasks because of the improved clock per clock performance and turbo boost, but in multithreaded tasks, the 3.2 octad will be faster, no doubt.

 

[derbothaus]

I honestly doubt that geekbench gives a reasonable, yet good, representation of the system's actual performance.

Generally speaking you are right. It is only a guidepost. I am already negating all other aspects of 2008, 2009 HW (Bus speeds, HDD's) as the 2 are so similar it is almost dismissive. But for something like Squeeze that can make use of all threads it is definitely a test you can take into consideration as it hits all cores fairly evenly. A well written app that makes similar use should have pleasant scaling. But there are Squeeze bench numbers out there somewhere which would be the true answer of whether the 2008 or 2009 is best for their purposes. I don't have time right now to find them.

not even close to the 100% increase Geekbench reports for the 3.2 quad vs. 3.2 octad.

Where are you getting this from? My average numbers indicate 3.2 Quad at 10030 and 3.2 2008 Octad at 8565. That is nowhere near 100%. It's closer to the 20% claimed earlier. Also shows that thread management is working correctly as both machines are utilizing 8 threads with the win going to the 3.2 Quad (on account of the 20% clock for clock improvements)

 

[Transporteur]

Where are you getting this from? My average numbers indicate 3.2 Quad at 10030 and 3.2 2008 Octad at 8565. That is nowhere near 100%. It's closer to the 20% claimed earlier. Also shows that thread management is working correctly as both machines are utilizing 8 threads with the win going to the 3.2 Quad (on account of the 20% clock for clock improvements)

Simple math. At identical core frequency (3.2GHz), according to geekbench the quad delivers the same (or even more) performance than the octad. That's a 100% increase (50% the core count, yet identical performance). Even more if you take the exact numbers (8500 vs 10000) into account.

 

[derbothaus]

All this sounds right if hyperthreading is working as it should in any app. The same number of threads can be addressed. But you are correct that Geekbench is a little overkill on the real world gains if this test is any indication.
Barefeats Geekbench and Cinebench numbers.
http://www.barefeats.com/wst10.html

Look at the 2.8 8-core and 2.8 4-core. Geekbench has them neck in neck and on Cinebench the "true" 8-core pulls ahead. I would assume the 3.2's would look similar against one another. Point taken

 

[Hjiorst]

Wow, thanks for the input! Looks like I see here the same disagreements I've read elsewhere. Perhaps it would be safe to assume that even if I get the less expensive 2008 unit I'll still have a powerful computer that will do the job. I don't think the amount of work I'm processing will over-tax a 2008.

I'm still concerned that my scheme of working through multiple FCP timelines will prevent access to multiple cores, thus dashing all my plans. But I guess there's only one way to check this out...

 

[Transporteur]

All this sounds right if hyperthreading is working as it should in any app. The same number of threads can be addressed.

Hyperthreading does make a small difference for highly multithreaded tasks, but can never make up for real cores.

 

[derbothaus]

Perhaps it would be safe to assume that even if I get the less expensive 2008 unit I'll still have a powerful computer that will do the job.

This is correct.

I'm still concerned that my scheme of working through multiple FCP timelines will prevent access to multiple cores, thus dashing all my plans. But I guess there's only one way to check this out...

You should be fine. FCP will not use multiple cores. But multiple timelines may dip into extra resources. When you offload to Squeeze for compression FCP is taken out of the mix and all your cores should start working the material through Squeeze. Also testing multicore against a dual core is not really a great way to forecast performance as iTunes and any other SW will use both the cores of a dual core chip. Never seen a dual core not appear to be using both cores. More of a load balancing thing. At least with the reporting tools available. Good luck!

 

[bearcatrp]

If money is tight, a 2008 8 core Mac pro will do you for awhile. Still pretty strong machine. It's 64 bit EFI so the new FCP should work on it, and use all cores too.

 

[Hjiorst]

You should be fine. FCP will not use multiple cores. But multiple timelines may dip into extra resources. When you offload to Squeeze for compression FCP is taken out of the mix and all your cores should start working the material through Squeeze.

This is good news, or a hopeful prediction, at least. It seems that, although the hardware these days is opening up multiple processing (both with multi-core hyperthreading and CUDA GPU based processing), a lot of software lags behind in the ability to make use of it. And if it can, some other software might interfere. I hope you're right about FCP. It sounds like you know what you're talking about.

Also testing multicore against a dual core is not really a great way to forecast performance as iTunes and any other SW will use both the cores of a dual core chip. Never seen a dual core not appear to be using both cores. More of a load balancing thing. At least with the reporting tools available. Good luck!

This is weird, to me, the not-fully-informed consumer. Unfortunately I can't remember all the details of my test, such as whether Squeeze was running one encode or two when I checked core usage and saw each was running at about 65%. But the documentation from Sorenson say it makes use of multiple cores, so that's what's important.

Here's a weird thing about my particular task: Squeeze can ramp up to 100% usage for H264 encoding, but since MPEG-1 files are antiquated (from the Nixon era, I believe), they haven't spent any time or development on improving it, and so it will not crank the encoding through at the highest capacity the processor can do. This is why multiple cores for simultaneous encoding is important for me. Maybe I can't get one file made faster, but I can run 8 (or 16) files at the same time and get the lot done faster. That's my theory, anyway.

 

[derbothaus]

This is why multiple cores for simultaneous encoding is important for me. Maybe I can't get one file made faster, but I can run 8 (or 16) files at the same time and get the lot done faster. That's my theory, anyway.

Sounds like a very accurate theory indeed. With 8 cores you'll have 800% CPU headroom (reporting). So if 1 encode is using 100% of 1 core you can send more jobs to the rest of the available cores to fully saturate the processors. How well Sorenson does this remains to be seen but you'll probably get at least 3 encodes done in the same time as the 1 took previously. Maybe more. Or Squeeze will saturate all available cores and each encode will be faster. Either way a win.