"just use the existing render test and switch to rendering AVCHD and it will take 5x longer (or more)!"

Actually, AVCHD renders faster than HDV MPEG-2. Just change the project properties to 1920x1080, pixel aspect ratio = 1.000 (Square). Render out to Sony AVC using the "AVCHD 1920x1080 NTSC" 16Mbps template. I suppose we can discuss the AVCHD results in this thread, but only post the RENDERTEST-2010.VEG HDV results in Steve's database.

On this little 3.0Ghz Core2 Duo laptop I tried this on, AVCHD rendered about 22% faster than HDV.

Actually John, in m case (QX6700) it's 287 sec AVCHD vs. 428 sec HDV - an even greater difference.

I got 245 for AVCHD vs 276 for HDV with my Q6700 running at 3.33

Thanx John for the new rendertest :)

My 3 year old Intel Quad Core (QX9650) runs it in 288 seconds - not bad for such an old PC! The CPU is overclocked to 3.8GHz and running smoothly as silk at that speed - since day one. This proves that a properly done overclocking is very reliable indeed.

288 seconds is precisely 4 times slower (as you correctly predicted) than your former rendertest, that ran at 72 seconds - on the exact same platform.

Cheers,

Christian

srode,

Looking at your results it seems that there is something strange with your result (too good result compared to your CPU and its clock speed). Did you render exactly according to Johns instructions?

Christian

Hello Steve,
I love this forum ... I expose what I think I understand about what I know and someone will always come to set me straight ... thanks ...
I was confused about it, but looking at the spreadsheet, the highest thread number was 12 or so ... I viewed my thread count during the render in the task manager - and it soared above 1100 ... so, not to look like a buffoon, I entered my core number . . . and concluded that thread request was actually core...

I guess I'm wrong on both counts...
I'm learning something new every time I post ... lol ... and never have to pay any tuition fees, either... a free education ... what a great country we live in ... well, okay what a great forum you guys (in both male and female understanding) create...!

Until that time. . . Earl J.

Christian, I thought the results were too good also compared to the others with Quad core processors and now with your 3.8ghz Quad for comparison looks even stranger. Rendering to Mainconcept Mpeg2 default HDV 1080 60i template (1440x1080) with the only adjustment being setting the template to "Best" instead of "project settings" under the custom settings project tab. Did I miss something? I am using 8 bit pixel format under file properties, are you by chance using a 32 bit setting?

I just ran it again to verify and got 4 minutes 28 seconds, which is ever lower at 268 seconds. This is with ram preview set to 5000 (not that it should matter) and the preview screen closed on 9.0c 64 bit. The processor is 100% utilized most of the render and memory usage is about 48% for the machine, don't know what portion Vegas is using. I don't think the CPU will make a difference compared to other quads, but the CPU speed should and your 3.8ghz overclock of the 9650 should be faster than mine.

On edit - I did notice that everyone but me using Vegas 9 is using version e and I am using c - not sure how that would make a difference? I also notice a higher than normal activity on my HDDs when rendering - and I am rendering to a RAID10 Array and caching to that as well, but don't think that should make a difference either as there's plenty of RAM for the machine to use at 8gb, it shouldn't be using virtual memory to render this small file, I assumed it was writing the file. The file's not that big to warrant as much HDD acivity as I am seeing though, 63.6mb.

Vegas 9e 64 bit: 7:32 (452 seconds) on my old Q6600@2.7 gHz, 2:46 (166 seconds) on my new i7 940 @ 3.92 gHz. Significantly better than 2:1 improvement, but I'm not convinced the benefit was worth the work of building this new machine.

Core 0 gets spikes up to 80 degrees C. That's a bit too warm for continuous operation (intel recommends staying below 73 degrees for i7 chips such as the 920-940), but probably OK for brief moments. Also, my computer room normally stays perhaps 15 degrees cooler (maybe 6 or 7 degrees C) - I had both computers running all day and the temp in the room was 90F; so usually I should be OK with expected peaks at around 73C.

Incidentally, it's important to reboot, or at least close and re-open Vegas between successive tests. If you set the Preview RAM really high (I set it for 3500 MB, which doesn't hit the 12 GB installed memory too hard), Vegas will re-use much of the output from the previous render. That seems to be more true of the older NEWRENDERTEST.HDV, but still it's something to consider when using this new benchmark test too.

