4 is the max for VMS. I believe Vegas Pro can do 8.

I have Vegas Pro 8/8.1.

8 (32bit) has a max of 4 and 8.1 (64 bit) has a max of 16. So it seems 32bit versions of Vegas support 4 threads max and 64bit supports far more. I haven't tried Vegas Pro 9 so not sure if the 32bit version of it is able to support more that 4 threads though.

I'm no expert .. but .. it is my understanding that the number of CPUs / cores has nothing to do with the amount of "threads" that you can run.

Obviously, the more cores you have the better, but I don't think it's a one to one relationship.

brighterside, you absolutely correct. All having more cores does is enable the possibility of having multiple threads run simultaneously. Even then, there is never 100% efficiency in multi-core implementations, and in practice performance can actually decrease with more cores (overhead, synchronization, and resource contention issues exist that don't exist with single cores). It is ALWAYS true that a single core that operates twice as fast as a dual core (all other things being equal) will execute programs faster than the dual core processors collectively can. Furthermore, most (especially all real world practical) programs cannot be written to effectively utilize all the resources made available by multi-cores. It's actually a very big problem. The only reason multi-core processors are made at all is only because that is far easier than making single cores faster, and there is essentially a limit (at any given point in our technological development) to the speed of any core, but there is practically no limit on the number of them. The more cores, the lower the average utilization of each, except in highly specialized applications and even then only with very careful programming.

Vegas 9 can make use of all the processor threads your system provides, but it has a built-in limitation of 4. This can be changed to 8 however if you know the following trick:

Hold down the Shift key when you open Options/Preferences. This will cause the Preferences window to open with a new tab called Internal. This is where you can change the limit of 4 threads to 8. Do this as follows:

1. Enter the text "threads" (no quotes) in the text box at the bottom. This will display all the parameters containing the word "threads."

2. Find the line that says Maximum video render threads (or something like that - I no longer have VMS 9 to look at.)

3. In that line change both the Default and Value numbers to 8 (or whatever the number of processing threads your system has.)

4. Hit OK, then close Vegas and re-open it.

You are now running with all threads active and usable.

To clarify some terminology: Intel now makes CPU chips that are multi-threaded. That means a single chip can process more than one instruction stream at a time, thus enabling one physical chip to do the work of multiple single thread ships.

"Thread" means a stream of instructions, which is the work processed by the CPU or "core". Core is really an obsolete/incorrect term that came into being yeas ago when main memory was referred to as "core memory" to differentiate it from cache memory built into processor chips.

In the case of the i7 line of processors, each i7 has 4 CPUs inside it. And each of these is dual channel. This means an i7 based computer can process 8 instruction streams ("threads") simultaneously, assuming there is enough memory in the system to support that.

Since raw CPU power is typically the limiting factor on render speeds, having more threads running speeds things up considerably. When rendering with Vegas you want all the CPUs you can get (and all the memory too,)

Thanks for guide. I just checked number of threats in Platinum10 and it says 16 threats by default :)

I have an i7 860, 8 GB RAM, and am running Windows 7 64 bit. In Vegas 9 I changed from 4 rendering threads to 8, and was curious to see what a difference it would make.

Well, it certainly made a difference. Rendering my little project took 5 minutes 38 seconds with the default settings, and 7 minutes 39 seconds with 8 threads. Any ideas why the rendering time would go up by 35% after making this change? I am rendering to Sony AVC format.

In addition, I loaded the same project into Vegas 10 and rendered there as well, using the default settings. Result - it took 9 minutes 25 seconds.

I just made a quick test too, and its shocking..
I have C2duo 2.93Ghz + nvidia 9800gt + WMS10
Rendring time using AVC:

