CPU Usage Revisited
dean_cefd567820
Posts: 0
I have read all the forum threads and the most popular solution is to turn of texture mapping. I seems to have helped in frame render speed, but the numbers in my resource monitor have really not changed. (>20%)
To Add my info to the question:
I7 8 CPUs 3.5 gig
32 gig ram
Asus Maximus V Extreme mother board (probably does not matter)
I am using only 27 % of the ram.
Rendering:
35000 meta ball spheres Minimal shader function, Almost transparent w/slight marbling.
It averaged out as 20 minutes per frame over night.
After turning off tex map, At 2.5 minutes per frame.
But the duty cycle of the CPUs have not changed.
Wouldn't it work as hard as allowed? If so then what is not allowing it?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Metaball models use calculated influences at render time, I believe, and transparency will also slow a render. Sometimes it's just what you want done in one shot that can bring even such a fine system as yours to its knees. There are ways to help.
First of all, it can really help to try and minimize what all gets done in one shot. Yes, transparency and translucency, reflections and caustics, etc., will all add a heavy load to your render times. Sometimes to a point where some folks tend to stop using such things. Instead of staying away from using them, instead try doing a little less of it in one shot. For example, if there would be a way to shoot 7,000 such metaballs at once, do several shots and composite them together, and if such a workflow would drastically reduce render/production time, yeah... that's what we want to do. So sometimes we just need to slim down what all is happening in each, specific render. Rendering to a format that can record alpha, for example, can really speed up the ability to composite several layers of these animations together - but I don't really know the specifics.
This is the counter intuitive thing that I can't get head around.
If there is more to do, and it really has to think about it, then wouldn't the CPUs being working harder.
Yes, the actual frames per minute would be down; because of the work it has to do to kick out a frame.
So why are they working at 20%. That tells me that the buffer is easily keeping up. Hell it can go get a beer in its spare time.
The i7 is fast enough, as I am typing this, have a browser open (obviously) and system monitors running, and rendering the middle of this cloud of spheres; But the avg CPU usage raises very little. But it does rise a little so it is not limited in any clock controls.
(Just saw the wall paper change on the 6 monitors, ((yah I know))
but even that it has time for.)
I can OC the i7 for a few hours at 4.5 gig before the fans speed up. But it isn't using what if has now.
Normally, (as far as I can deduce from history), the choke off and slow down happens after you have pushed it to a limit..
So what's choked off
Just confused.
When you say 'texture mapping', I assume you mean the Texture Spooling option, which should always be turned off for 64-bit systems?
I wonder if Metaball calculations are single-threaded? That's about what I would expect for CPU usage if part of the render was locked to a single thread.
Hi,
why should this texture spooling option turned off on 64 bit systems?
Thanks.
rk.
If you don't, then you will see that Carara very rarely manages to get your processor up to 100%, particularly if you have any of the Global Illumination options activated (skylight, ambient occlusion, caustice, or full indirect - doesn't matter what)
Running a performance monitor will show that Carrara spends an inordinate amount of time in completely pointless Disk I/O
Yes I mistyped, "Spooling", and it is off.
I cropped down a screen grab to show you the engine monitor.
You can see that it is just not working very hard. Something bottle necking. And I am out of ideas.
If Carrara wanted more, it isn't asking
I misunderstood the issue for sure. All eight of mine jam straight up to 100% during renders. I have 16GB RAM and have never come close to maxing that out in Carrara - well... while I was checking, anyways.
Could some setting in your Operating system be limiting Carrara to a certain amount of resources? I don't know about Carrarra, but some programs also have a limiter on that so you can do other things while it is busy. The OS MIGHT have something like that also? just a thought....
Gus
That would make sense.
I talked with Asus on the mother board and he said their is no controls for the board.
As far as windows 8.1 64 bit, if not Carrara than it has to be the OS.
And my guess was that if it is the OS, then someone should have something on it.
I can't find it.
I'll always defer to Fenric when it comes to coding questions. He raises a good point there. Ultimately, where your CPU utilization sits is going to be heavily dependent of the code that is being executed -- and we can't see DAZ's source code.
As an extreme example, you could write a very tight loop that literally does nothing at all. That will cause one core of your CPU to hit 100% for the duration of the loop. Do this across multiple threads and you can bury the needle on any machine.
If you really want to dig deeper into what Windows is doing, I would suggest downloading Process Explorer from SysInternals (now owned by Microsoft - their tools are free). ProcExp is like Task Manager on steroids (indeed, I refuse to trust Task Manager...it has a very shady history).
You'll be able to see individual threads inside Carrara - although you still won't know the precise code that they are executing - and you might get a little more insight into Carrara's behaviour.
I have often stated my intents to trigger a core dump of Carrara while it is running...just to poke around in its guts. My debugging skills are atrophying though. One day...maybe... :smirk:
Thanks Fenric...I missed this reply.
Pointless disk I/O? Now I'm really curious -- this will certainly kill chances of driving the CPU efficiently. Context switches and transitions to kernel mode (necessary for disk access) will also kick a system in the teeth. Another question would be if Carrara does it's I/O synchronously or not.
It is a shame that my C++ sucks out loud. I almost want a job at DAZ just so I can see the Carrara source code now. Yeah...almost...I doubt that they could afford me! :P
Thanks Fenric...I missed this reply.
Pointless disk I/O? Now I'm really curious -- this will certainly kill chances of driving the CPU efficiently. Context switches and transitions to kernel mode (necessary for disk access) will also kick a system in the teeth. Another question would be if Carrara does it's I/O synchronously or not.
It is a shame that my C++ sucks out loud. I almost want a job at DAZ just so I can see the Carrara source code now. Yeah...almost...I doubt that they could afford me! :P
I applied once, but I think that was their impression of me, too ;)
My guess is that if you have texture spooling turned on, then textures are spooled regardless of whether they really need to be or not. I have 24 gigabytes of RAM, and I have yet to get much over half of that used in Carrara - but it will still write textures out to disk if texture spooling is enabled.
Definitely don't want to be using an SSD for the drive you spool to...
That reminds me, in addition to Process Explorer, you can use Process Monitor to watch all disk activity (and more). Combined, you could probably get a decent idea of what is going on.
Honestly, it sounds like there are tons of optimizations that DAZ could be doing to Carrara if they cared to. But let's not allow this thread to devolve in the typical pettiness when someone mentions what DAZ should be doing in their opinion... :P
Not to mention, a little off topic.
The OS is on an SSD. But no data nor scratch uses it. This things boots from cold in 20 secs.
It sounds like there is an agreement that the app is limiting flow.
There seem to be a hint at first that the OS was limiting it.
In there is some one saying that they know why or is this speculation. Not that that is a bad thing.
Coming up with things that Daz should do is easy. Not like the tightly woven piece art that is Windows.
The Windows OS will not limit any program that runs on it just because "it doesn't like you." Conspiracy theorists be damned.
If a program is not running well, the problem is either that there is insufficient hardware resources (unlikely in this case, but I haven't see all the data) or the program is badly written. I love Carrara; but I have to be honest -- I think it is probably badly written. There is probably old code in there dating back 10 years and there are better ways to accomplish certain goals today.
The Windows OS will not limit any program that runs on it just because "it doesn't like you." Conspiracy theorists be damned.
If a program is not running well, the problem is either that there is insufficient hardware resources (unlikely in this case, but I haven't see all the data) or the program is badly written. I love Carrara; but I have to be honest -- I think it is probably badly written. There is probably old code in there dating back 10 years and there are better ways to accomplish certain goals today.
I'm sure some of the code goes back to the mid to late '90s. If I could run the old Raydream 5, I'd post a couple screen caps of the editors to show how little and (and how much) it has changed. Same with scans of the manual.
For this story, I gotta go with what I know - and that is Microsoft SQL Server. It was originally written just over 20 years ago by a company called Sybase. They partnered with Microsoft and by the time version 4 had rolled around, Microsoft had (limited) permission to edit the source code to fix bugs. Microsoft took over the product completely for version 6 (there was no version 5).
Now that SQL Server 2012 is mature (2014 is out soon)...I know from chatting with the developers that there is essentially none of the original Sybase code left in it. But that change sure didn't happen overnight.
I expect the same exists with Carrara. If there isn't a useful source code repository in use at DAZ, then making changes will be a nightmare. Most of us had issues with the wait for C8.5 being "DAZ Soon" but I'd be willing to put the blame on that squarely with management. If you don't fund your development properly, it will take longer to code, be buggier and be more expensive to produce. Such is the nature of programming.
And I would put the overall blame on the economy that tanked and sapped the resources of not only the public, but small companies as well. I agree, DAZ 3Ds development of C8.5 had a lot to do with a low budget, but it may have been the only budget they could afford.
Hmmm...yeah; maybe... But since DAZ doesn't like to talk to us about how they develop their products, we'll never really know for sure.
Hello.
Any comparison between DAZ with what...30, 35 people? and Microsoft with thousands and thousands more contract coders and designers? No comparison, I would say.
But since we're going there, I would venture to say that DAZ still has HUGE swaths of archaic, inefficient, and hard-to-maintain code in Carrara. Just look at the UI elements and methodologies that don't work like modern applications because they haven't been upgraded since the time before light and days.
If you ARE going to compare with SQL Server, you would not be doing justice if you neglect to mention that SQL Server is also its own OS. Yes, it runs an OS layer, underneath (on top?) Windows Server, so it does a lot of OSish stuff in order to make the database stuff happen.
Carrara, on the other hand is not an OS, although it does still employ the aforementioned obsolete hard-coded UI section, and I would not be surprised if the rendering and CPU scheduling code is just as archaic!
Carrara designers would do well to redesign around existing conventions in Windows and Mac OSX, and might be able to remove a hugely significant portion of inefficient (ne sluggish?) Carrara code, and from all areas of the program.
Oh hellz no! To quote Jules Winfield, "...ain't the same *****' ballpark, it ain't the same league, it ain't even the same *****' sport!" (Major props to you for knowing about the SQLOS layer :coolsmile:).
Carrara designers would do well to redesign around existing conventions in Windows and Mac OSX, and might be able to remove a hugely significant portion of inefficient (ne sluggish?) Carrara code, and from all areas of the program.
Yep, we are totally on the same page here. That's been the core of these arguments - DAZ is not a software house, they are a content delivery house. First and last. All else takes a backseat to that. That's why I see this primarily as a management issue. DAZ is not setting up its developers for success.
I do love Carrara - I'm not ready to give up on her yet - but LightWave does have my full attention now. I try to use both programs together; but I have to be honest with myself, the chief reason for that has been my past investment in the Content that I've purchased. If Carrara doesn't evolve it will end up on the dust-heap.
Agreed, but content delivery is probably only good for "half". Like me, I have more than half of the major products now, and I've slowed down my content purchases. I'm also teaching myself how to model. For DAZ to keep me as a customer, they're going to have to do better, and that means to upgrade the tools. All of them, because they have a legacy of obsolescence. Too many are still 32 bit and the ones that are 64 bit still need some work in the usability department. Yes, even DAZ Studio, with its inefficient and convoluted content database.
Yeah, there it is, I said it. :smirk: