My results were:
Vegas 8c - 3:54 (3 minutes and 54 seconds)
Vegas 8.1 - 3:33 (3 minutes and 33 seconds)

This means that 64 bit rendering, in my particular case, is 90 % of the time it takes to render in 32 bit. 90% is far away from my expectations, I had expected 70% or less, hopefully 50% time saving.

So I wonder where the 64 bit engine kicks in. If vegas uses 32 bit codecs or plugins, there is probably no improvement to talk about.
If anyone here use Vegas 8.1 I would be very interested to know where and with what Vegas really speeds up on the 64 bit platform.

And BTW, a 10% saving (90% of the 32 bit render time) is not enough for me to switch from XP to Vista, since all the other multi media tools I have run perfectly well on XP. (And XP 64 is no option)

ingvarai

Well, there's the catch then--the other things you need to do in the OS. I have both XP and Vista on my system, but seem to spend most of my time on the Vista side. But version 8c runs there as well, and (from what I am told) the plug-ins from the 32-bit side work there. I have never tried them though. I installed Vista 64 after buying a Sony SR11 and having a somewhat dismal time with AVCHD files in XP Pro with version 8c. Version 8.1 does a much better job with AVCHD than 8c, no doubt about it. but of course if you have to choose one OS and need lots of other tools that only run in the 32-bit OS, then there really isn't much choice...

TB

> Version 8.1 does a much better job with AVCHD than 8c

Yes, I have noticed this, preview is not as jerky in 8.1 as in 8c. And I work a lot with AVCHD, so this improvement is very welcome.
But again - a sigificant boost in performance is what I expected. Multimedia on the PC is all about churning bits and bytes, a digital mill where stuff is fed in and stuff comes out. With CPU registers twice the size, imaging:

32 bit:
FFFF FFFF FFFF FFFF
64 bit:
FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF

One would expect the 64 bit engine to get stuff through significantly faster, and in any case faster than 10%, as my test result was.
And - who knows, it may well happen, using other render settings etc. But so far - not the result I had hoped for.

ingvarai

Just this minute I installed Vista 64 and Vegas 8.1 - have up till now used Vista 32 vegas 8.0c
My CPU is an Intel Core 2 duo E6750 (2,66 GHz) and RAM 3GB
I didn´t recognize a better AVCHD preview with 64 bit than 32.
Will more RAM do it?
How much more 4GB, 8GB ?
Must I upgrade to Quad CPU to benefit the 32 to 64 bit change?
Have´nt tried render yet.
/Aje

Vegas 8.1 definitely is better than 8c at previewing AVCHD m2ts files. Just drop such a file on the time line in an empty project and let it run. It is another world. I have the same amount of RAM as you.

You do not need to upgrade to a Quad CPU to benefit from 64 bit, since the the difference (having CPU registers twice the size) will be the same. On the other hand, upgrading from a single core to a quad core, or even from a single core to dual core, is what will give you most bang for the buck, without comparison. It is just another world, regardless of 32 bit XP or 64 bit Vista.

In the mean time, I made another test. I rendered a single AVI source footage to a destination AVI file where the Pan/Crop was altered in order to give Vegas something to work on.
XP 32 bit and Vegas 8c: 16 minutes
Vista 64 and Vegas 8.1: 12 minutes

This is something! 75% render time using Vegas 81.
Now I start to think that I will move everything I have over to Vista, I will just test to what extent my VST-plugins for sound, and to what extent the Vegas plugins I have purchased also will work on Vista.

ingvarai

Thanks for reply!
I didn´t have problems with previewing m2t files its the MTS files
(AVCHD) that stutter in preview with 8.0c.
I´ve read other posts saying previewing AVCHD files is better with vegas 64 bit but I didn´t saw that.
Vista 64 can use more RAM - up to 16GB
My question is does upgrading RAM to lets say 8 GB improve
preview AVCHD files in Vegas 8.1 with Vista 64?
Aje

a 10% performance increase is HUGE. 10% of a day is 2.4 hours

I'd say your expectations were to high.

The biggest part of 64-bit isn't any faster rendering, it's more memory. Programs can use all 8gb (or whatever) you have instead of being limited to 4 total.

> The biggest part of 64-bit isn't any faster rendering

