CS5 Render Speed at DVinfo.net

Paul Matwiy · June 7th, 2010, 08:43 AM

I thought you’d be interested in my performance test with CS5. I’m using the same project for both as a comparison (90 minute 1440 x 1080 project, originally HDV but transcoded to the Cineform intermediate codec.

Baseline Verari, dual 3 GHz Opteron, 8 GB RAM, PP CS4, Quadro FX, Vista 64

Output: MPEG-2, 1920 x 1080i, 29.97 – 4 hrs 20 min.
MPEG-4 1920 x 1080p, 29.97 – 12 hrs 38 min.

Supermicro dual 2.6 GHz, hexa-core Opteron, 8 GB RAM, PP CS5 with Mercury enabled (GTX470), Win 7/64

Output: MPEG-2, 1920 x 1080i, 29.97 – 1 hrs 48 min.
MPEG-4 1920 x 1080p, 29.97 – 4 hrs 36 min.

I’ve monitored processor and system temps on the Supermicro. The MPEG-2 export used all 12 cores at approx 85%. Temps stabilized at 56 & 61 for the two CPUs. MPEG-4 encodes dropped core utilization to 60% and the thermal load went down to 48 and 53 degrees C.

Quite an improvement from my perspective.

Don Blish · July 6th, 2010, 08:58 AM

This was a great post that encouraged me to get a curent Quadro card and not wait for a power-hungry fermi based version.

I took a 100 minute CS5 sequence of HDV (cineform intermediate) and stills and brought it into Encore for a BluRay disc. This action used to take about 10x running time of the footage. My 100 minutes encoded to MPEG2 at 25mbps in 160 minutes and then muxed into a disc image in 13 more minutes....so I got the 4x speedup promised.

One very interesting thing I observed that bears on how fast the rest of the system needs to be to feed a Quadro FX 3800 is the profile of CPU activity. My CPU fan suggested and the Win7 task manager confirmed that the system would spool up to 100% for about 6 seconds to feed the Quadro then fall back to almost zero for about 12 seconds. This suggests that when Nvidia Fermi based cards deliver on the doubled core count, my basic system would still be adequate!.

Intel i7-975 (3,3Ghz) [a hyperthreaded quad, not hex core]
ASUS P6T Delux V2 motherboard
12 GB DDR3 1333 RAM
Win7 64 on single 7200 RPM disc
stills and Cineform HD footage on a pair of WD 7200rpm 1.5 TB drives striped RAID0

Harm Millaard · July 6th, 2010, 10:47 AM

First let's be clear about what both of you meant, because the heading may confuse people:

Rendering is meant for preview purposes of the time line.

Encoding is for export purposes, usually via AME.

Rendering profits significantly from hardware accelerated MPE. No doubt.

Encoding does not use hardware accelerated MPE. If you see significant performance gains in comparison to CS4, that is caused by the 64 bit engine, better memory management and better optimization. There is no difference in MPEG2-DVD or H.264 encode times with MPE on or off.

Don Blish · July 6th, 2010, 11:18 AM

I am not sure you are fully correct regarding encoding. My understanding is that CS5 encoding now includes or replicates the functionality of the "Elemental Accelerator" that was an aftermarket addon to CS4 to use the GPU of Quadro cards. This is complementary to the Murcury Playback engine.

If the encode was using only the CPU and not some other device like the GPU, utilization would have gone to 100% and stayed there till the project was done!

Harm Millaard · July 6th, 2010, 11:44 AM

CPU utilization depends on what the CPU is waiting for. It can be memory to deliver results, it can be disk activity to tell that it has finished reading or writing the required data and only with very fast disk setups and fast video cards will the CPU load be high. If you have a lacking disk setup, it can well be the CPU load will not go over a figure far below 100%, because it is continuously waiting for the disk(s) to finish before the CPU can continue.

In fact, CPU loads can be used to find bottlenecks in the system. For instance with only 6 GB memory, CPU loads will be lower than with 12 GB memory, due to the waiting. Same with disks.

BTW, no MPE acceleration during Encodes was told me by an engineer on the Scully team and I tend to believe these guys/girls.

Steve Kalle · July 6th, 2010, 12:18 PM

Both of you are partially correct. When exporting a timeline, Premiere still needs to RENDER any changes to the source video and then AME ENCODES. MPE is used for Rendering but NOT encoding. I tested this myself with H264, MPEG2 & FLV by turning MPE acceleration on and off. All I did was place a single clip in the timeline and queued it in AME. It is very unfortunate that Adobe couldn't have been bothered to speed up encoding like the Elemental Accelerator does.

On a side note, it is also unfortunate that all of these codecs are poorly threaded and also that AME cannot export more than one file at a time. With my dual-6 core HP Z800, it takes about 20% to export H264. FLV is the worst, only using 1 or 2 cores.

Don Blish · July 6th, 2010, 03:50 PM

Well, properly mutltithreaded apps on my machine will drive it to 100% and keep it there so I don't think I have a RAM or RAID thruput bottleneck.

Adobe personnel may not know what Main Concept did to get the big performance bump. More address space and cache under 64bit do not necessarily speed things up.

Anyone out there have both CS4 and CS5 but NOT have a qualifying GPU want to run an encoding speed comparison?

Harm Millaard · July 6th, 2010, 05:14 PM

With an ATI HD4870 the same MPEG2-DVD encoding test with CS4 and CS5 took 24.6 seconds with CS4 and 6.4 seconds with CS5, almost 4 times faster.

@ Steve: I said render profits greatly from MPE, encoding does not use MPE. So where is the partial?

Steve Kalle · July 6th, 2010, 05:19 PM

On my home workstation, I have CS4 & CS5, and I did test both with an identical project. I did see a 10% increase in export speed with CS5 using 1080p XDCAM EX to 720p H264 (this was w/ an 8800GT non-accelerated GPU). I also ran a test with 3 layers of AVCHD to see how much MPE acceleration helps. With 8 MPE accelerated effects on each layer and using a GTX 275 (w/hack), it only took 9 mins vs 51 mins under CS4. FYI, my home PC only has an i7 920 at stock speed.

And just in case you are wondering about any bottleneck in my HP Z800, I have 6 2TB Seagate Constellation ES drives in Raid 5 for the source video and 4 1TB Seagate 7200.12 in Raid 10 for export. Thus, there is no possible way my Z800 has any bottleneck.

Harm Millaard · July 6th, 2010, 06:19 PM

I concur with these findings about CS4 versus CS5 and that is around the same results I got, but where is the partial?

Steve Kalle · July 6th, 2010, 07:30 PM

Harm, for partial, I was referring to your comment, "Rendering is meant for preview purposes of the time line."

I take that comment to mean that rendering is ONLY for preview purposes. However, I consider rendering to encompass exporting of the timeline as well because Premiere must render prior to encoding.

Btw, has there been any progress with PPBM5? Last I checked, my latest numbers hadn't been added for my Z800. Or do you not want to give up the crown, hahahaha ;p

Harm Millaard · July 7th, 2010, 12:27 AM

Steve,

Either today or tomorrow I will contact you with the hopefully complete CS5 version 2 test. Bill is finalizing his website with all the considerations, instructions and download link.

Paul Matwiy · July 7th, 2010, 06:00 PM

Harm,

Good catch and a nice clarification about the differences. And thanks to Steve for the additional clarification that both rendering and encoding/trans-coding occur when outputting files. As I work in the film industry, we have a lazy tendency to call any digital output "rendering".

One thing I did neglect to mention was that the original projects used for comparison employed the Cineform intermediate codec.

June 7th, 2010, 08:43 AM	#1
Paul Matwiy Regular Crew Join Date: Jul 2004 Location: Marin, CA Posts: 85	CS5 Render Speed I thought you’d be interested in my performance test with CS5. I’m using the same project for both as a comparison (90 minute 1440 x 1080 project, originally HDV but transcoded to the Cineform intermediate codec. Baseline Verari, dual 3 GHz Opteron, 8 GB RAM, PP CS4, Quadro FX, Vista 64 Output: MPEG-2, 1920 x 1080i, 29.97 – 4 hrs 20 min. MPEG-4 1920 x 1080p, 29.97 – 12 hrs 38 min. Supermicro dual 2.6 GHz, hexa-core Opteron, 8 GB RAM, PP CS5 with Mercury enabled (GTX470), Win 7/64 Output: MPEG-2, 1920 x 1080i, 29.97 – 1 hrs 48 min. MPEG-4 1920 x 1080p, 29.97 – 4 hrs 36 min. I’ve monitored processor and system temps on the Supermicro. The MPEG-2 export used all 12 cores at approx 85%. Temps stabilized at 56 & 61 for the two CPUs. MPEG-4 encodes dropped core utilization to 60% and the thermal load went down to 48 and 53 degrees C. Quite an improvement from my perspective. __________________ Paul

July 6th, 2010, 08:58 AM	#2
Don Blish Major Player Join Date: Oct 2003 Location: Portland OR Posts: 227	Great post - additional info This was a great post that encouraged me to get a curent Quadro card and not wait for a power-hungry fermi based version. I took a 100 minute CS5 sequence of HDV (cineform intermediate) and stills and brought it into Encore for a BluRay disc. This action used to take about 10x running time of the footage. My 100 minutes encoded to MPEG2 at 25mbps in 160 minutes and then muxed into a disc image in 13 more minutes....so I got the 4x speedup promised. One very interesting thing I observed that bears on how fast the rest of the system needs to be to feed a Quadro FX 3800 is the profile of CPU activity. My CPU fan suggested and the Win7 task manager confirmed that the system would spool up to 100% for about 6 seconds to feed the Quadro then fall back to almost zero for about 12 seconds. This suggests that when Nvidia Fermi based cards deliver on the doubled core count, my basic system would still be adequate!. Intel i7-975 (3,3Ghz) [a hyperthreaded quad, not hex core] ASUS P6T Delux V2 motherboard 12 GB DDR3 1333 RAM Win7 64 on single 7200 RPM disc stills and Cineform HD footage on a pair of WD 7200rpm 1.5 TB drives striped RAID0

July 6th, 2010, 11:18 AM	#4
Don Blish Major Player Join Date: Oct 2003 Location: Portland OR Posts: 227	Encoding now using GPU I am not sure you are fully correct regarding encoding. My understanding is that CS5 encoding now includes or replicates the functionality of the "Elemental Accelerator" that was an aftermarket addon to CS4 to use the GPU of Quadro cards. This is complementary to the Murcury Playback engine. If the encode was using only the CPU and not some other device like the GPU, utilization would have gone to 100% and stayed there till the project was done!

July 6th, 2010, 03:50 PM	#7
Don Blish Major Player Join Date: Oct 2003 Location: Portland OR Posts: 227	Anyone for another test? Well, properly mutltithreaded apps on my machine will drive it to 100% and keep it there so I don't think I have a RAM or RAID thruput bottleneck. Adobe personnel may not know what Main Concept did to get the big performance bump. More address space and cache under 64bit do not necessarily speed things up. Anyone out there have both CS4 and CS5 but NOT have a qualifying GPU want to run an encoding speed comparison?

July 7th, 2010, 06:00 PM	#13
Paul Matwiy Regular Crew Join Date: Jul 2004 Location: Marin, CA Posts: 85	Rendering and encoding Harm, Good catch and a nice clarification about the differences. And thanks to Steve for the additional clarification that both rendering and encoding/trans-coding occur when outputting files. As I work in the film industry, we have a lazy tendency to call any digital output "rendering". One thing I did neglect to mention was that the original projects used for comparison employed the Cineform intermediate codec. __________________ Paul

July 6th, 2010, 10:47 AM	#3
Harm Millaard Trustee Join Date: Aug 2006 Location: Rotterdam, Netherlands Posts: 1,832	First let's be clear about what both of you meant, because the heading may confuse people: Rendering is meant for preview purposes of the time line. Encoding is for export purposes, usually via AME. Rendering profits significantly from hardware accelerated MPE. No doubt. Encoding does not use hardware accelerated MPE. If you see significant performance gains in comparison to CS4, that is caused by the 64 bit engine, better memory management and better optimization. There is no difference in MPEG2-DVD or H.264 encode times with MPE on or off.

July 6th, 2010, 11:44 AM	#5
Harm Millaard Trustee Join Date: Aug 2006 Location: Rotterdam, Netherlands Posts: 1,832	CPU utilization depends on what the CPU is waiting for. It can be memory to deliver results, it can be disk activity to tell that it has finished reading or writing the required data and only with very fast disk setups and fast video cards will the CPU load be high. If you have a lacking disk setup, it can well be the CPU load will not go over a figure far below 100%, because it is continuously waiting for the disk(s) to finish before the CPU can continue. In fact, CPU loads can be used to find bottlenecks in the system. For instance with only 6 GB memory, CPU loads will be lower than with 12 GB memory, due to the waiting. Same with disks. BTW, no MPE acceleration during Encodes was told me by an engineer on the Scully team and I tend to believe these guys/girls.

July 6th, 2010, 12:18 PM	#6
Steve Kalle Trustee Join Date: Aug 2009 Location: Chicago, IL Posts: 1,554	Both of you are partially correct. When exporting a timeline, Premiere still needs to RENDER any changes to the source video and then AME ENCODES. MPE is used for Rendering but NOT encoding. I tested this myself with H264, MPEG2 & FLV by turning MPE acceleration on and off. All I did was place a single clip in the timeline and queued it in AME. It is very unfortunate that Adobe couldn't have been bothered to speed up encoding like the Elemental Accelerator does. On a side note, it is also unfortunate that all of these codecs are poorly threaded and also that AME cannot export more than one file at a time. With my dual-6 core HP Z800, it takes about 20% to export H264. FLV is the worst, only using 1 or 2 cores.

July 6th, 2010, 05:14 PM	#8
Harm Millaard Trustee Join Date: Aug 2006 Location: Rotterdam, Netherlands Posts: 1,832	With an ATI HD4870 the same MPEG2-DVD encoding test with CS4 and CS5 took 24.6 seconds with CS4 and 6.4 seconds with CS5, almost 4 times faster. @ Steve: I said render profits greatly from MPE, encoding does not use MPE. So where is the partial?

July 6th, 2010, 05:19 PM	#9
Steve Kalle Trustee Join Date: Aug 2009 Location: Chicago, IL Posts: 1,554	On my home workstation, I have CS4 & CS5, and I did test both with an identical project. I did see a 10% increase in export speed with CS5 using 1080p XDCAM EX to 720p H264 (this was w/ an 8800GT non-accelerated GPU). I also ran a test with 3 layers of AVCHD to see how much MPE acceleration helps. With 8 MPE accelerated effects on each layer and using a GTX 275 (w/hack), it only took 9 mins vs 51 mins under CS4. FYI, my home PC only has an i7 920 at stock speed. And just in case you are wondering about any bottleneck in my HP Z800, I have 6 2TB Seagate Constellation ES drives in Raid 5 for the source video and 4 1TB Seagate 7200.12 in Raid 10 for export. Thus, there is no possible way my Z800 has any bottleneck.

July 6th, 2010, 06:19 PM	#10
Harm Millaard Trustee Join Date: Aug 2006 Location: Rotterdam, Netherlands Posts: 1,832	I concur with these findings about CS4 versus CS5 and that is around the same results I got, but where is the partial?

July 6th, 2010, 07:30 PM	#11
Steve Kalle Trustee Join Date: Aug 2009 Location: Chicago, IL Posts: 1,554	Harm, for partial, I was referring to your comment, "Rendering is meant for preview purposes of the time line." I take that comment to mean that rendering is ONLY for preview purposes. However, I consider rendering to encompass exporting of the timeline as well because Premiere must render prior to encoding. Btw, has there been any progress with PPBM5? Last I checked, my latest numbers hadn't been added for my Z800. Or do you not want to give up the crown, hahahaha ;p

July 7th, 2010, 12:27 AM	#12
Harm Millaard Trustee Join Date: Aug 2006 Location: Rotterdam, Netherlands Posts: 1,832	Steve, Either today or tomorrow I will contact you with the hopefully complete CS5 version 2 test. Bill is finalizing his website with all the considerations, instructions and download link.