When I get some time I'm going to post a Vegas 6 HDV test script for benchmark testing.
Also, in 4 years of receiving hundreds of scores for benchmarking both MediaStudio Pro 7 and Vegas 5 I've NEVER seen a performance variation due to hard drives (or memory over 512MB for that matter) greater than a few percent. For memory this assumes the OS is not starved for memory as more memory will allow more efficient multitasking.
Rendering is so much slower than real time that hard drive speed does not become an issue. Perhaps for uncompressed capture or preview, but not for rendering. I'm not entering this to be argumentative, just a reporting of a fairly large data base of actual numbers I've acquired over the years.
I have a simple 1 minute video that I rendered into AVI, WMV and multi-bitrate WMV. All three tests took twice as long to render on vegas 6 (compared to vegas 5). I still want to do more investigation to see if maybe there are some settings I can change but out of the box that was a little disappointing.
The tests happened within an hour of each other with no new hardware or software installed (other than Vegas and its requirement of .net patch1)
It's great to have all the mathematical theory as to why vegas 6 should be faster, but has anyone actually seen it be faster? My system has a p4 with hyper threading. (not two processors)
On my single processor Hyperthreading machine. I got a faster response by going to Preferences>Video> and setting the rendering to 1, I believe the default is 4.
BK? Did you get BETTER performance than V5 on Setting 1? That's what I want to know. Once I know, then I can accept, move on and/or see how Sony is going to tweak this V6 for Single HT - yeah? SO better than V5 or the same?
Thanks, I will give that a try tonight and update my post to include if it worked for me or not. I have since found other posts that recommended changing to one thread as well.
The source was 45 secs and had a transition and a filter applied. Furthermore I used the ColorCorrector-Filter (ComputerRGBtoStudioRGB) in V5 but not in V6 (as intermediate HD-AVIs are now automatically converted to StudioRGB in V6).
Even though I still wonder why 2 threads render slower than just one I really don't care as long as V6 is so much faster than V5.
Thanks Sony!
From various threads in the last few days it is looking like rendering performance gains are more noticeable when dealing with HD - -- I haven't had time to try it myself but I did compare all four thread settings in V6 with the same AVI DV file rendered in V5 - checking to be certain that all else was equal
With a thread setting of 1 V6 was negligibly faster in than a V5 render
A thread setting of 2 proved to be the ideal in this test which had lots of layers , VST effects and some motion blur
I guess I will have to do these tests again if I want to be sure this pertains to MPEG 2
and HD files
A difference here likely comes from the color correction filter on the V5 version of the project, but there are some reasons that one might expect HT performance differences.
The number of threads that you are limiting is the number of video engine worker threads used to render your project. There are still many other threads at play here (reading/decompressing, compressing rendered output to MPEG2, rendering audio, etc.), and when the video engine uses more threads, it is possible to have more scheduling contention between the threads.
This can be thought of in much the same way that one might consider the classic 'two people trying to go through one door at the same time' joke. This doesn't truly describe the situation, but it's an explanation that you can leverage if you don't wish to embroil yourself in the explanation that follows.
When Windows (XP and 2000 are all that we're talking about here) looks at HT processors, it sees two logical processors on which to schedule two threads for execution. In fact, Windows sees HT logical processors as essentially equal to physical processors, and this is where possible performance problems may arise.
The cost of scheduling threads and switching between them is not negligable (refer to the small "c" in the first post of this thread), but this is generally offset by the performance benefits of running threads in parallel on multiple processors. In the case of HT processors, the threads do not actually run in parallel (at least, not in the same way that threads run in parallel on multiple processors), but they are, instead, factored into much smaller execution chunks to take advantage of otherwise unused processing capabilities of componentized modern processors. The act of doing this for two threads in the HT processor is also not free, which means that two threads that would, on their own, have largely monopolized the processor's resources can contend for the processor's internal resources. Though an HT processor makes its best effort to optimize this process, it may not succeed in running two threads as quickly as it may have run them in sequence. Much of this behavior depends not only on the efficiency of the underlying code but on the processor's expected efficiency of the underlying code.
As an aside, if we consider two physical HT processors, A and B, and their logical processors A1, and B2, it is entirely possible for us to get unlucky with two threads and have Windows schedule both of them on the same physical processor (say, through A1 and A2). The Windows scheduler seems to round-robin threads (except in NUMA cases, which we'll skip for now), so this generally isn't too large a problem. You'll notice when you use a heavyweight single-threaded application on a dual-processor Xeon machine that the per-processor graphs in Task Manager generally don't show one processor getting completely pegged and the others sitting still. For more information on the Windows scheduler, I'd recommend talking with someone at Microsoft, as the specifics of the inner-workings of the scheduler may be known only to the NT team.
Ok, I ran the test setting threads to 1 and got slightly faster performance but nothing like what I got with V5. So, out of curiousity I reran my tests on V5. To my suprise, V5 is now slower than V6!?!? My suspicions immediately turned to the .net framework version 1.1 service pack 1 that Vegas 6 requires so I tried to roll back that install however I don't think that is possible since I still get the slower results with my v5 now. :( I also tried installing .net 2.0 beta just to see what would happen, however vegas 6 does not work with that. (It requires 1.1 be installed)
Sooo.... my new question is: if someone has not yet installed v6 and still has version 5 on their machine, run a benchmark BEFORE installing v6 and the new .net framework. I'd be interested to see if you saw the same results as me. If not, maybe I just lucked out and for that brief period of testing V5 my machine managed to render things in half the time it takes now.
The thing that reduced my rendering angst is this formula: I factored $15 into one Roger Magnusson, purchased Batchrender Pro, and set the computer to do all its time-consuming work while I sleep. In a way, I "upgraded"my 2.53 gHz Dell P4 (pre-HT).
The math looks nice, but for me the switch from version 5 to version 6 was well worth it for one reason: 60i to 24p looks wonderful now! I don't care if renders take a little longer (they seem about the same) or if it crashes once in awhile. This one feature trumps everything else and makes it all worthwhile!