I disagree. The biggest part of 64 bit computing, in my opinion, is exactly this, that the system can load in twice as much data per clock cycle compared to 32 bit. Graphics cards already run 128 bit processors, because so much data needs to be processed.

There are ways to circumvent the 32 bit boundary for memory access, as it was in the good old days with 16 bit computing, those days we found ways to access more than 64 Kb of memory, which is the "normal" limit for a 16 bit system (Windows 3).

> I'd say your expectations were to high.
I am very disappointed about so few applications been programmed to take advantage og 64 bit CPUs and multicore processors. The systems we run now in 2008 are capable of doing much more that they do, the available software is way behind.

ingvarai

ingvarai,

As has already been said, the biggest change you'll notice with Vegas 8.1 is that the application can access more memory from the OS. You are expecting faster render times, for which there have been mixed reports. It may depend on which codec you use, and perhaps the difference will be most visible in larger projects.

Instead of rehashing many observations that have already been made, take a look at these long threads:

1. 8.0c vs 8.1 rendering speed
2. Vista 64-bit speed...

I agree: 64-bit version 8.1 renders much faster than 32-bit version 8c. Actually, version 8.1 renders faster than 8c on Vista 64-bit as well. I can't really explain that one though. I'm certainly no expert at computer programming, although I have written my share of code over the last several years--but I wonder if the fact that the 64-bit OS does allow access to more memory addresses, that perhaps more data is written into memory during the render--thus the render proceeds faster? There has to be something like this going on, because on my system the differences between 8c 32-bit and 8.1 64-bit are night & day. It's very impressive.

So yes, the 64-bit OS allows access to more memory addresses; but it's what the application can *do* with those extra addresses (compared to a 32-bit app) that makes all the difference, as I understand it. Can the CPU process data any faster because it's a 64-bit OS...? Probably not. But can the CPU in a 64-bit system access data faster because more of that data has been loaded in memory, and therefore less has to be loaded form the hard drive? That's an interesting question...

TB

the system can load in twice as much data per clock cycle compared to 32 bit

This is not at all correct. The system can work with registers that are twice the size in 64 bit CPUs, but that doesn't mean that they can do anything at all except for register manipulation with a higher degree of efficiency. In fact, for many operations 64 bit CPUs are going to be slower than 32 bit computers.

There are ways to circumvent the 32 bit boundary for memory access, as it was in the good old days with 16 bit computing

Not really, not with any degree of efficiency. For direct memory access of memory above 4G the only real solution is to upgrade the CPU.

am very disappointed about so few applications been programmed to take advantage og 64 bit CPUs

Depending on the task at hand, a significant amount of the tasks a computer performs today will not benefit in any way from "taking advantage" of 64 bit computing. For the majority of these tasks the main advantage will be the ability to utilize additional memory. Depending on a few things, video editing may or may not be one of the tasks that has little to gain from going 64 bits. It depends on what kind of math has to be done on the video.

Again, a 64 bit CPU does most things (all other factors held the same) at about the same speed as a 32 bit CPU, some times a fraction faster and some times a fraction slower. Problem is, it's hard to show this.

The new intel 64 bit CPUs, for example, have more registers than their 32 bit counterparts. This means that they can operate faster, not because they are 64 bits, but because they have more registers. If you re-factored the 32 bit CPU with the additional registers you'd see the same speed-up. Intel could theoretically have done this on their 32 bit chips, but they haven't. Doing it on a 32 bit c hip would produce the same speed-up. There is nothing preventing Intel from doing this, and 32 bit chips from other vendors have more registers than Intel CPUs, most notably the RISC CPUs, which is one of the main reasons they are faster than their Intel counterpars MHz for MHz.

Also, on Windows, Microsoft has slightly changed the way function calls are made on 64 bit operating systems. The first three arguments to a function (never mind if this makes sense to you) are passed in registers, not on the stack as in 32 bit Windows. Again, this is something MS could have added to 32 bit Windows too and they would have gotten the same speed-up, but they haven't. Such improvements have nothing to do with 64 and 32 bits however, and they are improvements that applications will take advantage of automatically without having to be "programmed to take advantage" of it.

As for re-coding to take advantage of multiple cores, absolutely, they should have, and a lot of them have. Sony for one with Vegas.

