Confusing Mac Pro performance problems

Discussion in 'Mac Pro' started by guitarmaster18, Jun 4, 2008.

  1. guitarmaster18 macrumors regular

    guitarmaster18

    Joined:
    Mar 27, 2007
    #1
    Alright everyone, this one has really been driving me crazy.

    I have a mac pro 8 core 3GHz 16GB ram with a Radeon X1900 graphics card (should be beastly at 3D rendering, right?). I use cheetah3d for my renders. At this moment, the mac pro is rendering slower than my blackbook 2.0, in some cases by significant amounts (7 secs on blackbook vs. 13 secs on the Mac Pro). I was astonished by this, so I took a look at Activity Monitor to see what was going on. Well, according to Activity Monitor, the mac pro was only using 10% of it's total processing power while rendering. My blackbook uses every bit of power it can get. All I can say is WTF?? At this moment, the Mac Pro is useless to me. Does anyone have any idea what is going on?

    Thank You!
     
  2. echoout macrumors 6502a

    Joined:
    Aug 15, 2007
    Location:
    Austin, Texas
    #2
    I have the about the same setup as yours, but with the 2600 card. Anyway, I do a lot of 3D work but don't know what cheetah3D is. Does it support multiprocessing?
     
  3. Frozonecold macrumors 6502

    Joined:
    Mar 23, 2005
    #3
    I would check to see if it has some sort of low-CPU usage setting turned on.
     
  4. D4F Guest

    D4F

    Joined:
    Sep 18, 2007
    Location:
    Planet Earth
    #4
    which renderer are u using? Does it support multi core?
    many don't so it might not be a issue at all.
    also what memory are you using?
     
  5. Firefly2002 macrumors 65816

    Joined:
    Jan 9, 2008
    #5
    The odds that it doesn't support multiprocessing are low, given the "blackbook" (I assume you mean black MacBook?) clocked a full 33% lower is outpacing it.

    It does sound like it's only using one core though, since one core out of an oct setup would be 12.5%.
     
  6. Frozonecold macrumors 6502

    Joined:
    Mar 23, 2005
    #6
    1 core of an octopus Mac Pro is 100% 8 cores is 800%.
     
  7. zmttoxics macrumors 65816

    zmttoxics

    Joined:
    May 20, 2008
    #7
    Well, it is my understanding the ECC ram has longer latencies due to the error checking. On top of that it could be that with such a small render, that the system is spending all of its time managing ram instead of the render. I am not sure, I haven't done any of that stuff on a mac and I don't own a mac pro (yet).

    What I would try is drop the system down to 4 gigs (4 sticks) on a single board. That might keep latencies down by managing less ram.

    You could also try limiting the system to 2 cores (there is a sys pref program some wheres, another forum thread mentioned it). That would force the app to do less multithreading (the program might not be built well for it) matching the scenario of you Macbook.

    The last difference might be the cache on the hard drives. If you have a newer drive in your Macbook it is possible it has more cache on it then your older drives in the Mac Pro.

    If those don't help, I would check your video card is in the correct slot (16x), and do a hardware check on all of the components. Sometimes a bad disk and slow things down. Good luck!
     
  8. ASFx macrumors regular

    Joined:
    Feb 24, 2008
    #8
    Maybe your hard drive is running a lot slower than your macbook for some reason. Try benchmarking the drive and see what you find, or try using a separate drive for scratch and see if there's any improvement.
     
  9. Firefly2002 macrumors 65816

    Joined:
    Jan 9, 2008
    #9
    Hahaha yeah *cough* I knew that.

    That's even weirder, actually, given that it's at 1/80th total usage... you'd think it would be WAY slower than the MacBook.

    Yes, ECC has slightly higher latencies and generally less aggressive timings, but that's definitely not the issue... you'd never notice the performance difference in real life... they'd only ever show up on memory benchmark tests (and I suppose a little bit in general benchmarks, but less so); and let's not forget, all Mac Pros have ECC RAM. Actually the fact that theyr'e FBDIMMs has more of an impact on them than them being ECC.

    Again, the number of sticks of RAM does increase the latency a bit, but not that noticibly in real-world performance, and certainly not to the point where you'd be running at 10% CPU utilization. For that to be the case, not only would your program have to be completely memory intensive, you'd have to be running... 60ns EDO RAM ;)

    Hard drive cache size doesn't matter in any situation.

    Stripping it down to less memory might not be a bad idea though just to simplify things.

    I assume this is the only program with this problem?

    Do you have the latest version of Cheetah3D? I looked it up and they just released an update May 14th with bug fixes, so maybe.. =/
     
  10. zmttoxics macrumors 65816

    zmttoxics

    Joined:
    May 20, 2008
    #10
    You are missing the point. He is complaining about mere seconds. Any slight thing can cause that kind of time difference. Taking into account things like the memory setup is vital.

    Also, hard drive cache is very important. I recommend you read into it some day.
     
  11. Firefly2002 macrumors 65816

    Joined:
    Jan 9, 2008
    #11
    Oh, my mistake.

    I figured that when he compared an eight-core, 3 GHz tower to a two-core, 2 GHz laptop, that it would be significant if, say, the 2 GHz laptop performed a task nearly twice as fast as the tower, which technically has, at least in theory, six times the horsepower under the hood.

    But since it's only seconds we're talking about, and not, you know, hours, you're of course right.

    Except, half of all benchmark testing deals with things that take only a few seconds... photoshop benchmarks (PSBench) is a good example. When the G4s came out, and Adobe optimized photoshop for AltiVec, the PS 5.5 benchmarks that showed the G4 outstripping the G3s nearly twice as fast in Lighting Effects impressed many. The difference? A few seconds. But it represented a 100% increase in speed.

    No, it isn't. Any slight thing can cause that kind of difference if the total time taken was a few minutes, and the difference was a few seconds. And that would only be on identical machines.

    However, as he's explained it, one took 7 seconds, and the other took 13 total.

    Even then, memory timings that slight probably wouldn't make much difference, and certainly wouldn't make anything he'd ever notice. Barefeats ran 667 MHz FBDIMMs in the new Mac Pros, and they performed identically to when they had 800 MHz FBDIMMs in them. And latency is even less important than that. Memory latency doesn't just apply to the beginning of an operation, adding a few seconds to the start. Even if it were (which is a ridiculous idea), it certainly wouldn't add in seconds. The only time it makes a difference is when something takes a reasonably long time, then you can start counting the difference in seconds.

    Here, BareFeats investigated memory timings in the MacBook Pro.... one set of benchmarks in a long line of memory testing which has been going on for years (think AnAndTech, FiringSquad, Tom's Hardware, etc): http://barefeats.com/mbpp03.html

    The conclusion? Less than 1% difference most of the time.

    If you want to read up about memory latency, you could try here, at Ars Technica: http://arstechnica.com/paedia/b/bandwidth-latency/bandwidth-latency-1.html

    You're absolutely correct, hard drive cache is important. So long as you've got some. 512K is really enough. More doesn't help, especially over 2 MB.

    And explain to me how you figure hard drive cache would make any difference at all in rendering, when all the data has likely been stored in RAM? Actually, since you've obviously read up on it so thoroughly, why don't you explain to me how hard drive caching works?

    Cache only matters, first of all, for frequently used data... and only data that's already been accessed, save during things like burns which employs precaching. Rendering shouldn't even involve the hard drive.

    The only time you'd ever use a hard drive in an application like, for instance, Photoshop (which obviously doesn't involve rendering) is when you run out of memory, and hit your scratch disks. That doesn't really even happen anymore when you've got 8 GB of RAM devoted to a task.

    Cache helps for burst rate improvements... I can't think of much else. CPU L1 and L2 cache size matters. Hard drive cache size, not so much.

    Cache size doesn't matter. Want to read about it?

    http://www.tomshardware.com/reviews/understanding-hard-drive-performance,1557-5.html

    I actually made a thread about that a month or so ago with that link. http://forums.macrumors.com/showthread.php?t=480423

    I saw a test years before between 2 MB and 8 MB. Same thing, only the 8 MB was often slower.

    They of course only measured things that have to do with hard drives.. you won't find anything that has to do with rendering, I'm afraid.
     
  12. zmttoxics macrumors 65816

    zmttoxics

    Joined:
    May 20, 2008
    #12
    You are about a post away from hijacking this thread and turning it into a personal bout with me - which isn't cool since I wasn't looking to insult you. If I made you upset, I apologize.

    Here is a quick rebuttal though:
    Harddrives: Who knows man. Unless we have his model numbers, and proven benchmarks you can't toss out the idea. I bet the program he is using dumps its buffer to temporary files often for different undo states and render states. We can't say how the program is working, we don't have the circumstances.

    Memory speeds: http://barefeats.com/harper5.html You can't pee in my corn flakes and tell me its milk. You also can't tell me they are exactly the same performance. Those aren't identical results. Now imagine that for some reason, god gave him different ram for both systems because the cosmos weren't aligned properly that day, and they perform differently - producing different render times.

    The point is, these systems are completely different configurations. To produce the same results you'll want to bring them close together. I suggested those options as they are most evident to be different between systems. You can argue with me for weeks but it wont change the fact they are 2 different platforms. Again, sorry if I upset you, however I have zero intentions for continuing this with you.
     
  13. Firefly2002 macrumors 65816

    Joined:
    Jan 9, 2008
    #13
    Yeah, sorry.. I get snappy when I'm really tired. And it's true, the post was a lot longer than I meant it to be.. but he hasn't returned yet so.... :D

    And right, but logically it's a drive equal to or faster than the stock drive, so even if the hard drive played a role, it wouldn't be a factor. Also, If you look closely, the only differences in the BareFeats tests were in synthetic benchmarks.. the real-world tests were identical.

    My point is, memory isn't a factor, since he's got enough, and rendering basically comes down to CPU power. I just don't want him to be worrying about memory latency when he shouldn't be.

    Anyhow, given how it's only using 10% of the CPU, my guess is it's probably some sort of conflict between hardware and software, or something of that nature... I'd suggest updating to the latest version if you can (though I didn't see anything about Mac Pro performance when I checked the update notes..... and couldn't even find anything on Google).

    Also, if that doesn't work or isn't an option, perhaps you could find a program that lets you manually allocate CPU time to certain processes, meaning you could devote 700-800% of your CPU time to Cheetah3D. I don't know if that's actually doable, it's just a thought.

    Have you checked out their Forums and FAQ?

    One last thought... you say it's only using 10% of its processing power... do you mean the total CPU usage for the whole machine is 10%, or that it's listed as 10% under Cheetah3D?

    I think maybe if you looked at all the processes, there would be a child process of Cheetah that might be using more; and again, if the total CPU usage isn't 10%, what is it reading at while rendering?
     

Share This Page