Yes I have. Sorry, should have added that to the spec list in my post.
Any other difference between the two computer systems?
Different antivirus software/security settings? (I ask that because some such software can cause a real performance hit.)
They're nearly identical, just to avoid most headaches. they each have a few different apps here and there, but we've turned everything off but after effects for these tests.
1 person found this helpful
While it is possible that the OS is related to the issue, testing on a 16GB 8 core Mac with both 10.5.8 and 10.6.4 installed has not shown a noticeable speed difference in rendering speed with the same multiprocessing settings between the different OSes. However, these tests do not include XDCAM footage. The only major issue that affected After Effects in 10.6.4 was fixed by the graphics update which should have come through Software Update a month or so ago.
Could you try these settings for your project? Set the Memory preference to Reserve 4GB for other applications, and the Multiprocessing pref to allocate 1.5GB/bkgnd cpu. Then restart the machine, open AE and render the project. Let us know what the render time is.
Will, i tried your settings and it is definitely faster. render time = 8min.
that just seems bonkers to me...setting more ram per CPU results in 4x the render time? what's going on here, Will? and why would setting the multiprocessing configuration THEN restarting the machine have any different effect then just setting it up and hitting render?
so your config was helpful, but still not up to the speeds we had before. at least it's closer. any additional help would be greatly appreciated.
Good to know, thanks for the update. 10.6.x does manage memory differently, but our testing for performance has shown a slight improvement in the newer OS. So I am guessing that the OS update is not the issue. I just ran another test on a Mac with your configuration and saw a 4% improvement on 10.6.4 over 10.5.8.
It's uncertain what state the system memory was in when you started your tests. That's why I asked for a restart of the computer. The times reported seemed like there was a possibility that the OS was swapping. XDCAM footage places a high demand on system resources. But it's hard to say without being there.
What I was seeing with the initial post was that the two extremes of allocation per background cpu were tried, but not the middle ground. To better see this, launch the Activity Monitor utility or look at the last line of the MP preference. With the 4GB reserved and the 3GB/ bkgnd cpu setting you weren't getting any extra processes spawned for multiprocessing. You can see this in the preferences multiprocessing section as "Actual CPUs that will be used = 0". Then, by setting the pref to .75GB/bkgnd the app launched 8 bkgnd processes, but for the task at hand, I am guessing that they were starved for memory and sometimes failed to render. This was faster than the first test, but still slow. By setting the pref to 1.5GB/bkgnd cpu you were now getting 4 new processes spawned for multiprocessing. The background processes had enough memory to succeed so that made it render faster still.
Now, try setting it to 1GB/bkgnd cpu. That will launch 6 processes which should render faster as long as that is enough memory for the task. If the Memory pref for Reserve RAM for other apps is set back to 3GB, it will allow the spawning of 7 bkgnd processes. If that is a successful balance for this project then it will be the fastest render time. But, our testing shows it will be at the risk of starving the OS for memory, thus the more conservative 4GB recommendation for a 12GB system.
It's a fine line and why we are recommending that one give up a little speed by reserving more memory for other apps. True, there will be less processes spawned for multiprocessing, but there will also be less chance for the OS to start swapping to disk which greatly slows down performance for all tasks. If that compromise is not acceptible, then the alternative is to buy more ram so that all 8 processes can adequately receive enough memory for the job, and yet still maintain adequate reserves for the OS and other apps.
Thanks for the thorough explanation, Will. I really appreciate the help.
I left the memory allocation to reserve 4gb, set it to 1gb per CPU, and reserved 3 CPUs for other apps to give me 5 actual CPUs used = 10min render.
i'll be setting it back to the last config you listed.
but here's the part i don't get: I rendered the faster version file getting closer to the previous speed i had on the earlier OS, then set the above configuration and hit render. it got about 50% through and was at nearly 12 minutes. so I stopped the render, set up a new one in the queue, quit after effects, restarted the machine, and with the exact same settings got a full render in the above stated 10 minutes.
If i want to test MP settings, am i going to have to restart the machine every time? seems crazy to have to do that.
I'll do some more digging on the processes active when it's rendering and see if maybe there is some weird app stealing RAM somewhere. thanks again.
For the sake of isolating the problem it helps to have a clean slate. By restarting the OS, there is a fresh memory map. If you keep the Activity monitor open and watch the System Memory tab, you can see better what is occuring on the system level. Most particularly watch the Free memory and Swap Used. If the free memory goes down to zero and the OS starts swapping to disk, things are going to start slowing down. Once this issue is isolated and rememedied you shouldn't need to restart the OS continually. But for a test, it's best to keep things simple.
Ironically, yesterday while looking at these settings, I found a bug in the app where if one sets the CPUs reserved pref, then changes the RAM per bkgnd cpu, the memory setting does not take effect until the app is restarted. That bug may have affected your testing. While you are trying to come up with the best setting, please don't set the Reserve CPUs for other applications. Leave that setting at 0. By increasing the allocation of RAM per bkgnd cpu you will effectively be limiting the number of spawned processes. Also, for the test, don't have other applications running in the background. The less moving parts, the easier it is to see and isolate what's happening.
As a footnote for testing, MP is most efficient and offers the best bang for the buck when the task is speeding up the rendering of complex compositions by distributing the frame rendering over mulitple processes. If the task at hand is simple transcoding, MP may only offer modest gains because the overhead of marshalling the multiple processes exceeds the performance gains. Todd has posted some excellent guidelines on this topic.