Terje, you seem to know as much about this as anyone--so please teach me something: What is a CPU register, and how does it compare with a memory register? I thought I understood it, but now (having read your post) am not sure that I did. I know there is a memory address bus that the CPU uses, but honestly do not know what a CPU registry is. My C programming days were long ago, and I'm not really sure I knew it as well as I should have back then anyway; so time has only muddied the waters even further.

As long as you are in the mood to teach, please do so. I for one would be very grateful...

TB

ingvarai wrote:
>> the system can load in twice as much data per clock cycle
>> compared to 32 bit

terje wrote:
> This is not at all correct.

Hm.. in my world it is :-)
A CPU works by loading data into registers, work on the data and then showel the data out again, ready for the next operation.
Let us say you want to encrypt a file by using a simple xor-ing. Wouldn't it take almost half the time using 64 bit registers compared to 32 bit? Have you programmed in assembler? (I have)

I see memory is mentioned as the big advantage of 64 bit systems. Now - I have lots of free memory both on my XP and my Vista when rendering using Vegas. This means, for the way I use Vegas, more memory is nice to have, but it is not the the bottleneck.
And graphics cards - they do an incredible amount of calculations, programmed into the hardware. Here speed is the bottleneck, not memory. So they have 128 bit processors..

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

and

"While 64-bit architectures indisputably make working with large data sets in applications such as digital video, scientific computing, and large databases easier, there has been considerable debate as to whether they or their 32-bit compatibility modes will be faster than comparably-priced 32-bit systems for other tasks."

and

"A common misconception is that 64-bit architectures are no better than 32-bit architectures unless the computer has more than 4 GB of memory"

http://en.wikipedia.org/wiki/64-bit

I maintain that for multimedia tasks, like video rendering, 3D rendering, sound processing - the main advantage of 64 bit is processing power - calculations power. In other words, I need SPEED, not more memory.

But more memory is indeed needed on a 64 bit system because it is "swollen", 64 bit data will take up twice the space, provided the application is a "true " 64 bit app. But that is another story :-)

ingvarai

OK, I talked to my genius of a programmer cousin (he's the smart one in the family) about 32- versus 64-bit CPUs. In an AMD (or Intel, which uses very similar, if not identical, instruction sets) CPU, there are two individual instruction sets for doing vector math (for example), among other things. so as an example, in 32-bit mode it takes two clock ticks to multiply and then add vectors (or vice versa), but in a 64-bit CPU, both vector operations are accomplished on the same clock tick. So it's faster right there. Also, in a 64-bit CPU the engineers have created additional registers that enables data to remain in the CPU register (I now know what those are, lol) and therefore the data doesn't have to be shifted back & forth between the chip and the cache. So he could definitely see how Vegas could render faster in version 8.1 than in version 8c on a 32 OS, for example.

So it is definitely about more than just the extra RAM available in a 64-bit OS; it's really about (at least for our purposes) the differences in the instruction sets between the two different OS. And btw, he is currently coding in C for applications utilizing 16 cores. He even told me some horror stories about "race conditions" where different cores are competing for the same resource, and one out-races another for use of a given memory resource. So if core 7 is supposed to write to an allocated block of memory, but core 15 wrote to it first...oops. Crash. And that means it can be very difficult to debug these issues; and I suppose that goes for things like Vegas as well--even though it's using only 4 cores in most cases.

But after talking to him for about 30 minutes tonight, I have a much better appreciation for whole multi-core application thing. And I certainly have a better understanding of why my 64-bit version of 8.1 renders faster than my 32-bit version of 8c does. It isn't just about memory.

TB

EDIT: Sorry Ingvarai, I was writing my post while you were writing yours--and it's obvious that you are far more knowledgeable on this stuff than I am. Hopefully, I've reproduced my cousin's explanation faithfully, and done him justice.

terje:
> Also, on Windows, Microsoft has slightly changed the way function calls are made on 64 bit operating systems.
>The first three arguments to a function (never mind if this makes sense to you) are passed in registers, not on the stack as in 32 bit Windows.

What compiler does this apply to? Other compilers have done this for many years (Borland worth to mention). Since so many bright people moved from Borland to MS, this it is maybe the reason they finally saw the light :-)

ingvarai

TB:
> So it is definitely about more than just the extra RAM available in a 64-bit OS

Let us imagine a street with two bars, one at each side of the street. In the left side bar 32 people are drinking beer, on the right side we have 64 beer drinkers. Which bar will first empty the barrels in the basement?

