It's just a theory, haven't tried it. But I disagree that it's ONLY about CPU horsepower.
Disk I/O can also be important. People who use SDI, uncompressed AVIs, and/or multiple streams report that they need a good RAID to get good speed. If you use highly compressed source media and only one or two streams you probably don't see a difference from I/O speed, but that's not everyone's case. One user with a 4 disk RAID is reporting CFDI playback speeds that I'm not even close to, but my CPU is faster than his. Disk I/O is the choke point for this one.

You really could double your speed if you went from, say, a lowly 128MB of RAM to a much bigger 1GB of RAM. That's because you were previously using the hugely slower hard disk swapfile to compensate for lack of RAM. Of course once you have an adequate amount of RAM the benefit of more RAM is probably negligible.

Also I did indeed see a goodly increase on x64 for the particular project I was working on (a rather complex project with tons of memory-hogging stills, PIPs, and compositing). So it probably depends on the project and a few other things (like preview RAM settings, as found by fldave in his postings).

So overall you could be right that eliminating the swapfile would be of no use. But maybe it's worth a try.. And overall I disagree that only the CPU is important. It is most important, but if you are sufficiently lacking in other areas, it won't matter. (Like, try running with a 5400 RPM drive or with all your files on the system drive).

Well...there's nothing wrong with decent disk I/O but anyone serious about this will have that taken care of. RAID is NOT required. Any modern hard disk will give you more than enough throughput. But pound for pound - you still won't see any mind blowing performance increases.

