{"id":1795,"date":"2009-10-21T22:07:18","date_gmt":"2009-10-21T21:07:18","guid":{"rendered":"http:\/\/www.walkingrandomly.com\/?p=1795"},"modified":"2013-05-17T10:13:09","modified_gmt":"2013-05-17T09:13:09","slug":"parallel-matlab-with-openmp-mex-files","status":"publish","type":"post","link":"https:\/\/walkingrandomly.com\/?p=1795","title":{"rendered":"Parallel MATLAB with openmp mex files"},"content":{"rendered":"

Slowly but surely more and more MATLAB functions are becoming able to take advantage of multi-core processors.\u00a0 For example, in MATLAB 2009b, functions such as sort<\/strong>, bsxfun<\/strong>, filter<\/strong> and erf<\/strong> (among others) gained the ability to spread the calculational load across several processor cores.\u00a0 This is good news because if your code uses these functions, and if you have a multi-core processor, then you will get faster execution times without having to modify your program.\u00a0\u00a0 This kind of parallelism is called implicit parallelism<\/a> because it doesn’t require any special commands in order to take advantage of multiple cores – MATLAB just does it automagically.\u00a0 Faster code for free!<\/p>\n

For many people though, this isn’t enough and they find themselves needing to use explicit parallelism<\/a> where it becomes the programmer’s responsibility to tell MATLAB exactly how to spread the work between the multiple processing cores available.\u00a0 The standard way of doing this in MATLAB is to use the Parallel Computing Toolbox<\/a> but, unlike packages such as Mathematica<\/a> and Maple<\/a>, this functionality is going to cost you extra.<\/p>\n

There is another way though…<\/p>\n

I’ve recently been working with David Szotten<\/a>, a postgraduate student at Manchester University, on writing parallel mex files for MATLAB using openmp<\/a> and C<\/a>.\u00a0 Granted, it’s not as easy as using the Parallel Computing Toolbox but it does work and the results can be blisteringly fast since we are working in C.\u00a0 It’s also not quite as difficult as we originally thought it might be.<\/p>\n

There is one golden rule you need to observe:<\/p>\n

Never, ever call any of the mex api functions inside the portion of your code that you are trying to parallelise using openmp.\u00a0 Don’t try to interact with MATLAB at all during the parallel portion of your code.<\/strong><\/p>\n

The reason for the golden rule is because, at the time of writing at least (MATLAB 2009b), all mex api functions are not thread-safe<\/a> and that includes the printf<\/strong> function since printf <\/strong>is defined to be mexPrintf<\/strong> in the mex.h<\/strong> header file.\u00a0 Stick to the golden rule and you’ll be fine.\u00a0 Move away from the golden rule,however, and you’ll find dragons<\/a>.\u00a0 Trust me on this!<\/p>\n

Let’s start with an example and find the sum of foo(x) where foo is a moderately complicated function and x is a large number of values.\u00a0 We have implemented such an example in the mex function mex_sum_openmp.<\/p>\n

I assume you are running MATLAB 2009b on 32bit Ubuntu Linux version 9.04 – just like me.\u00a0 If your setup differs from this then you may need to modify the following instructions accordingly.<\/p>\n