Computing is complicated. And with the new CPUs and especially the new agressive compilers, the landscape is indeed difficult to manouvre in. But - a 64 bit CPU can load in almost twice as much data to do calculations on, as a 32 bit processor. With an application written to take advantage of this, the benefits are obvious: SPEED.

"He even told me some horror stories about "race conditions" where different cores are competing for the same resource, and one out-races another for use of a given memory resource. So if core 7 is supposed to write to an allocated block of memory, but core 15 wrote to it first...oops. Crash."

LOL!! Super LOL :-))
Coming across an article about this phenomenon, I recently solved my own crash problems, see here: My recent topic

> Sorry .. it's obvious that you are far more knowledgeable on this stuff
I know something, yes, but your friend knows MUCH more :-))

ingvarai

Ah--the core voltage issue...I remember posting in that. My story about Jim Roseberry and Prime95! I didn't even know there was such a thing as a Mersenne prime number before using that application! LOL.

But my cousin's abilities as a programmer simply amaze me. To spend weeks debugging code that runs 16 cores and fails once every 24 hours of running, just blows my mind. He told me he has to come up with new ways to simplify the number of cores that could possibly be causing the issue; or at least make it fail more frequently, so that he has more chances to debug the thing. And all 16 cores are executing the same block of code much of the time. Sheesh...

I like your beer analogy though--but I'd like to change it slightly: Drinkers in each bar have two mugs of beer, and must drink every drop in each mug. In the bar with 32 beer drinkers, they have to first drink from one mug and then from the other. But in the bar with 64 drinkers, they can drink from both mugs at once...

Who's going to pass out first?

TB

<<Where does 8.1 and Vista 64 excel? >>

A few days ago I upgraded my OS to Vista 64, added another 4G of RAM (for 8G total), and installed 8.1.

What I gained:
More frames per sec when previewing
No more lockups or errors when rendering HDV at Best quality setting
Able to render in 32-bit mode at Best setting faster than in 8-bit Good with 8.0b/XP
In general, all programs seem faster and look nicer with Vista64

What I lost:
Audigy sound card (pops & clicks when recording)
Can't find an audio interface with 64-bit drivers
My favorite VST audio plugin (it's installed correctly but Vegas won't recognize it)
Excuses for cursing

NOTE: I'm currently using the motherboard's on-board RealTek audio and it works just fine

> Can't find an audio interface with 64-bit drivers

Try Echo Audio, most of their audio devices have them. Some of M-Audio audio interfaces have them now and more are on the way. PreSonus has 64-bit drivers for some of their devices too. There are plenty to choose from.

~jr

I think you're missing something important here.
A 64 bit architecture and a 64 bit operating system are two different concepts entirely. Take the vector mulitply example above. Code running under either a 32bit or 64 bit OS will run faster on a CPU with a 64 bit acrhitecture, the OS has nothing to do with individual instructions and how they execute.

Bob.

I think you're missing something important here
I am not sure if "you" in this case is me, but when I discuss this topic, I regard the CPU a black box, and comparing 32bit and 64bit computing is still valid. If this black box is executing everything you throw at it faster than before, fine, code optimized for 64 will still do the job faster than the 32 bit counterpart.

In 1994/94 when the first 32 bit public operating systems saw the light of day, IMBs OS/2 and MS Windows 95, the CPUs had already been 32 bit a long time, running 16 bit code.

If you have an image processing application, and want to adjust the overall brightness of a bitmap, 64 bit code will do this job twice as fast as 32 bit code (approximately). At least in theory :-)
If you do not agree, I am interested in discussing it, because this is how I think it has to be, and maybe I am "missing something"

ingvarai

"My results were:

It often amazes on how people like to split hairs when it comes to rendering speed. Obviously time is money and the more you tie up a machine the less you can work on other things... but geez... come on. You work for days or weeks or even months piecing and acceptable time line together only to expect a render to be complete in the blink of an eye.... and are quite upset when it isn't???

Why is it that so many figure that a faster/slower render time means a better or worse product??? I just don't get this concept. One would figure that time line operation to be by far the more important aspect... wouldn't they??

If I can get a faster render time then hey... that's extra gravy on the plate! But what is essential are things more like smooth playback, better frame rates, more time line switches dials and knobs...etc. That to me makes a better product. This speedy render time stuff is really nice, but it's not exactly a high priority as an end result.