Let me see if I have this right
- Method #1 finishes runMe in ~5 minutes, using local scheduler
PBS jobscript
#!/bin/sh
#PBS -l nodes=1:ppn=16
module load matlab
matlab -batch runMe
runMe.m
function runMe
parpool("local",16);
parfor idx = 1:160
...
end
- Method #2 finishes runMe in ~5 minutes, using local scheduler
% # Run MATLAB on the compute node
% qsub -I -l nodes=1:ppn=16
% module load matlab
% matlab
runMe
- Method #3, finishes runMe in 20-30 minutes, using PBS scheduler. singleNodeJob is configured with 16 workers with -l nodes=1:ppn=16
% # Run MATLAB on the head node. Preferred choice because you have a
% # limited number of MATLAB and Toolbox licenses, and would like to use
% # MATLAB Parallel Server licenses instead.
% module load matlab
% matlab
Submit job
pbs = parcluster('singleNodeJob');
job = pbs.batch(@runMe,0,{},'Pool',15);
runMe.m
function runMe
% parpool("local",16);
parfor idx = 1:160
% Note, we're only running with 15 workers, not 16
...
end
A couple of thoughts:
- How are you measuring 5, 20, 30 minutes etc.?
- When using the local scheduler, you're using the resources already available to you in the PBS job. Therefore, starting the parallel pool will happen quicker. If you're running a PBS pool, you're submitting an "inner" job. Who know how busy the queue is. It might take 10-15 minutes for this inner job to start. This could be the crux of the matter.
- When you set NumThreads, for example
pbs.NumThreads = 8;
This doesn't increase the core count of your PBS jobs. Therefore, you'll have 16 workers running, each with access to 8 comp threads, all running on the same 16 cores on the single node. Conversely, if you set NumThreads to 1, then all the non-parallel code will only get a single comp thread.