Vegas is about RENDERING (which is what I think you are leaning toward here). That means raw math and number crunching and that means CPU. Sure - you can fetch things from memory faster and shunt them around with faster SATA drives etc...(I suppose you spend a wack of cash on a bunch of overpriced SCSI drives - but the performance for the price still isn't worth it IMHO) But c'mon - when has your rendering seriously improved to the point where you went - Holy crap!

I know when mine did - as soon as I slapped a new AMD Athlon 64 X2 4400+ with a 2MB cache. Some projects were halved in rendering...without changing anything else on the box.

That's what I am taking about. Go ahead and tweak all you want - at the end of the day - the only guaranteed way to boost performance (in a truly noticeable way) is to change out the CPU.

And trust me - If I (or anyone else) discovered some groovy new way to massively boost performance - we would certainly tell folks about it.

VP

On this topic - what, if any, advantages are there for having an Opteron -vs- an X2 processor? I too am using x64 XP Pro and love it - although I miss having a native verion of Firefox 2.0 - am still having to use 32 bit and it has been wonky at times.

With all the hubbub about raw horse power - what little I have been able to understand is that Opterons really are better for video editing compared to X2's... Or am I still not getting it?

What about Cache? Does having 1mb cache per core make a big difference compared to 512K when it comes to rendering? NewEgg has dropped their prices on AMD processors and although I just got the 3800 X2 AM2, They have some great deals up to 5000 X2's...

And no, I'm not going to jump over to Intel - it would be too much of a ding financially to start all over after having made the hardware upgrades I did a couple months ago. But a processor upgrade would be do-able right now.

Any thoughts?

Opterons are designed for server use. The memory controller on the CPU supports ECC RAM (RAM that allows for error correction).

They also overclock well.

Those are the differences that I know of.

2- Cache doesn't seem to make a big difference on rendering. Here are the AMD X2 figures:

39s - AMD X2 4600+
SOURCE: JohnnyRoy @ http://www.sonymediasoftware.com/forums/ShowMessage.asp?MessageID=423138&Replies=4

*39s/74s - AMD X2 4400+ (Toledo core, 2X2.2ghz, 2X1MB cache, no dual channel memory, Vegas 6.0b)
SOURCE: philfort@ http://www.sonymediasoftware.com/forums/ShowMessage.asp?MessageID=399447&Replies=26

*39s - AMD X2 4400+ overclocked to 2420mhz
SOURCE: Jayster @ http://www.sonymediasoftware.com/forums/ShowMessage.asp?MessageID=465519&Replies=0

*40s/76s - AMD X2 4400+ (Toledo core, 2X2.2ghz, 2X1MB cache, no dual channel memory, Vegas 6.0b)
SOURCE: TheRhino@ http://www.sonymediasoftware.com/forums/ShowMessage.asp?MessageID=396239&Replies=61

Rendering speed and the interaction with cache size may also depend on the effect used... i.e. gaussian blur may have a greater benefit from larger cache size.

3- Intel is "kicking butt" (that's the technical phrase) in the rendertest.veg benchmark right now. So I wouldn't spend too much on a AMD upgrade, because it goes to show that newer and faster CPUs are always around the corner.

Actually, it is about CPU, Memory AND disk speed. And on a REAL operating system (UNIX derivative), more RAM actually means something. The reason you aren't seeing any improvement in performance with more RAM is because Windows memory management is brain dead. I've been running Windows for years, and I just got a new Athelon64. I've had it. I'm going back to my roots. My next machine is going to be a MAC, which runs on FreeBSD. I've been a software engineer for over 20 years. The single biggest performance issue I have seen historically, is disk I/O. I took a simulation process that was caching EVERYTHING to disk, rewrote it to use the RAM, and went from 2 hours processing down to 2-3 minutes. Of course, that presupposed I had the RAM available, which I did... and the CPU on that configuration wasn't an issue either; it had plenty of capacity. So bottom line is you've got to optimize all the resources and that balancing depends entirely on the operating system and how it uses the resources.

Most people's experiences do show that CPU speed makes the biggest difference in video editing though. Certainly for other applications, other factors would be more important (and disk speed occaisionally does make a difference if you're in PIO mode). Vegas' memory management was (is?) weird so sometimes you get different results based on what RAM preview is set at.

"Actually, it is about CPU, Memory AND disk speed."

Actually - for Vegas (which is the key here) - It's ALL CPU.

"I took a simulation process that was caching EVERYTHING to disk, rewrote it to use the RAM, and went from 2 hours processing down to 2-3 minutes"

Not disagreeing with you on this - but Vegas doesn't use RAM for anything except some previewing and keeping the executable rolling....if the rendering process was to somehow occur in RAM - then we may see a significant breakthru - but last time I checked - the CPU STILL has to perform all those computations to create that final file..and since that does have almost nothing to do with RAM...you will see very little increase in anything.

Memory means nothing when rendering. Disk speed may buy you a slight advantage but anything modern (last 12 months) is about as fast as you are going to get. I have tested rendering to the same disk that Vegas is installed on, the same disk Windows is installed on and onto separate physical drives in SATA, SATA RAID, IDE...you name it - I didn't see a measurable gain anywhere...but pop in a new CPU (without changing anything else - memory, disk or any configuration settings - and some projects went from 2 hrs+ render time to 44 minutes. That is huge!

This same kinda commentary pops up from time to time from those keeners trying to convince themselves that a 512MB video card is going to somehow inject massive speed into their Vegas experience...when in reality - a plain ole 40 dollar 32 MB Matrox G450 will give you much better on screen Vegas performance than any 400+ dollar "gamer" card.

Rendering is pure number crunching and in the end - the CPU with most horsepower wins....

VP

Actually - for Vegas (which is the key here) - It's ALL CPU.

For most users, ASSUMING they have at least a 7200 RPM hard drive that is separate from the system disk, and ASSUMING that they have at least an adequate amount of RAM, then your statement can be true. Fail those assumptions and the statement doesn't hold.

Agreed, CPU is #1 by a long shot for most users. But (as I stated before), that's not necessarily true for all users. If you are using UNCOMPRESSED AVIS, and especially if using MULTIPLE STREAMS, then you WILL need a good RAID. If you don't think so, ask users who have done that kind of work. All the experts on this forum who do that kind of work have stated so on the forums, in their training books, etc. And this especially applies for previewing.

While I don't agree that 100% of Vegas use is ONLY dependent on the CPU, I do agree that for MOST users, once they meet the baseline they'll probably receive little benefit from incremental improvements in anything other than the CPU. But I'm not 100% sure about that last part.

... Vegas doesn't use RAM for anything except some previewing and keeping the executable rolling....if the rendering process was to somehow occur in RAM - then we may see a significant breakthru - but last time I checked - the CPU STILL has to perform all those computations to create that final file..and since that does have almost nothing to do with RAM...you will see very little increase in anything.

The size of the Vegas executable is less than 100MB. If all Vegas did in RAM was "keep the executable rolling", why does it climb up to more than 1GB of RAM usage during an HD render (even if previewing is off)?

There's a lot more than just code that gets loaded into RAM. The CPU doesn't have big enough arithmetic registers to crunch on multiple GB of video data. It must load the data into RAM and into the CPU memory cache (which isn't huge). It pipelines the data from RAM/cache into the registers for computation. Also, Vegas internally converts all the video data it processes into RGB 4:4:4. Where do you suppose it puts that temporary, uncompressed data?

Of course the time it takes to move the data from RAM into the registers is probably negligible compared to the time it takes to do the actual computations, which would explain why a faster RAM stick doesn't impact renders. But nonetheless it is using the RAM. And if you have a truly inadequate amount of RAM (let's say, 128 MB), all that data gets written to the swapfile and slows you to a crawl.

Run a render and look at the Task Manager, you'll see (if you told it to display this data) that VM SIZE goes up to a really significant number. Why? Because it is paging data and code. Some (or all) of that paging goes to the swapfile. Putting data and code back and forth into the swapfile requires hard disk read/writes which are orders of magnitude slower than RAM. (If you think Vegas isn't doing this, look again at the Task Manager). Considering that the disk is hundreds of times slower than RAM, an HD upgrade that is 1.2 times faster would have a negligible impact on paging speed. But what if you aren't using the (100x+ slower) hard drive at all for paging? What if you use RAM instead for this? I don't know the answer. You said you tried that and saw no difference. That can be true. I never tried it. Depends on what % of render time is spent paging data (which I have no idea). That tech article from Microsoft with its performance measurement suggestions could probably give some clues.

