detailed documentation regarding parallel and multi-thread computation with MCT

Any response? Is this forum still alive?

I just saw your message - spam filter hides the emails notifications from the forum.

The mp.NumberOfThreads function has documentation:

        % mp.NumberOfThreads Sets maximum number of threads to use in computations enabled with multi-core parallelism.
        %
        %   N = 0 (default):
        %   Sets number of threads = number of real hardware cores in the system.
        %   Each thread is pinned to execute on particular hardware core for best
        %   performance. This is optimal strategy for most of the users, who runs
        %   one instance of toolbox at a time.
        %   
        %   N ~= 0:
        %   Pushes toolbox to use exactly N cores, taking into account
        %   hyper-threaded cores as well. No thread affinity is applied.
        %   
        %   This is useful if you run several toolbox instances (e.g. with parfor). 
        %   In this case compute number of threads as:
        %   
        %      N = total_number_of_cores / number_of_matlab_workers
        %   
        %   Returns current setting if called without arguments.
        % 

Example of use and more information is in mpstartup.m:

    % Set up maximum number of threads to use in computations enabled with multi-core parallelism:
    %
    % mp.NumberOfThreads(N) with:
    %
    % N = maxNumCompThreads [default]
    % 
    %    Use MATLAB's default setting. This is probably optimal strategy for most of the users,
    %    especially if user already controls number of computational threads by built-in MATLAB's commands.
    %
    %    Usually MATLAB assigns number of computational threads equal to number
    %    of physical cores of CPU. Also each thread is binned to one physical
    %    core using thread affinity control. This is optimal for most heavy
    %    mathematical computations.
    %
    %    Multi-threading in toolbox/MATLAB is based on OpenMP framework. 
    %    OpenMP allows flexible control on number of threads, affinity, 
    %    timings, thread scheduling, etc. using OS environment variables.
    %    See OpenMP specifications for details: https://www.openmp.org/specifications/
    %
    %    On Windows we rely on Intel OpenMP which allows even more detailed
    %    tuning with (KMP_) environment variables: https://software.intel.com/en-us/node/522775
    %
    %    For example, OpenMP configuration for 16-cores/32-threads Intel Core i9 7960X 
    %    might look like (for Windows):
    %
    %       OMP_NUM_THREADS = 16
    %       KMP_AFFINITY = explicit,proclist=[0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30]
    %    
    %    Here we restrict OpenMP to use only 16 computational threads and attach every thread 
    %    to distinct physical CPU core ( = to use logical cores with even IDs).  
    % 
    % N = 0:
    %    Use all available CPU cores in the system (including logical cores).
    %    Pushes CPU utilization to the limit. This mode is beneficial for computations 
    %    which is massively parallel, e.g. for matrix multiplication.
    %    In other cases speed can actually go down. Please test this mode for your
    %    particular code to see if it provides any speed-up.
    % 
    %    Use with caution since this mode might slow down all other applications running on the computer.
    %    Suitable for users who run one instance of toolbox at a time (no parfor).
    % 
    % N ~= 0:
    %    Toolbox will use exactly N cores (including logical cores). No thread affinity is applied.
    %
    %    This is useful if you run several toolbox instances (e.g. with
    %    parfor) and want to balance the load among all workers.
    %
    %    In this case compute number of threads as:
    %
    %        N = total_number_of_cores / number_of_matlab_workers
    %
    % NOTE. The 'maxNumCompThreads' was declared deprecated starting from R2011 up to R2014. 
    %       But status of this command was restored later and now it is valid command.
    %

OK... So, the primary source of mp.??? functions documentation is available only via: help mp.???

As is already mentioned in your web documentation:

"Information on toolbox-specific routines can be obtained by the MATLAB help command: help mp.Digits, help mp.GaussLegendre, etc.)"

I think, that all these informations should be available at actual state on your WEB as a part of official documentation. From my point of view is help based documentation very brief, but still sufficient. Problem is, when MCT user trying to show MCT based code to anybody who has not already installed MCT. In this case is web based documentation only available source which is nearly useless, because does not cover this important part of MCT functionality.

Any specific user guides, function reference or other documentation regarding MATLAB Parallel Toolbox (parfor, parpool specs like "threads" vs 'processes', etc.) and MCT licensing requirements/options? Are there some limitations, recommended use case scenarios, etc?  

If non default precision is used - then mp.Digits() needs to be called inside parfor or other parallel code - to make sure each worker instance runs with the same precision.

Very brief answer :)

What about parpool initialization. Because of the fact, that the main part of MCT is implemented as MEX file, there is probably impossible to use Threads based parpool, becase of MATLAB limitation to run mex file in parallel only via Processes based parpool. Am I right?

Any comprehensive tutorial how to run properly parallel computing with Parallel Toolbox functionality together with MCT would very helpful! 

You are right, but we have ~1000 functions in toolbox and each has a lot of variations in input argument, outputs, etc. which are covered by MATLAB's documentation already (say Y=fft(X), or s=svd(A) are the same). It would require significant efforts to maintain separate web-pages with documentation and mostly duplicate the MATLAB's one. I am not sure if it would be a wise thing to do (?).

When showing code to others maybe we can just say - "same code as MATLAB's but running in extended precision"?

This answer: "same code as MATLAB's but running in extended precision" is not always absolute true. There are often some minor, but very important differences. But OK ... I understand your point :) 

The thing is that MathWorks doesn't really share information with MEX developers and they change how parallel toolbox works from version to version. For example, in March we stumbled on unknown issue - if code uses several parfor loops (and toolbox inside them) - the second loop cannot run just because MATLAB engine resets the path variable for the workers in second parfor loop. And toolbox cannot be found or cannot even read its files, since it is not in the path anymore. 

There are a lot of quirks like this, depending on MATLAB version, etc. Usually we receive reports from users about new issues.

The toolbox's MEX is just an ordinarily DLL/SO and MATLAB developers can use it in any way they desire, keeping the hard issues in their wrappers for MEX. Each system thread or process can use MEX, but I don't know how they implemented it. 

I would suggest just trying things - e.g. at least checking what precision is used in each parallel worker.