Comments

JJKizak wrote on 4/5/2008, 5:08 AM
I use default settings and have never had an instance where all four processors were not functioning at 50 to 100%. Vista 64, Q6600.
JJK
blink3times wrote on 4/5/2008, 5:41 AM
From what I have seen, it very much depends on what you are doing. When rendering M2T you should see all for cores working at close to 100%. But I'm playing around with uncompressed avi right now and interestingly enough the 4 cores are only functioning at around 35%.
JohnnyRoy wrote on 4/5/2008, 6:13 AM
> From what I have seen, it very much depends on what you are doing.

This is absolutely the case. What people who don't understand how computers do multi-tasking don't realize is that multiple cores can only be utilized when the task has steps that can be done in parallel. Work doesn't magically use all of the cores at 100%.

Think of it this way: You are trying to dig a hole and you have 4 workers standing around a ditch but you only have two shovels (a video shovel and an audio shovel). They can take turns using the shovels 25% of the time each, but you will never get more that 2 workers worth of work done (50% of your total work force). That's what happens in the computer. Unless there are 4 tasks that can be performed simultaneously, you will not use 4 cores at 100%. Rendering to MPEG does a good job of using all of the cores so I assume that there are enough sub-tasks that can be performed in parallel to keep them all busy.

~jr
blink3times wrote on 4/5/2008, 6:23 AM
In fact quite interesting.... when rendering with cineform intermediate over to ANY of the avi intermediates I'm getting SLOOOOOW renders of only 35% core usage.
pmooney wrote on 4/5/2008, 9:08 AM
If you hold the SHIFT key down while selecting "preferences" from the OPTIONS menu, you will see a new tab called INTERNAL.

If you select this tab and scroll down a bit, you will see scores of internal settings you can change for Vegas. Two of the settings are maximum and minumum rendering threads.

Change the maximum # to 8 and the minumum # to 4. You will then see all of your cores used in the rendering process.

When I made those changes, my render time on John Cline's render test dropped from 2:10 to 1:19. I've not had any crashes or issues since I made the change to those internal settings.

Enjoy the explosion in speed!
TimTyler wrote on 4/5/2008, 9:21 AM
While we're on this topic....

I've recently thought about replacing the Core 2 Duo 6700 I've got with a Quad processor of about the same speed. The board I have is quad-ready so it's just a matter of popping in a new chip I think.

Should I expect dramatically faster render times for MPEG2 and Cineform AVI, or is the upgrade cost not really worth it?

(Running 32-bit XP)
Christian de Godzinsky wrote on 4/5/2008, 9:23 AM
Hi pmooney,

Would be nice to know what core you have, and running at what speed? Also, the mem bandwith is of interest. It seems that you have beat my rendertest speed;) My record so far is 82 seconds, yours is 79! Did you run at best quality and 1080i? Or are you running 8 cores?

Christian

WIN10 Pro 64-bit | Version 1903 | OS build 18362.535 | Studio 16.1.2 | Vegas Pro 17 b387
CPU i9-7940C 14-core @4.4GHz | 64GB DDR4@XMP3600 | ASUS X299M1
GPU 2 x GTX1080Ti (2x11G GBDDR) | 442.19 nVidia driver | Intensity Pro 4K (BlackMagic)
4x Spyder calibrated monitors (1x4K, 1xUHD, 2xHD)
SSD 500GB system | 2x1TB HD | Internal 4x1TB HD's @RAID10 | Raid1 HDD array via 1Gb ethernet
Steinberg UR2 USB audio Interface (24bit/192kHz)
ShuttlePro2 controller

blink3times wrote on 4/5/2008, 9:52 AM
"Change the maximum # to 8 and the minumum # to 4. You will then see all of your cores used in the rendering process."

Thanks but it doesn't do much for avi renders. I have a pretty fast machine with all cores blazing with M2T renders.... but with uncompressed avi core usage drops to 35%
Paul Masters wrote on 4/5/2008, 11:33 AM
A lot of stuff in INTERNAL!
Do you know of a way to chnge the cursor color?
I have changed to a more gray windows background and for some reason, the cursor 'line' nearly dissapears.

Thanks for any pointers.

Paul Masters
VanLazarus wrote on 4/5/2008, 12:52 PM
Hmmmm, thanks for the info about holding down SHIFT when bringing up preferences. Seems pretty cryptic!

