Number of render threads - meaningless?

steveinco wrote on 1/21/2011, 1:46 PM
Hello all. I was testing number of render threads on a small test project. I have an 2.8 gHz i7 system with 8GB memory, a GTX-470 video card and a 1.3 TB Raid 0 hard drive system.

I was rendering 1280 X 720 Canon SX20is MOV files to Sony AVC for 1920 X 1080 Blu-ray, generating a AVC elementary stream.

Tests

Threads CPU/GPU Time
1 Thread CPU only 2:40
8 Threads CPU only 2:40
1 Thread with GPU 2:13
8 Threads with GPU 2:14

Using Task Manager with the resource monitor shows essentially the same CPU utilization no matter what the setting of threads or CPU/GPU usage. In portions of the timeline with straight video CPU utilization may only be around 21 - 25%. In portions os the timeline with effects or crossfades CPU utilization will go as high as 51%. The Resource Monitor does show addional threads appearing for the Vegas100.exe application as I go from 1 to 8 threads for rendering. However, it accounts for no difference in render time. So, what is the point?

Do any of you do see a difference on your systems?

Comments

Steve Mann wrote on 1/21/2011, 3:56 PM
Have you read the manual?

"This setting specifies the maximum number of threads that will be used for rendering files.

Increasing the setting will not increase performance beyond the number of available threads; for example, if you have a single-processor computer, choosing 2 will not improve rendering performance.

Decrease the setting if you have a multiprocessor (or multicore) computer and want to limit processor use or turn off multithreaded rendering. For example, if you had a dual-processor hyperthreaded computer, choosing 3 would allow you to keep one thread available for other tasks while rendering."

The render thread is the one that actually talks to DirectX and It sounds like your project just didn't need any more threads - or you don't have any more. Can't guess how many cores your PC has since you haven't filled out the system details in your profile.

Hulk wrote on 1/21/2011, 6:13 PM
The other possibility is that Vegas will use more threads than you specify unless you are doing some other task that requires them and then at that point will "let go" of the thread. This would explain your results being the same.

Wanna test it? Render the project again in multiple instances of Vegas.
Render one with 1 thread.
Render one with 4 threads.
Render one with 3 threads.
That should use all 8 threads. Results could be skewed a little bit since when the 4 thread render finishes first the other instances of Vegas will grab those available threads if my theory is correct.

I don't know but it might be fun to investigate.

Mark
MaxFiPro wrote on 4/22/2011, 12:51 AM
I discovered that by setting the maximum number of threads used for rendering to 1, I have eliminated what was apparently the source of all my troubles with regard to Vegas crashing while rendering, without incurring any performance penalty whatsoever. In addition, on my quad-core (9550 Yorkfield) WinXP32 system, changing this parameter from 4 down to 1 did not change the number of cores used during render at all. In fact this setting on my system does nothing except cause it to crash very frequently if it is set to anything but 1.

I am using Vegas Pro 8.0c, Intel Core 2 Quad 9550 (Yorkfield) CPU (2.83 GHz), 4GB RAM, 2TB RAID-0, MSI-GTX8800 video card, Windows XP Professional 32-bit.

I wonder if others have found this max threads setting to affect their frequency of rendering crashes? In my case I have not had a single crash since I set max threads to 1.
Adam L. wrote on 4/22/2011, 9:49 AM
MaxFiPro other cores can't process information unless one or more additional threads are created. There's a minimum of 3 threads for Vegas - the main thread and 2 worker threads. My guess is one execution thread, a UI thread, and a worker thread.

This topic piqued my interest to see what difference specifying the number of threads makes, and to see how the threads are distributed across cores. What I found was pretty surprising. I did a basic method of snooping to see what Vegas is up to - attaching Visual Studio 2008's debugger to Vegas' process.

I broke into the debugger with a project that had loaded when I started Vegas. It was a project that contained 1 multicam output clip, and 3 audio tracks. Looking at the threads Vegas owned I saw 3. I continued execution of Vegas and kicked off a render, then broke into the debugger again. There were still 3 threads owned by Vegas. My settings were to use 4 render threads.

