CS4 and 64-bit Systems, Part 2

In this month''s first installment, I discussed the technical aspects of 64-bit computing as it related to Adobe Creative Suite 4 (CS4) performance. In this installment, I''ll detail the head to head tests between a 2.83GHz HP xw6600 workstation running Windows XP (32-bit version) with 3GB of RAM and a 3.33GHz HP xw8600 workstation running 64-bit Vista with 16GB of RAM. Both workstations have dual, quad-core processors for a total of eight cores.

From a strict processor-to-processor comparison, the xw8600 should be about 18 percent faster simply because of processor speed, 2.83GHz compared to 3.33GHz. To account for this, in addition to presenting raw scores, I also showed adjusted scores that reduced the encoding times of the 6600 by 18 percent.

Figure 1. PProHeadless.exe. To see this view of Windows Task Manager, click ctrl+alt+del and click the Processes tab.
Click here for a larger image

Before getting started, let''s review one fact about CS4 that didn''t quite make it up to the top of the new feature list: it requires a lot more memory for the same operations. For example, when rendering the HDV multicam project referred to below to Blu-ray-compatible MPEG-2 format, CS3 consumed 1.03GB of memory, while CS4 required 1.80GB.

Related Links

CS4 and 64-bit Systems, Part 1 So there I was, testing Adobe Creative Suite 4 (CS4)''s AVCHD compatibility. I created a simple project, about 4 minutes long, two picture-in-picture overlays with simple rotation and color correction... Test Drive: Nvidia Quadro CX and Adobe CS4, Part 1 This month, in our quest to identify the optimal CS4 configuration, we look at graphic chip manufacturer Nvidia''s Quadro CX technology... Test Drive: Nvidia Quadro CX and Adobe CS4, Part 2 This month, we're looking at how Nvidia's Quadro CX technology (around $2,000 at B&H Photo Video) can accelerate performance in Adobe Creative Suite 4 (CS4)...

To be fair, as mentioned in the first installment, Adobe is recommending 64-bit systems for CS4, but to my recollection, that message came rather late. Nonetheless, the additional memory requirements make perfect sense; when Adobe architected Encore and Adobe Media Encoder (AME) to import Premiere Pro sequences directly, the company had to create some program that could render the sequences separately—kind of a Premiere Pro sequence interpreter. You won''t see this program running, but obviously it needs memory to run.

This is the PProHeadless.exe program that you can see in Figure 1, which inputs a Premiere Pro sequence, renders all edits, and hands off rendered frames in some easily recognizable intermediate file to AME and Encore. In addition to this application, Adobe also had to beef up the functionality of AME so it could operate as a standalone program, which also requires more RAM.

This brings to mind the phrase TANSTAAFL—which, for those sad souls who didn''t voraciously consume Robert Heinlein in their youth, stands for “There Ain''t No Such Thing As A Free Lunch.” The dish Adobe is serving up—separate operation for Encore and Adobe Media Encoder—is quite tasty, but the unadvertised price is that you might need to step up to a 64-bit system to really enjoy the fare.

I ran multiple tests using as many types of source files as I could find on my various hard disks (DV, HDV, AVCHD, DVCPRO HD) or download from the web (Red Digital Cinema). My general procedure was to create a test on the 32-bit system, copy the project file and content to the 64-bit system, then run the tests side by side recording Commit charge, processor utilization, and encoding time.

I kept most projects about 1 minute in length, and all employed a mixture of picture-in-picture, greenscreen, color correction, and relatively common effects. With each format, I included greenscreen both natively within Premiere Pro and via Dynamic Link from After Effects. I created all projects using native format presets in Premiere Pro and rendered to either DVD-compatible MPEG-2 (DV) or Blu-ray-compatible MPEG-2 (all HD formats).

Table 1. DV files.
Click here for a larger image

My assumption entering this analysis was that working with relatively simple DV files would require less memory than the HD formats, so would run equally efficiently on both systems. Boy, was I wrong. The reality was that the 64-bit system proved much speedier than the 32-bit system in both test scenarios.

Most of the results are self-explanatory, but let me explicate just a bit. As mentioned, the first project used native greenscreen controls, and the second used the Keylight filter from After Effects via Dynamic Link. The impact on the amount of required RAM was dramatic, from 1.8GB to 2.41GB on the 32-bit system—though, somewhat surprisingly, it didn''t improve the 64-bit system''s comparative performance. Still, without Dynamic Link, the 64-bit system was 67 percent faster; with Dynamic Link, it was 41 percent faster.

Table 2. HDV files.
Click here for a larger image

While DV is a relatively simple intraframe-only only format, HDV is long GOP MPEG-2, which means all those complicated and inter-related I, B, and P frames. HDV is obviously also HD, while DV is SD, which means lots more pixels per frame, so I expected a significant difference in performance between the two systems. However, my results were project-dependent.

Using a four-camera multicamera HDV benchmark that I''ve used in the past, the systems were roughly identical in performance after correcting for processor speed (test 1). This makes sense, because after choosing angles with the multicam tool, you''re left with one HDV stream that required only 1.6GB of RAM to render. Add an overlay from After Effects, however, and RAM requirements jump to 2.5GB, which stresses out the 32-bit system, and it trailed the 64-bit system by 22 percent.

