I am experimenting with various setting for the percentages of the CPUs vs. the percentages of the time I allow BOINC to use.

So far, I am sure of one thing and quite unsure of another.

SURE OF: it is better for cooling purposes, fan speed and noise to use less of more cores, than more of fever cores. I.E.: 50% or 8 cores running 100% of the time will generate more heat, will spin the fan faster (and louder) than 100% of 8 cores running 50% of the time.

UNSURE OF: is one of these approaches better for computational performance over the other?

I appreciate your thoughts.

I think the best way would be to test both methods with the application involved. If you let the application run for many days and monitor how much tasks take time to complete... then you started to see which method was better for computational performance (for that particular application). My quess is that running less threads 100% of the time is more efficient.

It is what I am doing, but the change in efficiency may be obscured by the fluctuation of the efficiency of different work units, I am afraid. I am hoping somebody went this route in a more controlled and scientific manner, and can share their experience.

Yes, it is Hyperthreaded. And you have a valid point.

Perhaps I should have used a different example (I am experimenting with various settings)

1. 25% of 8 cores (2 cores) running 80% of the time, vs
2. 100% of 8 cores (8 cores) running 20% of the time

I use a simple math to calculate an index to judge what combination should provide a better performance:

1. 2 x 80% = 160%
2. 8 x 20% = 160%

So, in this example, one would expect even performance in between the two. The difference is in the temps and fan speeds. Combination #2 is much more cooler and fans are much more quieter (and I have a way to easily see graphs for the temps and fans speed via iStat menus; I am on Macs). If, in fact, performance is equal (and this is what I am beginning to question), one should opt for spreading smaller loads over as many cores as one has available. However, I am beginning to notice that it also may be yielding slower (sometimes substantially) performance.

If you're using linux or unix you can use the taskset command to possibly limit the physical CPUs.

I briefly used to have a HT dual core (i5 4200u) but when I had it, I wasn't aware of taskset, and I also never looked into out how the core numbering was arranged. So, I'm not 100% sure, but I'll take a hopefully good guess.

If it's anything like the AMD SMT arrangment, the (logical) cores 0 and 1 correspond to the first module, cores 2 and 3 correspond to the second module, cores 4 and 5 correspond to the third module, etc etc.

If this is the case (i.e. module is analogous to a HT physical core), then you could try tasksetting all boinc tasks to restrict them to a range of logical cores (and corresponding physical cores).

HT actually works really well and wonders for efficiency, if the code depends very much on the RAM like many numerical solutions do, since the data is often too large to fit in the CPU caches.

Anyways, the goal here is to fully load a physical core with two threads so that HT is employed, and that you either have a fully loaded physical core, or a fully idle physical core.

Your 80/20 example is a little hard, but I'm going to try a 50/50 example here.

We'll compare using half the cores (2 physical cores or analogously, "modules") all the time to using all 8 (logical) cores half the time.

For the former case, set 100% compute time and 4 threads in BOINC manager, and then follow this with four tasksets under a unix command line:

taskset -p -c 4-7 pid1
taskset -p -c 4-7 pid2
taskset -p -c 4-7 pid3
taskset -p -c 4-7 pid4

where pid1, pid2, pid3, and pid4 are the boinc threads.

And the latter case is easy, you just set 8 threads running at 50% in boinc manager.

I have a sort of script that will automatically taskset boinc tasks (or any threads with nice value of 19 for that matter) to a range of specified logical cores.

You have to modify the code to suit what you want it to do:

http://ee.freeshell.org/Slow/slowNice3.c
http://ee.freeshell.org/Slow/

There are also some scripts in there that will adjust the CPU clock. They won't be relevant and you can modify them to do nothing if all you want to do is run this performance test.

If your goal is to reduce heat or performance per watt then you should really look into running your CPU at reduced speeds. Consumer CPUs are set up to be clocked for performance, not performance per watt. You manually clock them somewhat lower if efficiency and low fan noise is what you want.

Ritchie wrote

I think the best way would be to test both methods with the application involved.

I think this is definitely a good way to go. Expect to see different results based on different applications. Try to work with one application (and even one task) running to get a base line.

I recently stumbled across Intel's PCM while tuning over at Einsten@home (see here) which gives really detailed information to see what is happening.

Applications are different, each affected in different ways by many things, such as memory bandwidth, memory speed, %cache hit rates, throttling and boosting to name a few. This is hidden behind the %CPU figure.

You can get a much better view and even detailed power use using the tools.

hth

"Is your 8 core Hyperthreaded? If so, limiting to 4 cores"

Quad core 8-thread CPU, you mean (8 logical cores, 4 actual cores); or so I thought.

Also, I meant to say CMT not SMT (SMT won't be there for another half year).

You could also do a 75:25 test by loading one physical core 100% with two threads. Then compare that with a fully loaded CPU (8 threads) that are active 25% of the time.