Knowing that it was possible that Vegas might not have needed additional threads to render a single clip, I dumped 3 additional clips into the timeline, then set the opacity of all of them except the bottom layer to 50%. This way I knew Vegas had to process all of the tracks, and I figured if there was a prime opportunity to use additional threads to speed up rendering the multiple clips, this was it. I started rendering and broke into the debugger again. Still only 3 threads owned by Vegas.

Ok, so this was puzzling. I went into my settings and set render threads to 1, started rendering and broke into the debugger again. 3 threads running under Vegas. Increase threads to 2. Broke into the debugger, 3 threads. Upped it to 3 threads, rendered again, broke into the debugger, you guessed it - 3 threads.

So, what does this mean? It means that for typical rendering Vegas doesn't even use additional threads. I did have some color correction on the tracks, and some audio effects as well, but nothing fancy, so these weren't just plain vanilla clips, there was a little bit of work Vegas had to do besides munging clips together.

Does this mean that the number of threads property option is bogus and doesn't do anything? Maybe. There could be conditions that I'm not aware of that would cause Vegas to attempt creating additional threads. But my findings were a little shocking, as I fully expected to see the number of threads increase based on the settings I specified.

Also interesting to note that Vegas is written in managed code. I used ILDasm on some of the assemblies to see if there was any obvious code to spin up additional threads while rendering, but as expected with commercial code there are a LOT of assemblies with a LOT of namespaces and code to wander through. I'm satisfied with observing Vegas not starting additional threads when I'd expect it to use more.

As an FYI I have a quad-core processor, so this behavior isn't due to a shortage of cores Vegas could leverage.
3DFrog wrote on 4/22/2011, 11:36 AM
What would be nice is to a standard set of files to benchmark with.

Created a project which all can use do perform rending and thread management with, which is downloadable.

Created various files for difference testing, were everyone is on the same page.

Example set of files for Stereoscopic 3D
A set files for normal rendering
A set of files for medium rendering
A set of files for maximum rendering

Tester report back there system and results

Something like this
ritsmer wrote on 4/22/2011, 1:30 PM
Rendered a project on a 2 x Xeon quad machine (8 physical cores). Ran both tests twice with max number of rendering threads:

= 1: time= 2:01, memory=1.055, cpu util= 68-70 pct.
=12: time= 1:41, memory=1.055, cpu util=98-100 pct.

So Max number of render threads does matter - in this case - at least.

Did the test again with 1 cpu (4 cores) switched off - now:

= 1: time= 2:38, memory=1.055, cpu util= 46 pct.
=12: time= 2:33, memory=1.055, cpu util= 50 pct.

So, yes, with only 4 cores the max number of render threads does not matter that much as it does with 8 cores.
SuperG wrote on 4/22/2011, 4:56 PM
"Also interesting to note that Vegas is written in managed code. I used ILDasm on some of the assemblies to see if there was any obvious code to spin up additional threads"

I always knew that Vegas had .net code in it - there'd be no scripting interface without it. But I always assumed that what they were doing, was providing 'wrappers' to certain objects so that scripts and .net-based addons could get at them - the main application was still written in a compiled language.

However, that's not to say that they haven't added some components written in .net to the application. You can easily identify them - they stand out within the application like a sore thumb. There's the ProType titler - nice, accurate, but UI clunky. Then there's the changes they made to the FX timeline. (Thankfully, they fixed the problems with it since the 10a release - but it still will not snap keyframes if snapping is enabled)

Anyway, I think SCS got the message a bit back - our bread and butter is the UI - you can make it better - but never, ever, go backwards.
Steve Mann wrote on 4/22/2011, 8:24 PM
Adam - According to your observation in VS debugger, Vegas uses three threads. What bout .net, the CODEC and any DLL's spawned by Vegas?
Adam L. wrote on 4/23/2011, 9:51 AM
You brought up a good point. I found it odd that VS2008 was only showing a few threads, even when dialog boxes were being displayed (dialogs almost always have their own thread.) I figured out why, it was because I had used the Automatic setting for debugging type. Since Vegas uses managed code, the debugger decided to only used the Managed debugger. This omits any native information. I set it to debug both native and managed, and there were 70+ threads listed. VS2008 isn't that great for monitoring though, as you have to break into the app in order to see what's going on. So I used Process Explorer instead.