Changed the MAX and MIN threads to 8 and 4. Will see if it speeds things up.

I'm rendering a DVD Architect compatible NTSC MPG stream.

Unfortunately, my tests are hitting a brick wall because the NEAT VIDEO plug-in keeps on running out of memory no matter what setting I have. (I have 4 gigs of RAM!!!).
Jay Gladwell wrote on 4/5/2008, 3:35 PM

Still shooting and rendering in SD here, and the change in settings really made a difference in renders!

Pat, how did you know that was there?


VanLazarus wrote on 4/5/2008, 4:32 PM
My results:

Categories:
NTSC MPG = DVD Architect Video Stream MPG file
HD M2T = HDV 1080 60i M2T file
HD AVI = HDV 1080-60i intermediate AVI file

My system:
Quad-core Vista 32-bit SP1 with 4gigs RAM

The columns represent the different settings for the maximum and minimum render threads (internal), and dynamic RAM setting.

The result times are given in seconds.

-----------------Max4-------Max8-------Max4
-----------------Min1--------Min4-------Min1
-----------------128mb-----128mb----256mb

NTSC MPG---35-----------36----------36
HD M2T-------145----------146--------146
HD AVI---------135----------145--------145

Well, increasing the maximum/minimum render threads, or dynamic RAM just slows down my renders. Am I on crack?
rmack350 wrote on 4/5/2008, 7:34 PM
Wellllll...

First off, not all codecs are multithreaded so you might not get more than a video and an audio thread going, depending on what you're doing. Second, I suppose you could find that the overhead of trying to manage 8 threads might actually slow a render down. Given your slower results you might find in your specific case that lowering the setting to 2 might actually speed things up.

Rob Mack
marks27 wrote on 4/5/2008, 8:42 PM
"Change the maximum # to 8 and the minumum # to 4. You will then see all of your cores used in the rendering process." Thanks but it doesn't do much for avi renders. I have a pretty fast machine with all cores blazing with M2T renders.... but with uncompressed avi core usage drops to 35%

I think you might find that this is because working with uncompressed AVI is fairly much a copying process rather than a rendering one (unless you are doing lots of effects and transitions). This means that rendering is more likely to be constrained by disk I/O than CPU speed -- there is comparatively little for the CPU to do. Going to mpeg, H.264, wmv, etc means that there is a good deal going on encoding-wise.




John_Cline wrote on 4/5/2008, 10:13 PM
Personally, I think that people spend too much time obsessing over what Task Manager is reporting for CPU usage. I think Johnny Roy nailed it in his earlier message; some functions just aren't going to peg the CPU meter at 100% for all cores.
busterkeaton wrote on 4/5/2008, 10:48 PM
Jay, it was in this thread last month.

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=583564

Van, what was also in that thread was the warning that you can really screw up your Vegas installation if you mess up the internal settings. That's why it's so cryptic, I don't think it something regular Vegas users were supposed to know about.
busterkeaton wrote on 4/5/2008, 10:50 PM
I think you may have to change that in Windows itself.
Jay Gladwell wrote on 4/6/2008, 6:19 AM

John, there's an excellent chance that I've misuderstood what you're saying here: "...I think that people spend too much time obsessing over what Task Manager is reporting for CPU usage. ... some functions just aren't going to peg the CPU meter at 100% for all cores."

I shouldn't speak for anyone else, but I think it's safe to say that not all of us are as technically inclinded as you, and some of the other forum members, are when it comes to the internal intricacies of computers and software. Although I've built a couple of computers (under the tutelage of a guru friend), I really don't understand much of what goes on inside. I probably know more than the casual or average computer user, but people like you have forgotten more than I'll ever know about them.

For example, as I mentioned above, there was a significant increase in my render times and CPU usage when I applied the suggested alterations in Pat's post above. On my old system I had a project (SD) that was 5 minutes, 30-seconds long. It had several transitions and there wasn't a single frame that didn't have some FX applied (mostly color correction). On my old system that project took hours to render (can't recall the exact number). With my new quad-core, and the adjustments to threading, yesterday it took 11 minutes and 35 seconds to render!

Prior to the adjustment, the quad-core's CPU was running at around 35% on renders. After the adjustment, it was hover around 97%. Maybe I'm wrong, but it only seems logical to think that if more of the CPU is being used for rendering, the project will get rendered faster. The CPU usage seems to be the most logic indicator of what's happening under the hood (or bonnet for those in the UK). Is my logic incorrect?

