You have to use the advanced (more tricky) package at Folding; the standard client only runs on one thread. Also, some numbers of threads don't work; so you may be able to use 4 but not 5, for example.
Aqua (now closed) use to use Multi-threading, but it had issues, not least the fact that the number of threads in use varied, usually dropping towards the end of a run, and you could not use these free threads for other Boinc projects.

The reason you might want to run multi-threaded is task duration. It's fine having 8, 16 or even 24 separate tasks running on different threads/cores, so long as they each complete quickly (a few hours). The longer the task takes the greater the likelihood of problems. So if a task can complete using all cores/threads in say 12h, on a 24 thread dual skt high end server, then one task would take 288h (12days) if run on one thread. On a standard desktop that could take >400h. Some people would just give up if a task runs say for 40h, or 100, or 150h... and abort the task, retarding the project (resends); sometimes the science requires a fast turn around of a complete batch of tasks, to build the next batch, and therefore has to run several batches (or internal projects) concurrently, or the project is up and down repeatedly.

Not many applications are designed to cater for multi-threading. It takes a lot of time to refine applications, and there is a learning curve. My understanding of recent Intel processors, and available building tools, is that to some extent this is becoming easier, but I'm not sure that its catching up with ever-increasing core/thread counts. Perhaps the drive towards cloud computing will improve the situation.

In the past I tested a lot the Intel 980X a six core, with (12 threads)or without (6 threads) hyperthreading.
There are differences per project but one can say that with hyperthreading on you get about 15% more work done. (I do not know how things are in the AMD world)
It is not important the time one WU takes at a given moment. What is important is statistically on a a longer period, (ex. ten days or more) how much output you produce. After all we are here to crunch for a long time.
Conclusion, keep hyperthreading on.
I will have in the coming days a Intel X3960 running, and will check how it does behave with hyperthreading on and off.

You are right skgiven. I misplaced the X

The motherboard is an Asus Sabertooth and it is indeed a PCIE 3.0.

With ThreadMasterGui [for WXP/W2K and up] as replacement for the BOINC setting you get an all-round smoother experience. You only need to change the ceiling factor that default applies to all lowest priority" BOINC science apps, and it will run your tasks smoothé too, not the hacksaw profile you get with the BOINC throttle... running X seconds, pausing Y seconds... which is the reason why BOINC is noticed in the first place by some sensitive programs.

Apologies for that interjection.

Calling the beast by it's name as what the title is asking for, SMP processing on BOINC I've only experienced when testing with the MW project. Ruthlessly, when it had it's turn, you get kind of the Hi priority processing experience. All running tasks are put in stasis, and MW grabs all BOINC allowed cores [and with running CEP2 only and LAIM on, a serious memory hogging situation]. The odd view then observed in BOINCTasks is how you see the CPU time column run 4 times as fast as the elapsed column, so an task of 1 hour counts as 4 hours on a quad. Similar to GPU, it requires very special coding, which most types of science tasks are not suited for as they are serial processing oriented, or so they seem to me.

--//--