Why would you think a 64bit OS would make a CPU run faster?

All a 64bit OS means is the operating system can address more RAM. More RAM can dramatically increase speed if it prevents RAM being paged to disk. Outside of that there's nothing in it. Well that's my understanding of it from working on everything from 1 bit to 64bit systems. Oh and the 1 bit systems were pretty dang fast.

Bob.

64bit has some more registers than 32bit, so there is a potential for faster performance there. But that's only a few percent and not noticeable.

really depends on what you are rendering - I have seen as much as 40% reduction in time using 8.1 vs 8.0c - longer more complicated files see much more benfit. Having much used by the fileIOsurrogate is normal - if you aren't using near 100% of your CPU you need to utilize more RAM by adding it and/or turning up your preview ram setting under options - I have mine set to 6Gb for Vegas to use.

I think this is a misunderstanding. 64bit is on my machine slower than on XP 32bit! So there is absolute no advantage taken. I have 6GB on my board, so RAM is not an issue. When I take a look at the RAM usage I also see not more than mazbe 1.2GB used by Vegas, independent from the project length, so there seems to be something not running right.
I also thought that rendering in AVC is a pretty sophisticated task and thought Vegas is handling this differently (better?).
I tried this test with and without page file and both are absolute the same.
I have not tested editing behavoir since I'm not working on an actual project, the test project was made under 8.0 but however, it does no looks like that it made sence to buy Vista64 and redo all installations.
Is it maybe that the encoder are not utelizing 64bit?

Axel

First off, you are not testing apples to apples.

The difference in speed between XP and Vista would affect your test.
Unless you have turned everything off in Vista, it generally is not faster than XP.

Again, not all projects need 64 bit.

found a video clip I found on youtube where the guy did a comparison between 32bit native, 32bit emulation under vista 64 and 64bit native. he had some impressive results overall.

I'm comparing apples to apples (but not a MAC apple) because I needed a fast OS so no Aero crap, every search function switched off (who is using his computer for searching only? I wanna work with it!), no ready boost and so on. It's a stripped down Vista and, to be honest I was expecting a much slower reaction from Vista due to my experience with it on a couple of computer at work so this is already a positive surprise.
Which codecs are kind like optimized for 64bit. I might be possibile that the codecs are making a huge difference?!

Yes, you're probably running a 32-bit codec.

Oh and the 1 bit systems were pretty dang fast.

Bob, what computer was that?

