plan_class without <max_threads> uses always only 1 thread

[UweBeckert]

This plan_class:

     <plan_class>
         <name>                  16t          </name>
         <min_ncpus>             16           </min_ncpus>
         <nthreads_cmdline/>
     </plan_class>

Uses only 1 thread. It sends to the client

     <platform>windows_x86_64</platform>
     <plan_class>16t</plan_class>
     <avg_ncpus>1.000000</avg_ncpus>
     <max_ncpus>1.000000</max_ncpus>
     <flops>3718491507.830066</flops>
     <cmdline> --nthreads 1</cmdline>

But if I extend the plan_class with

<max_threads>           512          </max_threads>

It sends 16 threads to the client.

max_threads should be considered as very big or at least min_ncpus if missing. But it shouldn't be 1 as default.

[RichardHaselgrove]

If <max_threads> is present, BOINC will always set --nthreads to the maximum number of threads available to the BOINC client at the time the task is requested and allocated - so an 8-core machine with BOINC restricted with <max_ncpus_pct> 75 will receive tasks with --nthreads 6

So there should be no downside to setting a high default value as suggested: it will only come into play with extreme workstations or possibly Xeon Phi coprocessors.

More practically, there is probably an upper limit to the benefits of multithreading for each application: a tipping point where the overheads of synchronisation are greater than the benefits of an extra thread. Administrators deploying MT apps might choose to set lower <max_threads> values like 32 or 64, depending on the performance of their applications, but that's a matter for individual projects, not BOINC.