You can set kernelopts(numcpus) once per kernel session/restart. Usually that has to be done at the very beginning (before anything else does).
There is kernel code which examines the processor specifications and tries to determine the appropriate value for kernelopts(numcpus) automatically, which is the value you see when you first query it.
For some very new CPU chipsets (eg. intel skylake, etc) the Maple facility which examines the processor specs may not be fully up to date. And so -- for example -- it may under-report and not initally set kernelopts(numcpus) to the number of physical cores instead of the number of logical cores (which could include hyperthreading). Ot it may under-report by not properly recognizing that hyperthreading is enabled.
On at least one of my recent Linux boxes the initial value of kernelopts(numcpus) is set to the number of physical cores, and some Threads:-Task examples speed up for me if I manually set it to twice that (thus accounting for all logical cores under hyperthreading) at the start of the session.
When hyperthreading was first introduced, years ago, the memory buses and cache access was not done well, and highly intensive and parallelized code would orten do worse if the additional virual cores also contended for these resources. So on such very old machines Maple sets kernelopts(numcpus) initially to just the number of physical cores. But nowadays the situation has much improved, and quite often there are still measurable gains to be had by allowing the virtual cores to participate even in previously problematic examples. The current fly in the ointment is that the facility may need updating for spanking new machines -- or manual setting of kernelopts(numcpus) at session start.
On my 64bit Linux Maple 2019.0 I can run this command to see details of what Maple's kernel thinks my machine can support.
That runs the `processor` binary from the kernelopts(bindir) subdirectory.
I am not promising that altering kernelopts(numcpus) will improve your particular example. It might even make performance worse. I just thought that I'd tack on these details as commentary to your prior reply, since you wrote that kernelopts(numcpus) could not be changed.
I find that the benefits of Threads:-Task are generally platform dependent.
The use of name n in the example seems unnecessarily confusing, since it is scoped within doTask, a parameter of setupTask, and assigned at the top-level.