I remember working on an "RCA Spectra 70" 4-bit mainframe (it was a donation to my university's Computer Society that I co-founded in the early 70s), but no 1-bit computers which would seem to make no sense (at least not without more caffeine than I have had this morning).

Are there any 64bit packages out that can be the replacement for the codecs in V8.1? The other question is why Sony does not deliver the codecs with the software? For it makes no sence to give you a 64bit environment and than have to get back to 32bit for the last task of rendering or is it MainConcept? The Sony AVC seems to give a not so good rendering quality, that was the reason why I used the MainConcept codec.

Sorry I don't remember the part # of the 1 bit uP but it was made by Motorola. We used it in sequence controllers for power stations.
Wrote our own compiler that converted ladder logic and then it was burnt into the chips, 1,000s of them. Single bit data 'buss'

Bpb.

Bob,

>All a 64bit OS means is the operating system can address more RAM

It means a lot more.

>More RAM can dramatically increase speed if it prevents RAM being paged to disk

Right

>Outside of that there's nothing in it.

I wonder why this [mis]conception is so widespread.
There is a reason we prefer 64 bit registers to 32, 16, 8 etc.
A Windows application written to take advantage of 64 bit registers, compiled with a dedicated 64 bit compiler, will of course use the 64 bit registers for what they are worth, when it comes to churning large loads of data. Large loads of data typically exist in the multi media worlds, where we Sony Vegas users are.

A 64 bit application can load twice as much data to be calculated per operation, as a 34 bit application. So, for certain operations, things will run much faster, up to twice as fast.
Look at graphic cards, they already are 128 bit. But they do not have Terabytes of memory. So - why are they not 32 bit or 64 bit? They are 128 bit because they process zillions of pixels per. second, tons of data is loaded, tons of data processed and tons of processed data showed out again.

Some 32 bit applications already emulate 64 bit (the sound processor in Cakewalk Sonar for example). The CPUs have already been 64 bit a long time, like the CPUs in the nineties where 32 bit way long before the 16 bit operating systems followed up and switched to 32 bit.

Here, from Wikipedia:
"64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments"

Here, from Wikipedia:
"64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments"

But only when the software program is made to utalize the 64bit register, that's how I see it and Vegas shows me that.
I will make some more tests with different Codecs for rendering. Maybe I will find something out.

So far, Vegas is not using 64bit all the time and for all task, is the outcome?!

Thanks

Axel

"64-bit processors calculate particular tasks (such as factorials of large figures) twice as fast as working in 32-bit environments"The key word in this statement is "particular." If I want to add two integer numbers, say 163 and 599, together, that won't happen any faster in a 64-bit environment because the data structures for those two numbers don't require many bits to store.

Where more bits helps is when dealing with massive data structures where gigantic arrays of data must be moved, inverted, transposed, shifted, etc. The performance improvement can actually be extremely large, even when disk paging isn't involved, simply because some operations which require splitting a data structure into parts, manipulating each part, and then putting the results back together can now be done in one operation. The idea that performance scale factors would relate directly to the ratio of bits (i.e., that 64 bit would be twice as fast as 32 bit) will seldom actually be the case.

The really good news is that the stuff done during video rendering should benefit a LOT from this increase from 32 to 64 bits, and I expect that if Sony keeps working on version 8.1, we can expect to see further increases in render performance. Unfortunately, preview performance relies on a whole bunch of other factors about how an IBM PC moves data around.

That was the Motorola MC14500B. A very strange beast indeed. Datasheet here.

Mark

Hi John M,

I am a programmer and besides of using the latest compilers, I have also programmed in assembler.
I have written compression algorithms, and especially routines for handling graphics and bitmap data.

The idea that performance scale factors would relate directly to the ratio of bits (i.e., that 64 bit would be twice as fast as 32 bit) will seldom actually be the case
I would not use the word "seldom" when dealing with the topics we are interested in, namely multi media operations. When I watch the gauge crawl at snail speed, I live under the impression that more register headroom would help a lot. Of course it depends on how things a programmed, and as time passes it seems less emphasises is put on low level programming. Still I hope for dedicated 64 bit applications to dominate the scene, soon, while I belive this will speed things up, becasue of the double sized registers, not neccisarily because of more available memory.

Myself I have 4 Gb RAM, and while Vista 64 can access all of it, it still does not explain why an AVCHD footage rendered to DVDA mpg standard takes 2 minutes in Vegas 8c and 20 seconds in Vegas 8.1.
I believe this is because some 64 bit optimizations take place here.
When I have time, I will do some test renderings to find out if this difference was a pure coincidence or of it really is so (on my machine).

Darg, if you are only seeing 1.2gb used on a render that takes 5 minutes or longer to render with 8.1 and 6GB of RAM installed there's something wrong - and that's what's slowing it down. Go to options > preferences > Video tab and set your Dyanmic RAM for preview about 1000 less than the max availble and see what happens. Also, what does the max available show? If you still don't use most of your RAM set like that Vista must be causing problems, I don't know anything about Vista but XP uses all I give it and it is night and day diffence in both CPU utilization and rendering time. Try rendering a long file with cross fades - like 10 minutes of video to an MPEG2 1920x1080 template.

The maximum for dynamic preview is 5118, maximum number rendering threads is 16 for whatever reason. I have dual core so what is 16 helping?

The 1.2 GB are from task manager Memory. Under Physical Memory I see 6142 total and Superfetch is taking most of it :-).
At the moment I'm experimenting with Superfetch since it is screwing up my HD access from time to time when I'm too fast for Vista after log on. It does not let me access my own HD when it has not finished it's task. I love Billyboy :-)