4 Threats + GPU 1:18
1 Threat + GPU 1:14
1 Threat + no GPU (ticked "encode on CPU even if GPU is aviable option in AVC render dialog" 1:15

No change at all, so it doesn`t work here.

Thanks to all for the replies, and for the thread limit trick to increase from 4 to 8.

HollowMan, regarding your rendering times, very interesting indeed. As one other reply mentioned, depending on what the software is doing in those multiple threads, you may see a decrease in performance if you have too much contention between threads. Its also a function of how the software is written to take advantage of multiple processing threads, and how easily the application itself can be divided into parallel processes that are each as efficient as one big single thread would be (or as close as possible). As was said before, its not an easy software design problem, and considering the price of VMS, I wasn't expecting miracles. I've read benchmarks for Premiere Pro where more threads seem to always render faster, but for its price I'd hope that was the case. I suspect Vegas Pro may also be similar in that regard but haven't seen benchmarks on Pro to verify that.

Regarding your VMS 10 vs. VMS 9 discrepancy I have two possible explanations: the first involves a preference setting that may be different between your two versions. Look at the window where you set the dynamic RAM preview max (options/preferences/video). I'm not sure exactly what that value controls, but I thought it might help my preview screen be less jerky, so I cranked that value up to the max, which was half my available memory. My previews didn't improve at all as far as I could tell, but my render times got slower by a significant amount. Putting it back to the default value improved them back to what I was seeing before making the change. Check the settings on both versions to see if they're the same, if not that could possibly explain it.

The second explanation is that I've run the same operations on still images with different versions of Photoshop and noticed the more recent versions often take longer to do the same exact operation that a previous version did faster on the same machine. Not sure exactly why that would happen, but I've seen it, and considering the complexity of these types of programs I have little hope of ever figuring it out. In the case of Photoshop, perhaps they find tuned the algorithms between versions, making them more compute intensive.

For video rendering I'd suspect the algorithms are pretty static between versions, but don't really know for sure. I hope what you're seeing has to do with some settings being different rather than the new version just has some unexplained software bloat that makes it less efficient.

These are fascinating results and not at all what I expected. My own experience on my system is that V10 renders about 40% faster than V9. My system is Win7-64 running on an i7 with 8 GB ram and 2 hard drives (one for source files, one for rendered files.)

To those of you running V9 on a 64-bit OS and are rendering AVCHD video: are you aware that you need to make a fix to V9 that allows it to use more than 4 GB of RAM? If you don't have this fix installed V9 is limited to the amount of RAM it can access, so adding more threads will likely increase memory thrashing, and thus slow things down.

Another thing to note is the number of processes your system has running when it is idle. Idle means the system is booted up but has no applications running. You can check the number of processes by running Task Manager and clicking the Processes tab.

My system has 45 processes at idle. I've seen systems with as many as 80. This is a ridiculous number and will cause all sorts of internal performance problems. The most typical reason for this many processes is the bloatware loaded onto systems by companies like HP, Dell, and Sony.

Resolving performance problems is tricky business and is typically very system dependent. In general more CPUs and more RAM = faster performance, but dwalby's point is very valid: writing multi-threaded code is hard to do well and it might be that the code in Vegas just isn't quite up to snuff.

Vegas 10 default for Dynamic RAM Preview max was 350. Vegas 9 value was 128. I changed Vegas 10 to 128 - got the same render time (9:26 this time). Of course, I have 8 GB, so a few hundred K shouldn't make any difference anyway. You're probably right about some setting causing the difference, but at this point the new version is considerably slower than the old for me.

I've made the CFF Explorer >2GB mods for Vegas 9 (before I did that it just crashed). And I built my own machine so there's no bloatware, and a minimum number of processes running.

One other bit of info - I watched the Task Manager during the Vegas 10 rendering this time. CPU usage occasionally spiked to 50%, but is typically between 25 and 30% during the entire process. It seems fairly evenly distributed between the 8 CPU windows visible in the task manager performance window. And the memory usage was at 2.67GB flatlined the whole time.

One last thought - I did not make the >2GB mods to the Vegas 10 files since I have not had crashing problems there. I wonder if they would help out? Maybe I'll try that later if I have some time.

OK, I tried 2 vs. 4 threads and my render times are virtually identical, which is what I expected with a 2-core CPU without any hyper threading capabilities.

Then I tried the 8 thread trick just to see what happened, and I don't think it really works. The number you assign to max threads shows up in the preferences box initially, but if you click on the up/down arrows and try to change it, the max value returns to 4. (this appears to be the case whether you just click 'apply' and don't restart VMS, or if you restart it as in the directions above) I was suspicious about this trick to begin with, because if Sony had coded the software to allow more threads why would they artifically reduce the processing capability to just 4 threads? Also, I was not able to change any of the default settings, they are all greyed out and did not allow editing, was there something else I needed to do to make those values editable?

Another thought on why the 8 thread took longer than 4 thread on VMS 9, it may have to do with cache coherency and more threads fighting over the same data and causing too many cache refresh operations. Not sure how much this is instrumented in the typical PC to even be able to measure cache refresh operations, so it may not even be something you can technically prove is happening. The basic idea is each core will have its own cache. Data is brought into the cache in blocks, if another core/thread modifies any data within that block, the core will be forced to update the cache to reflect the latest values for that data block. Having too many threads accessing data within the same cache block size will cause problems because they're all updating each other's data and causing a lot of cache refresh operations to be needed, consuming a lot of cycles in the process. This is one of the things that s/w designers need to take into account when coding for a multi-core/thread platform. In video the threads can operate on different parts of each image, or different frames in a video, but they eventually have to be working on data that's directly adjacent to that of another thread. The more threads you have, the more of these transition areas exist, so this eventually could become a problem as the number of threads increases. The cache block size would be fixed by the processor, so s/w can't change it. Without having more insight into the processor architecture and VMS code its hard to really say, but in theory its something that would need to be addressed by the s/w designers in creating a highly parallelized computing environment.