Project 3 was similar to the picture-in-picture tests that I created for the other HD formats. Though RAM requirements on the 32-bit system remained well below that consumed on the previous HDV test, the 64-bit system was still 62 percent faster than the 32-bit system—63 percent when working with an After Effects chroma key effect.

Table 3. AVCHD files.
Click here for a larger image

I didn''t reuse the AVCHD tests that prompted this analysis, since the test took too long to complete, but to recount the results, I rendered a 4-minute project to Blu-ray compatible MPEG-2, which took 68 minutes on the 32-bit workstation and about 9 minutes on the 64-bit workstation. The shorter tests that I ran for this article showed a clear benefit for the 64-bit system, though not to that extent.

Specifically, rendering a two-track project with a picture-in-picture, the 64-bit system was 31 percent faster. Throw in a native greenscreen, and the 64-bit system proved 50 percent faster. Surprisingly, however, substituting After Effects via Dynamic Link for Premiere Pro''s native greenscreen actually narrowed the gap back to 25 percent.

Why didn''t these results reproduce the greater than 600 percent margin recorded in my initial tests? Hard to say, but the results from the Red One camera, discussed below, may shed some light on the issue.

Table 4. DVCPro HD files.
Click here for a larger image

In contrast to the other 1080i HD streams such as HDV and AVCHD that use long-GOP compression, DVCPRO HD is essentially four DV streams, one for each quadrant. DVCPRO HD also has the fewest pixels to work with, with a native resolution of 1280x1080, compared to 1440x1080 for HDV and 1920x1080 for the AVCHD file. This makes it the easiest HD format to edit, and the format the showed the least benefit from working with a 64-bit system.

What is surprising was that editing DV showed more benefit from a 64-bit system than DVCPRO HD, which makes little sense, other then perhaps because the DV project was more complex. As Dick Cheney might say, however, it is what it is, and from where I sit, the only format that appears not to significantly benefit from a 64-bit system is DVCPRO HD.

Table 5. Red RD3 files.
Click here for a larger image

Running short on time, I ran only two tests with Red''s R3D format, a 4K picture-in-picture-based project with native greenscreen of yet another R3D file, and a picture-in-picture-based project with an After Effects green screen via Dynamic Link. On the second project, I reached a memory-related tipping point that explained why my first AVCHD test took so long to complete.

As you can see in Figure 2, while rendering this project, the total Commit Charge exceeded the 3GB of system RAM, which meant that Adobe Media Encoder had to store data on the system''s hard disk while rendering. This is also called “paging” to disk, and it substantially decreases performance because writing to and reading from disk is much less efficient than working with RAM.

Figure 2. Commit Charge. To see this view of Windows Task Manager, click ctrl+alt+del and click the Performance tab.
Click here for a larger image

While rendering this project, the 32-bit system made very little progress until I shut Premiere Pro down, which reduced the total commit charge to less than 3GB. From there on, rendering was faster, but overall, the 64-bit system was well more than 200 percent faster. Had I not shut Premiere Pro, the results probably would have equaled or exceeded the 600 percent difference seen in my initial AVCHD tests.

If you''re running CS4 on a 32-bit system and you''re experiencing unstable or very slow operation, check your commit charge. If you''re consuming all of your system RAM and paging to disk, that''s probably the cause of both problems.

Table 6. Burning DVD disc image/render in Adobe Media Encoder.
Click here for a larger image

The tests described above involved two main applications: Premiere Pro and Adobe Media Encoder, with an occasional appearance by After Effects courtesy of Dynamic Link. At least for my practice, they represent the most likely scenario: I finish one project, start to render it, and begin another.

Less frequently, I''ll start rendering a disc-based project in Encore, then start editing another in Premiere Pro, and perhaps even render that project. So, in this final test, I reproduced this scenario, rendering a project in Encore and then rendering the third AVCHD scenario described above (picture-in-picture, After Effects via Dynamic Link).

As you can see, this is another scenario where the total commit charge on the 32-bit system exceeded RAM, which meant that the system had to page to hard disk during rendering. Not surprisingly, the 64-bit system was 70 percent faster in this trial.

Rendering is only one measure of editing performance, and often it''s completely irrelevant if you''re not in a hurry. Still, it''s objective and easily measurable, and these rendering trials clearly show that a 64-bit system will deliver superior performance with most formats except DVCPRO HD. Though your mileage will certainly vary, I would guess that the more complicated the project, the more significance the performance boost.

If you''re upgrading from CS3 to CS4 on a 32-bit system, I recommend upping your RAM to your system''s maximum. If you download the trial version of CS4, run some short rendering benchmarks with the two versions to get a feel for whether your current system performs well with CS4. If your projects are extremely complex, you may find performance unacceptable. After upgrading, if you''re rendering and not editing, be sure to close Premiere Pro and any other unnecessary programs, because if you boost the commit charge beyond system RAM, you will probably slow rendering significantly.

If you''re buying a 64-bit system, purchase at least 8GB of RAM, as any less would require the same type of performance limiting paging experienced on the 32-bit systems.

That''s it, and I am out. Happy Holidays.