That's why I upgraded to a quad-core, to get markedly faster render times. Now I have, or so it appears. Frankly, I was disappointed when I saw the CPU hovering at 35% on renders. If I buy a 12 cylinder Jag, I want to run on all 12 cylinders, not just 4! Does that analogy work?


JJKizak wrote on 4/6/2008, 6:44 AM
Everybody here is missing one thing---the accuracy of the task manager to monitor CPU activity---. Mine shows 100% on non-complex projects and 35-50% on complex projects which makes no sense at all. That means the activity monitor function is monitoring something that is not accurate to what we think is happening---like monitoring wind noise in a car to determine the speed---.
JJK
farss wrote on 4/6/2008, 6:59 AM
You could have something there. It seems to be a difficult task to actually determine how many of the CPU cycles are being used to do something.
On the other hand the CPU can well be idle waiting for data to arrive from the disk. So highly compressed video that uses a hard to decode codec could mean that the CPU does work hard, only relatively small amounts of data are needed to be read from the disk.
On the other hand uncompressed video needs very little work by the CPU to decode but requires very large amounts of data to be read.
Aside from that some things cannot be split accross tasks due to dependancies.

Bob.
pmooney wrote on 4/6/2008, 7:34 AM
I apologize for my earlier post gentlemen. I misread the initial post.

Changing the render threads worked for me because I have a DUAL quad core processor instead of a single core. 8 threads brings both dual cores into the render, hence the amazing boost in the rendertest.

On a SINGLE quad core, changing those threads doesn't help to increase the CPU usage. I know because I tried to change the settings on a single quad machine and the render speed, though very fast (2:10), did not improve.
JohnnyRoy wrote on 4/6/2008, 8:34 AM
> If I buy a 12 cylinder Jag, I want to run on all 12 cylinders, not just 4! Does that analogy work?

No that analogy doesn't quite work because an internal combustion engine uses the cylinders in a round-robin fashion where each one gets to divide the work of making tiny controlled explosions that turn the crankshaft. A computer can't always partition the work in such small increments.

A valid computer analogy to the 12 cylinder engine might be a render farm. If you bought 12 computers to form a render farm you would expect Vegas to use all 12 computers. This works as an analogy because a project can be split into 12 segments (assuming it's larger than 12 frames) and each computer can be given a segment to render and then the main computer can simply stitch them together. The job is partitionable so multiple workers (in this case computers) works.

And that's key: the job must be partitionale into things that can be done in parallel and not rely on the outcome of one to affect the others. This is just not always possible with computer problems. Parallel processing (i.e., using multiple CPU's) requires a parallel problem to solve.

The other problem is that jobs that can be parallelized are not written that way as a computer program. In other words, while you can see how a render could be partitioned more efficiently, the programmer did not see it that way and wrote a single threaded program that starts at one end and reads until there are no more frames to process. It doesn't matter how many CPU's you have, this kind of program will always emulate a single CPU. Some of the renderers are like this in Vegas while others are not. As multi-CPU PC's become the norm, more programmers will take advantage of this and make their programs multi-threaded (threads are the computers smallest unit of distributable work)

~jr
Jay Gladwell wrote on 4/6/2008, 8:50 AM

Thanks, Johnny, for the clarification. I had always imagined the dual quad-core as a kind of mini-render farm.

So now it's more like my car. I don't know how it works or how to really fix it, should something major go wrong, but I do know how to drive it. All I know is that since I adjusted the threading as Pat suggested, my render time is significantly faster than before (excluding the older system).


megabit wrote on 4/6/2008, 10:48 AM
Interesting discussion it is... Unfortunately, I cannot confirm any influence whatsoever of setting the max and min threads number to anything other than default, on how my renders are using the cores of my Quad. All render jobs (save for audio) do use all 4 cores, but sometimes at nearly 100%, while at other occasions - at a mere 25%. Really don't know why; interestingly under Vista x64 it's 100% much more often than under XP.

AMD TR 2990WX CPU | MSI X399 CARBON AC | 64GB RAM@XMP2933  | 2x RTX 2080Ti GPU | 4x 3TB WD Black RAID0 media drive | 3x 1TB NVMe RAID0 cache drive | SSD SATA system drive | AX1600i PSU | Decklink 12G Extreme | Samsung UHD reference monitor (calibrated)