#325 closed Defect (wontfix)
Force project applications to single core (Windows)
Reported by: | wto605 | Owned by: | davea |
---|---|---|---|
Priority: | Minor | Milestone: | Undetermined |
Component: | Client - Daemon | Version: | |
Keywords: | affinity | Cc: |
Description
BOINC preferences allow users to set a maximum number of cores to use at one time... however under windows a thread is distributed between all the cores (but is still limited to %50 of of the processing power). For example, on my Quad-core machine I run three threads... but instead of three cores being at 100 percent and 1 being at 10 or so (for whatever other system tasks may be running) all four cores are at 75% or so. This is very inefficient because not only are you increasing the amount of cache used (because you're populating all four caches with the information of all three projects as opposed to one different project on three of the four cores). But it will also slow down the work-unit because of timing (one core must wait for the others to finish). While project mangers COULD release their applications with flags limiting each thread to one processor/core they don't... however Windows lets this option be set on a per instance basis (in the task manger), or every time the executable is started using imagecfg.exe (available in tool-kits, or google it). Seeing as imagecfg works on a command-line basis it might even be possible to use it as-is.
Change History (3)
comment:1 Changed 17 years ago by
Component: | Client - Build → Client - Daemon |
---|---|
Owner: | changed from romw to davea |
Priority: | Major → Minor |
comment:2 Changed 17 years ago by
Here are some articles that mention the benefits of Bound Multiprocessing over Symmetric Multiprocessing...
Keep in mind that imagecfg.exe can configure an exe to only operate on a single core... it doesn't have to be bound to a specific core. (this allows for multiple threads of the same exe on different cores, and for the process to move in another comes in that is monopolizing a specific core). Also... BOINC is not affected by the need for shared resources that can cause problems with BMP because each thread is working on a different work unit. HOWEVER, no an SMP the "thrashing" is a problem because the work units are distributed.
http://www.carnica-technology.com/OvwRTOS/MCEdit/MCEdit.html
http://www.rtcmagazine.com/home/article.php?id=100403&pg=3
"Compared to full, floating SMP operation, this approach offers several advantages. It eliminates the cache thrashing that can reduce performance in an SMP system by allowing applications that share the same data set to run exclusively on the same core. It also offers simpler application debugging than SMP since all execution threads within an application run on a single core. And it helps legacy applications written for uniprocessor environments to run correctly, again by letting them run on a single core."
There are many many many other articles which discuss only SMP and AMP and then mention in passing that BMP is better but requires a supporting operating system (which windows does).
Another way to show how this makes a difference is to compare the affect of disabling Hyper Threading on a P4 while running a "static" thread (like BOINC). It will perform much faster, and thats even without the cache issues (because its the same processor, and thus the same cache).
I have seen a discussion on the mailing lists (long ago) questioning if the performance gain would be really noticeable or not. I don't remember the final outcome of the discussion though. I may search for it...