Thanks for the follow on questions Bruno!
Preferred Number of Workers in a Pool
For parpool('processes') the number of workers you will get will be the minimum of: the parallel preference; or the NumWorkers field in the 'processes' cluster profile. In your case I would expect it to open a parallel pool of 12 workers [min(12,14)].
The default value of 12 in the Parallel Preferences will only apply to non-thread pools. This stems from Thread pools historically following the value of maxNumCompThreads() thus this preference never applied. From R2022b you can now specify a size of thread pool and parpool('threads') defers to the same default number of workers as the 'processes' profile i.e. the number of physical cores detected.
maxNumCompThreads behaviour
The value returned by maxNumCompThreads('automatic') is counting just your performance cores (6) rather than performance + efficiency (14). This is because maxNumCompThreads primarily focuses on the implicit multi-threading of mathematical operations which should take place on the Performance cores of your processor. Adding additional threads would either cause resource contention on the Performance cores or cause them to run on some of the efficiency cores which could incur some slowdown on the overall operation.
Standalone Deployed Application
When you deploy onto another machine using the 'processes' or 'local' profile it by default will use a number of cores = to the number of physical cores detected on the machine. I would recommend finding out how many workers the cluster profile thinks it has by instantiating a cluster object then querying the number of workers:
c = parcluster('processes');
numcores = c.NumWorkers
This would be safer than using an undocumented feature command.
