Matlab is a widely used tool in research, thanks in part to the ability to quickly develop code to test solutions without (necessarily) needing to be a expert coder, and a wealth of toolboxes and functions from image and signal processing, to bioinformatics, econometrics and robotics. However, Matlab can be quite resource hungry and if you find your PC struggling or yourself waiting for Matlab to finish processing before doing other things on your computer, or even if you just want to get your Matlab tasks running more quickly and efficiently, then you might want to think about using Matlab on Viper. Why?
It’s not (rocket) science…
Compared to the science you do, migrating your Matlab task from the desktop to Viper isn’t that complicated. While Viper does run Linux you don’t have to be an expert to use Viper, starting out you can get by knowing just a few commands (a little more of that another day). It is possible to benefit from Viper’s resources after just a short introduction to Linux and how to work on Viper from the Viper support team. Matlab provides a familiar working environment across MacOS, Windows and Linux, and the University’s ‘Total Academic Headcount’ license means all the toolboxes are available on Viper as they are on the desktop.
The migration process may typical involve starting with working interactively using the Matlab GUI right through to submitting tasks to the scheduler to run automatically when resource becomes available. Generally speaking, the most likely initial changes required to Matlab .m scripts will be updating path references to files being loaded, depending on the platform.
Lots and lots to do…
The standard Viper systems have 128GB of RAM, while high memory systems are available with 1TB of RAM, meaning you shouldn’t see this sort of thing anymore:
But it isn’t just for the big resource hungry tasks. If you have hundreds or thousands of tasks, even if they have modest resource requirements, with Viper’s multicore systems it is possible to run large numbers of Matlab jobs concurrently. With queues (partitions) that run for up to 5 days, you can leave those long running tasks processing and wait for the results to come in.
Perhaps most noticeably though, without any modification, tasks moving from a standard PC to Viper could see significant speedups. A number of Matlab functions automatically execute on multiple computational threads, allowing them to run faster on multicore-enabled machines such as Viper’s 28 core systems. This includes many functions in the Image Processing Toolbox.
The following graph shows the run times of some of the functions that benefit from built-in multi-threaded computation. For these synthetic benchmarks, the functions were run across varying sized random matrices. The graph shows comparisons between Matlab running across 2 cores on my relatively new i5 laptop, running on a single core on a Viper node (with the singlecompthread option) and across all 28 cores on one of Viper’s 180 compute nodes.
While running Matlab on Viper with the singlecompthread does limit Matlab to using just 1 core and slows things down a little, it does mean you can run 28 independent Matlab sessions on a single node!
While these are synthetic examples, what they show is the potential performance improvements may be seen without any significant updates to your Matlab code. For example, when running a sort on a 8192×8192 matrix, running multi-threaded across 2 cores of my i5 laptop took 11 seconds, on a single Viper core the task took 18 seconds, and finally the same task took just under 2 seconds on Viper with 28 cores.
If you want to take it to the next level you can move from a single instance of Matlab to using the Parallel Computing Toolbox and utilise a number of Matlab workers (separate Matlab engines) for true parallel processing. Using the Parallel Computing Toolbox does require some changes to the code, for example using parfor loops rather than standard for loops.
The following example code calculates the spectral radius of a matrix. Firstly a normal for loop version (my nonpareig function below) on my 2 core laptop took 30 seconds to complete. Using the parallel computing toolbox to open 2 workers on the same laptop and converting to a parfor loop (my pareig function) the run time was reduced to 20 seconds.
Using this same parfor example code and opening 28 workers on a standard Viper compute node reduces the run time down to just over 2 seconds.
The parallel computing toolbox also makes it possible to make use of GPU resources:
More playing with Matlab on Viper – GPU Mandelbrot Set! (ramping up grid size to 5000) 30 secs on CPU > 0.15 on GPU pic.twitter.com/l4OkCHo3tZ
— Hull Uni HPC-VIPER (@HULL_HPC_VIPER) 9 August 2016
If you are interested in using Matlab on Viper or would like more information on what can be done on Viper, please contact us as firstname.lastname@example.org
The Viper wiki page on Matlab – http://hpc.mediawiki.hull.ac.uk/Applications/Matlab
Run MATLAB on multicore and multiprocessor machines – https://uk.mathworks.com/discovery/matlab-multicore.html
Matlab functions that benefit from multithreaded computation – https://uk.mathworks.com/matlabcentral/answers/95958-which-matlab-functions-benefit-from-multithreaded-computation
Matlab parallel computing fundamentals – https://uk.mathworks.com/help/distcomp/parallel-computing-fundamentals.html
“There is ONE reason matlab is so good and so widely used” – https://stackoverflow.com/a/8347327
Matlab: Decide when to use parfor – https://uk.mathworks.com/help/distcomp/decide-when-to-use-parfor.html
Matlab: Illustrating three approaches to GPU computing – https://uk.mathworks.com/help/distcomp/examples/illustrating-three-approaches-to-gpu-computing-the-mandelbrot-set.html