Jayster,

"Considering that the disk is hundreds of times slower than RAM, an HD upgrade that is 1.2 times faster would have a negligible impact on paging speed. But what if you aren't using the (100x+ slower) hard drive at all for paging? What if you use RAM instead for this? I don't know the answer. You said you tried that and saw no difference. That can be true. I never tried it. Depends on what % of render time is spent paging data (which I have no idea). That tech article from Microsoft with its performance measurement suggestions could probably give some clues."

If you are so convinced - then shut off your page file and have at it. You will probably notice no change in anything. This is an easy test - if it doesn't work or gives you fits....turn the pagefile back on. I ran with no pagefile on XP for about 6 months after finally getting 2GB or RAM....my machine was actually faster (something I could feel) when I turned it back on.

We could debate possibilities all day - but without a true understanding of what is being paged...when and why - there is no sure way to guarantee any performance change. Despite what we think about the coolness of x64 - if an app isn't specifically written to address gobs of RAM - no amount of tweaking will help.

My big question is - why doesn't Vegas just use all my available physical memory doing a render...why stop at 1GB? If I have 3 or 4GB at my disposal - wouldn't Vegas just fly if it could use all that RAM?

My guess is that the program itself has a number of upper level ceilings...especially since it is a 32bit app. It will never be able to access beyond 2GB....a 64 bit version of Vegas would be a different story.

VP

Jayster, I couldn't agree more. This is precisely what I've seen with Vegas (task manager and all), and frankly this is exactly what they taught me in Computer Science class. This is standard computer architecture, and Vegas, since it runs on an operating system, has to live within the physics of computer processing. I had to deal with all this when I wrote an operating system many years ago.