Process Explorer is a free app you can download from Sysinternals (Microsoft has links on their site to it, so it's a legit application) if you're interested in seeing Vegas as it's doing its thing in real-time.

So yeah, I was WAY off. The number of threads under Vegas when all the satellite modules are taken into consideration seems to hover ~70 threads. This number scales up or down depending on what Vegas is doing. Open a dialog box in Vegas and it adds one or more threads, since dialogs run in their own thread.

So now that I have an actual good monitor for seeing threads, next step was figuring out which threads are the ones that do the rendering. There isn't a thread named something convenient like Vegas100.exe!RenderThread+0x1234, so I had to poke around a bit. After playing with the number of render threads, and sorting threads by their CPU consumption, I found the thread's name.

When Vegas does it's rendering it's through a function called Vegas100.exe!FindEnvelopePoint. There's actually a number of these threads in the Vegas100 process, but only the ones associated with rendering will pop up to the top of the list when rendering is started and the columns are sorted by CPU cycles. There might not be as many of these functions consuming cycles depending on your project. If your project has a lot of clips on the timeline, you'll see a consistent number of these chewing up cycles and the number of them will be directly tied to the number of render threads you've set.

I set my project to use 1 thread, started rendering, and Vegas100.exe!FindEnvelopePoint popped to the top with the most CPU usage. Stopped rendering, went back and set it to use 2 threads, rendered again. Now 2 Vegas100.exe!FindEnvelopePoint threads appear at the top. Set it to 3, repeat: 3 Vegas100.exe!FindEnvelopePoint threads are now present, and finally set it to 4, 4 Vegas100.exe!FindEnvelopePoint threads show up. For the sake of being thorough I set the number of render threads back to 2, then render again. 2 Vegas100.exe!FindEnvelopePoint threads are shown at the top of the columns.

So my earlier test was broken as VS2008 didn't concern itself with all the threads the process spawned, only managed threads were being displayed due to my error. Vegas does indeed spawn additional threads associated with rendering based on what the user has set.

The really interesting thing is Vegas pegs all 4 cores to 100% when rendering. Setting the number of render threads has absolutely no bearing whatsoever on how many cores Vegas will use. If there's a core there, a thread is dedicated to it. This is why setting the number of render threads doesn't have as big an impact as it implies. Since Vegas uses all 4 cores at 100%, the additional cycles the render threads need won't amount to much since the cores are busy anyway.

If you use Sysinternals, when you start rendering you'll see Vegas creates 4 threads called ntdll.dll!RtlUserThreadStart. I suspect that these worker threads are spun up during render, and will be related to the number of available cores. 1 thread per core to do all the work of rendering. If someone with a different number of cores could verify, that would be cool. These worker threads are the ones who suck up 100% of each core while Vegas renders.

I'd be interested in hearing from someone with an 8 core or more machine running Sysinternals and seeing how many RtlUserThreadStart threads are listed during a render. If there are 8, then I think it's a safe assumption that Vegas will always use as many cores as the machine has for rendering purposes. With that in mind setting the number of render threads won't have a significant impact, although as the number of cores scale up the more impact this property might have due to the render threads getting additional cycles to do their job.

So to sum up, Vegas does create threads based on the number of render threads set by the user. However, the number of cores you need in order for this to be useful is unknown. Adding additional threads when all the cores are pegged at 100% might result in slightly faster render times as the render threads will be given cycles, but Vegas is already using 100% of all cores anyway, so there shouldn't be much difference.
It's entirely possible that on machines with a large number of cores (8 or more I guess) that Vegas won't use all cores while rendering, and at that point setting additional render threads might improve performance by a significant amount. But for those of us with 4 cores or less, I suspect setting the number of render threads won't make much of a difference.