Rightaway I have increased preview ram to 4118, what I see is that my physical memory usage is going up and up until the render crashes with a message like "Message Missing". What is that?!

OK, additional tests with different preview ram settings:

RAM Render Handles Time Physical RAM usage
128MB 16 7:38 1.38GB
2048MB 16 7:28 3.28GB
3072MB 16 7:30 4.24GB
3072MB 2 7:24 4.24BG
4096MB 2 crashed when RAM reached 4.something GB

Error Message is 0x80010105 (message missing)

This is pretty marginal and can be caused by finished services of M$.
Interesting is that filling all this RAM up to the maxlevel takes about 1.5 to 2 minutes.

Under 8.0 preview ram had a negative impact on render times and also 8.1 seems not to perform that well with high values.

You need to understand the nature of the problem to get a good handle on it. Rendering video is a rather unique task and the bottlenecks change depending on several variables.
This is why high end systems can perform apparent miracles compared to what a general purpose NLE like Vegas is capable of

I've played around with grading systems that can playout 2K with tracking, splines and serious color correction in real time. However the're pretty much limited to one type of media in and out. They'd probably choke worse on consummer level AVCHD than Vegas if they could read it. A lot of the performance comes from the hardware not the software. These systems have to move massive amounts of data very quickly so disk i/o and buss bandwidth is the limiting factors. Most PC mobos are not optimised for this. Due to the low level of compression employed in the codecs CPU load is relatively light and the most intense calcs are hived off to the GPU.

On the other hand consummer level codecs such as HDV and worse AVCHD don't involve shifting much data (relatively) so disk i/o performance is less of an issue than CPU performance. Many of the medium level systems by design will not work with these codecs. Instead vision is converted to an easier to handle intermediate codec.

I should also point out that running benchmarks with limited amounts of video is not realistic. Vegas caches uncompressed frames into RAM. You may think you've gained some huge performance boost only to have it vanish under real world conditions. If you watch carefully what happens when editing you can see this effect, try jumping around the timeline and you'll see playback speeds drop dramatically for a few seonds and then speed up.

Bob.

The Motorola "Dragonball" processor was really a 4-bit processor with 1-bit I/O.

That chip reminded me of intel's 4004, their first "general purpose" chip (really for calculators) that led to the 1970s x86 architecture that is still slowing us down to this day (but we gained something from 30+ years of backwards program compatibility).

When you get that messege your render is either trying to do something it can't (like using a 32 bit codec that won't work in 8.1) or you have too much RAM being used - when I push my RAM preview up to 7gb it crashes. Mine takes a minute to fill up the RAM and start pushing the processor - did you see your processor utilization go up to 100% or at least near it? What does the task manager show is being used (total) when your render crashes? If you are over your installed RAM when crashing - try a little bit lower number - like 3800 or 3500 and don't multi task when rendering. Adding a task when you are using all the RAM can crash it. You really need a file that takes a good 30 minutes to render to see the full gain of 8.1. The expected time to complete that you see at first won't be accurate (almost always high) - have to wait till it's done to get a good read on the render time. The 16 threads won't hurt anything - but won't help either - just leave it at the default.
Also, watch your drive light and see if your drive is running continuously (light is on solid not flickering) if it's on solid your drive is the bottle neck for the render speed - the CPU can only do so much processing - once it's completed the task it has to have somewhere to store it. I have 3 drives including 1 RAId5 array on mine - I read from the raid 5, OS is on 1 250gb drive, I write to a 1TB drive. This helps reduce drive constraints some as the seek time is minimized.

"That chip reminded me of intel's 4004, their first "general purpose" chip " A sad fact that TI had a superior design(a 16bit with hardware multiple and divide) but IBM's war with TI lead to the Intel 80XX being the chosen chip for the IBM PC.

There were a number of serial stream processors in the early 70's, trying to save cost on memory subsystems and interfaces. These designs also played a critical role in telecommunication advancements and circular buffers designs.