Vocalpoint asked: "My big question is - why doesn't Vegas just use all my available physical memory doing a render...why stop at 1GB? If I have 3 or 4GB at my disposal - wouldn't Vegas just fly if it could use all that RAM?"

The answer is, it cannot if it is running on Windows. The operating system is what assigns memory to the applications. If the O/S won't assign more than 1GB to an application, it doesn't matter if you have 100 GB on the system, the application won't get to use it.

"The operating system is what assigns memory to the applications."

Yep, I remember the days when *we* could decide how much memory would be available to a task, and instruct the operating system to make it so. We could even prioritize which task got, well, priority for processing, and for how long before another task had a shot at the cpu.

Now we have to search for workarounds and system settings to trick (not ask, trick) the operating system to do what *we* deem important. One of those workarounds is installing XP64.

I just want to point out that I got about a 20% to 25% performancy increase in Vegas simply by moving my Windows swap file to a second physical hard disk. My Vegas temp folder is still on drive C:, my Windows swap file on drive D:.

I know many posted about this in the past, but this is the quickest way to bump up Vegas performance. Everyone should do it. Hard disks are so cheap now.

My drive D: happens to be a RAID 0 array where I keep my in-progress media as well. In tests, it makes no difference where my media files are sourced. All that matters is that your Windows swap file be on a 2nd physical disk from your Vegas temp files folder.

I forgot to mention that I am running 64-bit Windows Server with 4 GB RAM. I tested long ago, there was no improvement at all by running without a swap file. It's a good theory, but just does not pan out, strangely enough.

Moving the swap file to another disk makes perfect sense. That means you are using two disks with two independent heads simultaneously. If you read/write/swap all to the same disk, you have to wait for the head to move for each operation. Some time ago, I separated my source from output files -- sources go on D, output goes on C. The other thing I do now is make sure my hard drives are fully defragmented before rendering a big project. These two things for me made a huge difference in performance. Plus, I had been burning out hard drives like crazy, probably because I had the drive head jumping all over the place. Those things are mechanical, and at some point, they just wear out.

My own tests show that hard drive speed only makes a big difference if the render is like copying a file. In most typical renders, the render is very processing-intensive and bottlenecked by the CPU.

http://www.dvinfo.net/conf/showthread.php?s=&threadid=18784

2- Excessive swap file use can slow down a render by magnitudes. Some people saw this happen with one of the newer rendertest.veg's (I did). However, I would consider this to be a program design flaw as the program should manage memory properly in the first place.

When Vegas is operating 'correctly', the main bottleneck is in the CPU/processing.

"When Vegas is operating 'correctly', the main bottleneck is in the CPU/processing."

True. However, when the op system decides to swap, swap takes priority, and swap happens. If the called IO routine is in the swap file, that has to get paged in, some other page swapped out. Then the IO routine gets further and further down the use cue until the op system decides "aw, what the heck, swap it back out". Ooooo, and then suddenly the IO routine is called...

Wouldn't it be nice to dictate to the op system what *must not be swapped*?

Just for giggles, I too put the page file on a RAID0 striped dual-drive. Min 2973, Max 4092 MB - running mostly at 2973MB on a 2-gig Ram system. I too noticed a measurable (albeit small) improvement in simple stuff like moving the jog wheel through frames. Mind you I'm looking at Best-Full on a second screen m2t (1440x1080ix32) displayed 1440x1080x32, so redisplay is very CPU intensive.

All in all, I've decided to add a quad-core 4gb multi-raid (one for applications/system, one for swap, one for source, one for render) system to the network, edit with 4 processors, and render with the equivalent of 6 processors and many disk arrays.

I don't have that many years left in me to wait around for the next frame to display, so the old clunker Jeep will just have to live another year.

Any chance we could get a Sony engineer to weigh in on this subject? There's obviously a lot of educated conjecture in this thread, but I'd love to know what Sony recommends.

Do they have any configuration white papers available?