Vista 64 - Vegas 8.1 - does "change happen"?

ingvarai wrote on 11/15/2008, 9:04 PM

There has lately been so much talk about all the change that will happen in politics, my concern is more to what extent Vista 64 bit and Vegas 8.1 means a real "change" when it comes to speed.

I have installed Vista 64, and Vegas 8.1. I notice that previewing my AVCHD footages run much smoother. My test render, a 1 minute m2ts file rendered with an unsharp mask filter, takes 3:54 on XP 32 and 3:33 on Vista 64. Both XP and Vista run on the same machine, dual boot, so the results should be comparable.

Where does 8.1 and Vista 64 excel? What kind of "jobs" show that 64 bit is much better? I upgraded to quad core 2 days ago, and that means a real change :-)

Those 20 seconds I gained will not necessarily make me prefer Vista to XP.

ingvarai

Back to post

Comments

ingvarai wrote on 11/20/2008, 2:49 PM

It often amazes on how people like to split hairs when it comes to rendering speed.
..
Obviously time is money

I am a hobbyist when it comes to Sony Vegas, I make a living as a programmer :-)
My approach to this is [almost] of pure technical curiosity. I say "almost" because I generally am disappointed by how slow things move when I do my multimedia projects on PC. I feel it prevents me from being creative because it takes so long time from my idea come up, till I can see the final result. Like in the good old days when a good deal of work had to be done in the darkroom before my pictures were developed.

If I were a professional, I think I could perfectly well live with the way things are, I would know what I was doing, accept to wait, and probably organize my day different. Batch render at night time and so on. As it is now, I want to experiment and try new things out, and get tired of watching gauges crawl along at snail speed.

Why is it that so many figure that a faster/slower render time means a better or worse product???
So all in all - I do not criticize anyone in particular, I am just airing my general disappointment when my [unrealistic] dreams do not come true.

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.
I believe you are a professional. See what I said above. I do this when I come home form work, in the evening, I just want to se results before I go to bed, so to say :-)
I have applications at work that also are slow. I have no problems with them. I know precisely what I do, how to do it, and when to do it, and especially how to plan for getting it done.

ingvarai

ingvarai wrote on 11/20/2008, 3:01 PM

Coursedesign:
Using registers to pass arguments goes back to at least the 1960s IBM 360 mainframes.

Afterwards, when thinking about it, I believe the original poster of this, Terje, meant that the Windows 64 bit API is using this. Basically, you are free to use whatever solution you want, as long as the calling method and the called method agree upon how to communicate.
The Windows API, ont the other hand, has to obey strict rules, otherwise it would be very hard to document it, and software writers outside Microsoft would face an impossible task calling API functions.
It is obvious to me that Microsoft now finally saw an opportunity to change the API calling convention(to the better) when the 64 bit Windows API was introduced, they could not have a mixed solution in the 32 bit API of course. For us - the users - it will mean nothing in some cases, in other cases things will move faster.
ingvarai

Coursedesign wrote on 11/20/2008, 3:15 PM

Programmers are always trying to reduce instruction overhead. In spite of this, using a stack to pass arguments became the standard, because it made it easy to write recursively (a function calling itself) and because it made it easy to preserve the state of a machine when servicing a priority interrupt for example.

srode wrote on 12/2/2008, 6:49 PM

I use XP64 as my OS and compared 8.0c vs 8.1 and for my projects rendered 32bit instead of 8bit with say 10 clips with 1 second cross fades the speed difference is very noticable, probably 30 to 40% less time for comparable rendering projects.

I went from 4 to 8GB RAM and reduced the time another 30% on the formats where Memory was the choke - Rendering for Vimeo format was one that caused this problem - Windows Task Manager showed I was using betwee50 and 60% of the CPU capacity indicating there was something else choking the speed - adding upping the RAM to 8GB allowed 95 to 100% utilization of CPU and the one project I used for comparison went from 25.5 minutes to 18.25 minutes rendering time, both in 8.1