Anyway, thanks for posting the Rendertest-2010

Edit: Incidentally, there are some bargain 940s around - I paid only $225, $5 shipping, in unopened Intel retail box. It's C0 stepping - considered good. Seems to be a fairly good chip, but I think the surface is not totally flat, hence the high Core 0 temps (real OC fanatics lap down the case with fine sandpaper on thick glass until they have a mirror finish; ugh!).

Vegas9e (32) 00:14:43 = around 900 sec on a MacBook Pro (2*2.8GHz) with BootCamp-W7. About double that time (almost half an hour) on a MacPro BootCamp-XP (8*2.8GHz, though msinfo32 only reports two of them).

My results are so much worse than other peoples' results (at http://www.mmdv.com/sonyvegas/rendertest, including for similar hardware (e.g. ritsmer), that I wonder if I did the test correctly (but what's there to mess up? I followed the ReadMe). And it's interesting that the W7 time is twice as good as the XP time - how come? Does W7 make better use of the MBP's 2 cores than XP does of the MP's 8 cores?

Update:

On MacPro XP(32) got almost twice as fast after increasing Preview RAM from 0 to anything >0 (tried between 1 and 512) and increasing max threads from 3 (which I found to be best on a real project) to 4. A "real project" for me is e.g. 1 hour with extensive reframing, grading, denoising and also big stills; under Vegas 8c(32), greater numbers of threads had tended to increased the incidence of freeze/crash issues (haven't yet experimenting with this under Vegas9e). These mods took overall time down to 8mins 13 sec i.e. 495 sec. CPU was typically 50%, implying 4 out of 8 cores being used, as I would expect for 32-bit OS & App. So I wonder how ritsmer got twice as good results. Different OS or 64bit?

Through the Internal Settings, tried the XP-bound Vegas9e(32) with 8 threads, obtaining CPU85% giving 5 min 06 sec = 306 sec. Wonder why its not 100% - tried both RAID and system disk, also disabling AntiVirus, none of which made any difference. Some "fiendish" hidden (-ve ID) process of XP perhaps? Interestingly, Vegas9e(32) rendertest best MaxThreads no. is 8, whereas for Vegas8c(32) it had been 7. I guess this shows 9e(32) handles multithreading/multicores/management better than 8c(32).

Possible insight to a long-standing question: Why should Preview RAM have any effect? I have heard about it before but it doesn't make sense. It even had effect when the Preview window was closed down. With PreviewRAM=0, total CPU was 15%, equivalent (on my 8 core machine) to 1 core. With PreviewRAM=1 (or greater) total CPU was 50%, equivalent to 4 cores (the max I expect, as explained earlier). Increasing PreviewRAM above 1 had no effect. So it looks like PreviewRAM=0 essentially disables multithreading. Surely a bug!

Further Update:

The presence/absence of Preview, Videoscopes, Excalibur windows etc. makes no difference. Likewise AntiVirus (Kapersky) paused or not, no difference.

Oddly, under Windows 7 (on MacBookPro-BootCamp) the render says at first it is saving to a .mpg file but after clicking Custom and back, making no changes (it is always on "Best"), it then says it is saving to a .m2t file. This does not happen for the same Vegas version under XP (on a MacPro). Presumably a Vegas/Windows7 issue - I'll note it to that forum.

Final update:

I'll add my results to the database once I'm confident the tests are being run consistently with other people's. Maybe some of the items above could usefully be added to the ReadMe. Alternatively, maybe the database could have optional columns for these kinds of variations. Would increase the value of the data collected.

I put the i7 940 that I just built in a cooler environment (71 degrees F, down from 90F when I first posted above) and noticed that the highest core temp was only 70 degrees C during the rendertest. That seems to be too much improvement to be attributable solely to cooler ambient temperature, so I'm guessing that the Arctic Silver 5 past is improving the heat transfer from the CPU with time (Arctic Silver says that you might get up to 5 degrees improvement over a period extending up to 200 days, with most of the improvement occurring during the first days). Unfortunately, I'm still running 7 or 8 degrees hotter on Core 0 than on the coolest core.

I also got slightly faster time: 2:43 - probably because I had failed to disable indexing for my hard disks, and probably my disks still were getting indexed when I first ran this rendertest on this new machine.

Seeing that I had at least a 3-degree C. headroom, I upped the CPU voltage setting to 1.45 in bios, for an actual voltage reading of 1.352 according to CPU-Z. Under load, the voltage drooped to between 1.31 and 1.32, with the CPU timing set for 3.975 gHz (yes, that's the droop I observed with voltage droop correction enabled in bios).

Temp at the hottest core occasionally reached a maximum of 73 C., but the render time was only shaved by 1 second. Certainly not worth the added heat - I'll be cutting it back unless Arctic Silver 5 continues to improve heat transfer to the heat sink (I generally run my chips cooler than the game players who push for the maximum speed - I want my CPU to last a long time). If I see a significant improvement, I'll report it back here.

@fausseplanete: a little info:

My Mac Pro (2 x quad Xeons at 2.8 GHz 8GB RAM + a 12 GB paging file on its own HDD) has Windows 7 64 Bit Ultimate installed directly (no bootcamp or any other Apple things on the machine. All drivers downloaded directly from ATI etc). I'm using Vegas 9.0e 64 bit.

After reading your post I have redone the Rendertest. Noticed a CPU usage changing between some 80-100% (mostly over 90) with an quite evenly balanced load on all 8 cores. Repeated the test 3 times, today with max 11 rendering threads and with Kaspersky, Task Manager, Word and a little other stuff running. Results 3:20, 3:20, 3:22.

Also tried with Vegas 9.0e 32 bit on the same machine. Note: I have set the "can handle >2 GB" flag on this vegas90.exe. Saw again evenly balanced core load. Results: with 11 rendering threads (as above) 4:19, with 7 rendering threads 4:33, with 6 rendering threads 5:06.

Booted in XP Pro. The task manager shows all 8 cores. Ran the test with Vegas 9.0b and 7 threads giving 5:33.

L Reavis "Incidentally, it's important to reboot, or at least close and re-open Vegas between successive tests. If you set the Preview RAM really high (I set it for 3500 MB, which doesn't hit the 12 GB installed memory too hard), Vegas will re-use much of the output from the previous render. That seems to be more true of the older NEWRENDERTEST.HDV, but still it's something to consider when using this new benchmark test too".


On a fresh boot and first run of Vegas I got 279 seconds (4:39).

[IMG=http://tefjug.blu.livefilestore.com/y1phEwFKsFnazIcwsH-LUx4iYNgeigzf029ltg_g7vArU0CHc4XZkRR-pZiU7VUrOYrwLOZ4q6x4_8Q1WffzJ-PH-5MivBTIsJ0/render2010.JPG?psid=1]

Running the render test again without restarting vegas I got 299 seconds (4:59) - seems it slowed my system down didn't speed it up?

I admit it - I'm surprised. How much Preview RAM did you allocate?

Just to ensure no confusion, my MacPro's Task Manager does show all 8 cores, its msinfo32 that shows two Processors. That'll be the two physical Xeons then I guess.

Ritsmer, I tried your "11 threads" (despite only having 8 cores) and hacking the >2GB flag and increasing Preview RAM to maximum, which for Vegas9e(32) is 1024. Of course I tried these one at a time as well as in combination! Only the latter (PreviewRAM=1024) made any significant difference, but it was definitely significant, reducing time from around 05:20 to 04:14.

That is actually quite shocking - to discover that PreviewRAM had a second "quantum leap" effect (additional to the one when going from 0 to 1 MB as I reported previously), this time when going from 512 to 1024. I haven't experimented to find where the exact threshold is and in any case it could be test-specific. Regardless, clearly it's not just Preview RAM, it also gets used for something else (unknown), some kind of internal scratchpad perhaps. I know experienced people have advised settings like 128 in the past for general editing, but I was never too sure how important that really was. Now we have something objective (at least, for this test; it remains to be seen what would happen for a real project). Sounds to me like a definite "feature"...

If PreviewRAM is that significant, might it be worth mentioning in the ReadMe or providing a database column for that setting?

Despite hacking the >2GB flag in vegas90.exe (only), Task Manager shows that process's memory usage maxing out at 2.06 GB. I have gotten the same maximum using the hack when running big real projects.

Does anyone know, is that to be expected when running under XP Pro (32 bit) SP3 ? Or is there some additional hack I need to do, e.g. to XP also? Or does BootCamp "put a spanner in the works" I wonder (thoughI think all it does is provide some drivers). I found the same thing in the past for Vegas 8c (32), again under XP (32). Is it a case of needing a 64-bit OS to see the benefit of this hack?

Until I can get past the 2GB limit, I couldn't sensibly use such a large PreviewRAM setting (1024) for a real project because my projects nearly burst (and sometimes actually burst) the apparent 2GB RAM limits already. For that reason, normally I keep it down to 128 or 256.

Any advice to get past that 2GB problem would be appreciated, then I can get more representative/comparable results for the database.

LReavis - I have 5000mb allocated for preview. The ram showed higher utilization on the second run so it didn't release all it was using the first run I guess, but doubt it reused it or it would have been faster the 2nd run.

apparently the Rendertest-12010 doesn't respond to changes in Preview RAM the way that Rendertest-HDV did. With the latter, the other day I saw a second render time of 2 SECONDS! I really hadn't carefully checked out the Rendertest-2010, but I thought I was seeing an improvement with it, too - just not as significant. I haven't had time to experiment more, but it looks like running the test again does not cut time - to the contrary - based on your info, srode.

@fausseplanete:

Seeing your last post I also changed the preview RAM to 1024and can confirm your results.
RAM 1024 and 7 threads gives 2:55.
RAM 2048 and 7 threads gives 2:54 - and 2:44 with 11 threads.
I guess that around 2:40 is the theoretical minimum for a Mac Pro as I watched the CPU utilization grow from some 90% before to now 98-100% .

Would be nice if other users could confirm the differences in rendering speed using 0/1/512/1024/2048 MB RAM

I also tried to switch of the preview window while rendering to save a few CPU cycles - but no change in the result.
It seems that you can gain a second or 2 by changing the machine usage from "foreground" to "background" - which gives some longer time slices - and so less time waste in the OS for switching threads too often.

As my test with XP on the same machine showed 5:33 I think that the only way you can improve the speed and reach my results would be to jump to Windows 7 64 (at least professional because of the 2 physical processors in your Mac).
I installed the Windows 7 without Boot Camp because I thought it might give me more control over the machine and its EFI (Bios) for overclocking etc - but it seems that such things are not available for Mac Pro users anyway.

Thanks for that update ritsmer, it feels like my world and the rest of the world are phasing back into cohesion once more... I don't claim to know when it's reality though :-) Regardless, I shall definitely be upgrading to W7(64)Pro on the main machine and will explore the background prio influence.

Thanks to John for the newer RenderTest.veg

32 bit 6 min 3 seconds
64 bit 3 min 41 seconds

Intel i7 2.6 CPU
6GB 1333 RAM

BTW - If you are running Win7 you can download a useful gadget that shows your core temperatures and load on CPU's. This is useful if you want check if your cooling is sufficient. The stock cooler that comes with the i7 doesn't even cover the surface area of the CPU.

Get it here at http://www.alcpu.com/CoreTemp/

On a MacBook Pro, two cores, PreviewRAM = maximum possible in each case (stated).

Under BootCamp>WIndows7 (direct boot):
Vegas9e(32), PreviewRAM=1024: 750 seconds
Vegas9e(64), PreviewRAM=1024 or 3048 (same result): 615 seconds

Under MacOS(10.6)>Parallels 5 (virtual machine):
Vegas9e(32), PreviewRAM=1024: 1140 seconds
Vegas9e(64), PreviewRAM=1024: 738 seconds

So, surprisingly (to me), for Vegas9e(64), rendertest2010 performance under Parallels virtual machine is not that much worse than under BootCamp. Shame about the 32 bit result though.

What I noticed when doing any render is that no matter what quality you set the preview window to, it always sets the window to the last "Best" setting you had, when you render.

Just an observation.

I just finished with the render test. 212 seconds to complete or 3 minutes 32 seconds; with i7 930, 24 gigs of ram, 6 TB raid 0.

I was able to do a full Dynamic RAM preview in about 3 seconds.