Does Blender support dualcore CPU’s ?
Yes, it does. Just click on button Threads in Render Buttons
Utilized during rendering output only, blender internal renderer only (not sure how/if yafray’s multithreading is set up…)
I’d recommend reading this thread, and if you’re still on 2.37a, then use AN][ARES’ Intel/AMD optimized compile. Really helps lower render times on Windows PCs.
Additionally, you can bump up blender’s “priority” in Windows under the Task Mgr (right-click on the blender.exe process and set “Set Priority” to what you want) to gain further performance at the expense of being able to use other programs effectively during rendering.
Renders are one of the few examples of a truly “CPU-bound” workload … one that will use 100% of the CPU resource available, do so for an extended period, and perform in a manner that is strictly limited by its ability to gain access to the CPU.
(The opposite of a “CPU bound” application is an “I/O bound” one, whose progress is primarily determined by its ability to perform I/O. It does very little with the CPU, when it gets it, than to start another I/O operation, or to go sleep. Nearly every program you normally run has this characteristic, including Blender itself when it’s not rendering.)
The rule-of-thumb for urgent I/O bound workloads is to give them normal or minus-one-step priority (that is to say, “slightly inferior”) … the user interface is usually considered to be the one that should respond quickest, as well as being the most extremely “asleep most of the time” application on the system. (And yes, I said “inferior!”)
Paradoxically, one of the best ways to improve the performance of a CPU-bound workload is not to increase the priority, but to lower it about two or three steps.
Such an application ought to “really be” a non-interactive process. It should not have interactive and CPU-intensive characteristics within the same thread. For example, run a command-line invocation of Blender, just to do a render, with no windows showing. You should also be certain that there is sufficient system-memory that its entire “working set” memory-requirements can be satisfied without paging, for prolonged periods of time. Send one, clear signal to the scheduler: “mixed” characteristics are very hard to accomodate. A CPU-intensive process that is frequently interrupted by paging (done on its own behalf) becomes “mixed.” Chips are cheap now, so that problem’s avoidable.
Here’s the logic: We know that the scheduler will always strive to keep the CPU busy. If there is something for it to do, the scheduler will have it do it. So if we “park” a Blender process with lots of work to do, it will be constantly busy without further ado. We give the process an inferior priority as a clear indication to the scheduler that we don’t care if and when the process gets pre-empted: it’ll burn up full time-slices whenever it can get them, but it won’t be severely impacted if some of its time silces are less than full. When you click that mouse, or that disk drive finishes an operation, we want the system to immediately pre-empt Blender, service the interrupt, and resume working on Blender when next convenient.
What we would prefer not to happen is for that process to be running at normal priority, getting full time-slices (much longer than the time-slices that other “interactive” workload are getting), and thereby slowing things down. The scheduler itself will adjust priorities somewhat based on the observed characteristics of the processes, but by adjusting the priorities ourselves we make our intentions very clear.
So what we’ll observe is that the background render-process is probably getting 95% or better of the CPU resource, pretty much all of the time, yet the system will remain quite responsive.
On my (Linux) system, when I’m doing re-renders of a project (for which I use Makefiles), I simply enter: nice make &. The process is launched as a background job, and I do other things until the job is finished.
The priority adjustments should be small ones, not drastic ones, and I can never think of a time … not in common practice anyway … where the priority of an application should be made premium … above that of the user-interface.