Back again, comparing the performance of an Apple MacBook Pro (3.06GHz Intel Core 2 Duo processor, 8GB of 1067MHz DDR3 RAM) with a Mac Pro (2.93GHz quad-core Nehalem Xeon CPUs with 18GB of 1067MHz DDR3 RAM) in a range of editing and encoding chores (read about the two computers’ specs). The Mac Pro has an obvious advantage in power; the big question is whether the speed advantage will be sufficient to outweigh the hassle of carrying (or shipping) a desktop computer around, rather than a notebook.
Table 1: Comparing rendering times for preview in Apple Final Cut Pro.
Apple Final Cut Pro tests: previewing
All projects are different, and editing responsiveness is difficult to objectively measure. During the real-world projects that I edited in Apple Final Cut Pro—which were all single-camera DV, AVCHD, or HDV shoots—I felt very little subjective difference in editing responsiveness, which was quite snappy on both platforms.
Month after month, one of the most widely researched topics on the millimeter site is the performance difference between an Apple Mac Pro and a MacBook Pro. Given that I have brand-new models of both computers in my office, it felt like it was time to revisit the issue…
Apple’s new Snow Leopard (or OS X 10.6) is the type of release that delivers incremental advancements on the surface, but exponential enhancements below the waterline–though many will take months, if not years, to truly start bearing fruit…
I have in my hands an Intel Nehalem-based Apple Mac Pro, specifically a 2.93GHz dual-processor, quad-core unit running Mac OS 10.5.7 with 12GB of RAM and an ATI Radeon HD 4870 driving a beautiful Apple LED Cinema Display…
To gain some objective results, I performed three tests on the two computers: first adding a 10-second Apple Motion title to an AVCHD project and rendering for preview, then rendering a 1-second cross-zoom transition, and then rendering a 10-second 720p greenscreen effect. The results are presented in Table 1 in seconds.
Though I don’t particularly enjoy waiting for Final Cut Pro to convert AVCHD footage to ProRes 422 during ingest, editing in ProRes is generally worth the wait, especially on lower-power computers—not that you have any choice. Probably because ProRes is so efficient, none of the results presented in Table 1 convince me that I need to take my Mac Pro on location. If you’re working with more complex or higher-data-rate footage, or more effects, your conclusion might be different.
Table 2. Final Cut Pro rendering times using the new Share output.
Final Cut Pro tests: rendering
Table 2 presents the results of rendering to the various formats presented. By way of background, the “Loose Strings” project was a single-camera widescreen DV shoot, and I rendered one song about 4 minutes long to the YouTube format using Final Cut Pro’s Share option.
For the “No Speed Limit” project, I imported 25 minutes of AVCHD video, grabbed a 4-minute song, and output an MPEG-2 file to include on a compilation DVD. Comparative import times were significantly longer on the MacBook Pro. Next time, I’ll remember to trim the AVCHD file before ingest and only grab what’s absolutely necessary.
Encoding to MPEG-2 took 181 percent longer on the MacBook Pro, and the total operation was 278 percent slower. This may not be significant if you can render overnight, but if you’re on a deadline, you better think seriously about packing up your desktop.
The last project was a 9:46 piano recital shot in AVCHD and rendered to H.264 for Blu-ray and MPEG-2. As the table shows, the MacPro blew the notebook away when producing H.264, and it was slightly more than twice as fast with MPEG-2.
Though the MacBook Pro looks pretty slow in the table, for perspective, I rendered the same source footage to MPEG-2 using a dual-core PowerPC G5, which was one of the last pre-Intel boxes and state-of-the-art in 2005. Rendering took 55:21, slightly less than twice as long as the MacBook Pro’s test. The MacBook Pro seems slow compared to the new Mac Pro, but it’s faster than any Mac available in 2005 and probably faster than the first generation of Intel-based Macs.
Table 3. Final Cut Pro rendering times outputting using the FCP > QuickTime reference movie (QTRM) > Compressor workflow.
Final Cut Pro tests: Share or QTRM?
For the record, I produced all files detailed in Table 2 using Final Cut Pro’s Share option, which renders directly from the Final Cut Pro timeline but doesn’t use Qmaster. After reviewing the results, I started wondering if the outcome would be different if I used the older workflow, which involved producing a QuickTime reference movie (QTRM) from Final Cut Pro, inputting that into Apple Compressor, then rendering with Qmaster. I decided to test output to MPEG-2 because that’s where the performance delta between the two systems was smallest.
Table 4. Sharing (without Qmaster) and using the traditional FCP > QTRM > Compressor workflow.
Using that workflow reduced processing times for both systems and produced a much greater performance disparity between the two systems. The obvious next question was how much faster the traditional approach was over sharing, which I show in Table 4.
As you can see, Qmaster boosted performance by 33 percent with the dual-core system, and a whopping 149 percent with the eight-core system. Given that Qmaster was designed to improve performance on multicore systems, this makes a lot of sense.
I like the ease and convenience of the new Share approach that Apple implemented in Final Cut Pro 7. Clearly, however, if you have a multicore computer and optimizing your rendering times is a priority, you should compare your results using this approach and the traditional QuickTime reference movie/Qmaster workflow.
Table 5. Rendering for preview trials in Adobe Premiere Pro.
Adobe Premiere Pro tests
I produced two projects on both computers with Adobe Premiere Pro: one a 14-minute, three-camera, mixed-format shoot (two HDV/one AVCHD) and one a dual-DV-camera shoot. I’ll admit that I cheated on the first and ingested the AVCHD file in Final Cut Pro so I could work in ProRes rather than native AVCHD. It’s not a workflow available to all Adobe producers, but one that’s worth checking out if you can ingest in Final Cut Pro.
In terms of responsiveness, using Premiere Pro’s multicamera monitor, the Mac Pro clearly displayed more frames per second than did the MacBook Pro, but the notebook gave me sufficient feedback for edit decisions. Since I usually have to tweak camera-angle changes on the timeline anyway, from an editing perspective, the MacBook Pro was more than acceptable.
To test timeline rendering performance, I inserted a 5-second title into a AVCHD/ProRes timeline and rendered for preview, and then I inserted a 10-second 720p greenscreen clip into a DV project and rendered for preview. Table 5 shows the comparisons. For meat-and-potatoes titles, the MacBook Pro does just fine, but if you’re doing a lot of precision greenscreen production, you’ll start to see some significant time savings from the Mac Pro.
Table 6. Rendering times from Adobe Media Encoder.
In terms of final rendering, Table 6 shows that the more complex the source video format, the greater the performance disparity between the two computers. The Winston concert was an 80-minute dual-camera DV shoot rendered to MPEG-2, and the Mac Pro was 135 percent faster. The JC Weaver concert was the mixed HDV/AVCHD shoot, and the Mac Pro was dramatically faster in both output formats.
Table 7. Encoding time with Sorenson Media Squeeze and On2 Technologies Flix Pro.
Streaming rendering tests
In addition to the editors, I compared the performance of two streaming encoding tools: Sorenson Media Squeeze and On2 Technologies Flix Pro. I found that comparative performance between the computers depended upon the format. For example, with MPEG-2, Squeeze could encode up to 16 files simultaneously, and it produced 16 files in roughly one-third the time of the MacBook Pro. With MPEG-4, Squeeze could only encode one file at a time. Though it was still much faster than the MacBook Pro, the difference wasn’t as stark.
I included Flix Pro because On2’s VP6 codec is relentlessly single-threaded, which means that it only uses a single CPU core in most applications. That’s why the performance difference was only 41 percent. There are workarounds for this, such as running multiple versions of Flix Pro simultaneously or using a program such as Telestream Episode Engine to run simultaneous encoding sessions for better multiprocessor efficiency.
Still, these results highlight the important point that the benefit that you reap from a multiprocessor computer depends upon how efficiently a program can use multiple cores. In this regard, in the future, Snow Leopard‘s Grand Central will make it much easier for programs to use the resources of a multicore computer (read more about Snow Leopard). Probably won’t change your life substantially in the next six months or so, but it’s a factor to consider going forward.
Overall, these results are decidedly dog-bites-man. Still, I hope these numbers help illustrate where the teeth are the longest and the bite most painful.
Table 8. Rendering times for Apple Final Cut Pro and Adobe Premiere Pro using a Verbatim SureFire 250GB drive in FireWire 800 and USB 2.0 modes.
Working with external drives
Much of the time when you produce video with a notebook, you have to store your source videos on an external drive. Since I had a Verbatim SureFire 250GB drive handy (available for around $100), with support for both FireWire 800 and USB 2.0, I thought that I would rerun some of my benchmarks and compare the results. Table 8 tells the tale.
While rendering a single-camera shoot in Final Cut Pro, FireWire 800 mode was actually slightly faster than the internal drive, and the USB mode was slightly slower. While rendering a three-camera shoot with Premiere Pro, FireWire 800 mode was 2 percent slower, compared to 17 percent slower in USB 2.0 mode.
Why so little difference in three of four results? In slower-than-realtime activities such as encoding, file retrieval from disc isn’t the bottleneck, so slower retrieval times don’t slow the overall process significantly. As shown in the Premiere Pro USB 2.0 results, retrieving five files simultaneously via USB is a bottleneck, resulting in a significant difference in encoding time.
What about the editing experience? Here’s the rub. Even in FireWire 800, Premiere’s multicam monitor lost audio/video sync after 10 or 15 seconds, complicating the edit. So if you’re planning multicam editing in either program (especially Final Cut Pro if you’ve ingested into PreRes), using a FireWire 800 or especially a USB external drive could be problematic. For many single-camera shoots, however, an external drive shouldn’t significantly affect production time.