Just set the BOINC client to run 50% of the CPUs and it will have almost the same effect.

In general, you MUST turn HT OFF for LLR tasks. In my experiments, all what it does it either heating up CPU like hell without any change in overall performance on small projects (got 95C at PPSE, and I thought I had a good tower fan! And speed of each core was exactly two times slower then without HT). Either it slowing things down because more tasks are fighting for memory access, which becomes bottleneck in big workunits like SOB.

If you cannot turn it off, limit number of tasks to 3 or 4.

With typical "stock" DDR3-1600 CL11 (and slower memory), running 3 or 4 cores on big projects like SOB usually gives same (or very close to) overall performance, because everybody is waiting for memory access. Must often 4 tasks are still a bit faster (although almost unnoticeable), but in some setups (overclocked CPU with big cache and slow memory) running 4 tasks degrades performance.

In my opinion, most "credit-effective" way is to run 3 "BIG LLR" + 1 Sieve task. Unfortunately, as far as I understood it's not possible to do this completely automatically in Boinc - you have to change projects preferences every time and abort unneeded tasks.

What is best for your computer? It's not so difficult to do a benchmark from command line without waiting for SOB workunit to complete. Before benchmarking, be sure that Boinc is stopped and you're not running any heavy tasks like web browser with flash and animation.

I'll assume you're using Windows-32, for Windows-64 and Linux everything will be same with minor changes in file names.

You'll need two files from Boinc projects/www.primegrid.com directory:

1. llr.ini.6.07
2. primegrid_cllr_3.8.13_windows_intelx86.exe

- Copy them to empty temporary directory, e.g. "test1"
- Rename "llr.ini.6.07" as "llr.ini"
- Optionally, to avoid long typing, rename primegrid_cllr_3.8.13_windows_intelx86.exe to llr.exe
- To avoid long typing again, create batch file, e.g. "test.cmd" with following contents. Note the quotes!

One more note about test procedure for those who want to repeat. I found that LLR.EXE, when used in "-q" -option mode, will delete LLR.INI file after Ctrl-C, making use and editing of this file hard for tweaking. So,

1. Do not copy LLR.INI at all, all you'll need is LLR executable.
2. The batch file to run test must be following:

Another thing you can tweak is CPU affinity. I see about 10% reduction in WU run time by setting CPU affinity for each WU to a distinct physical core. YMMV.

<tl;dr>You WILL want to select certain logical CPUs to avoid hyperthreading. Linux and Windows use different mapping schemes between physical cores and logical CPUs.</tl;dr>

In Linux, the command "lstopo" (for "list topology") draws a diagram showing the relationship between logical CPUs, physical cores, and layers of cache. What I've always seen is that one side every physical core is mapped to a sequentially numbered range of logical CPUs. Then to avoid hyperthreading WUs in Linux, use half of all the logical CPUs in sequential numerical order (it doesn't matter where you start, you'll wrap around and uniquely hit all the physical cores).

In Windows 7 and 8, based on experimental performance observations, each even-odd pair of logical CPU numbers corresponds to a physical core. To avoid hyperthreading WUs in Windows, use only the even numbered (or only the odd numbered) logical CPUs.

You can't set CPU affinity through configuration with stock versions of BOINC, but you can set it manually on running WUs. This only lasts as long as your patience. Or set the CPU affinity of the running BOINC client to the subset of logical CPUs you want WUs to use, and hope that the O/S is proficient at dispatching simultaneously running WUs onto distinct physical cores.

It's very easy with PRPNet to guarantee a distinct physical core is always used by each instance of prpclient, but this forum's scope isn't wide enough to contain it.