# Difference between revisions of "SW:Matlab"

(→matlabsubmit: running matlab codes on the compute nodes) |
(→Example 2: utilizing additional Matlab workers) |
||

Line 135: | Line 135: | ||

− | === Example 2: | + | === Example 2: Utilizing Matlab workers (simple) === |

− | To utilize additional workers used by Matlab's parallel features such as ''parfor'',''spmd'', and ''distributed'' matlabsubmit provided the option to specify the number of workers. This is done using the ''-w <N>'' flag (where <N> represents the number of workers). The following example shows a simple | + | To utilize additional workers used by Matlab's parallel features such as ''parfor'',''spmd'', and ''distributed'' matlabsubmit provided the option to specify the number of workers. This is done using the ''-w <N>'' flag (where <N> represents the number of workers). The following example shows a simple case of using additional workers; in this case 8 workers |

<pre> | <pre> | ||

Line 171: | Line 171: | ||

</pre> | </pre> | ||

+ | |||

+ | In this example, matlabsubmit will first execute matlab code to create a ''parpool'' with 8 workers (using the local profile). As can be seen in the output, matlabsubmit requests 9 cores in this case; 1 core for the client and 8 cores for the workers. The only exception is when the user requests 20 workers. In that case matlabsubmit will request 20 cores. | ||

===Writing your own batch file=== | ===Writing your own batch file=== |

## Revision as of 11:58, 1 August 2016

## Contents

## Starting Matlab

To start matlab you need to load the Matlab module first. You can do this using the command

-bash-4.1$ module load Matlab

This will setup the environment for the latest Matlab version. To see a list of all installed versions, use the command **module spider Matlab** command.

To start matlab, type:

-bash-4.1$ matlab

depending on your X server settings this will start the Matlab GUI or the Matlab command line interface. To force matlab to start in command line interface mode, type:

-bash-4.1$ matlab -nosplash -nodisplay

By default Matlab will enable its multi-threading capabilities and will use as many threads (cores) as available. Since our login nodes are shared we **don't** allow individual users to use more than 8 cores on a node. For that reason we added Matlab code to the system startup script to limit the number of threads. Currently we set it to 4 threads. To explicitly disable multi threading, type:

-bash-4.1$ matlab -singleCompThread

NOTE, when you run interactively (i.e. on the login nodes) there are some other limits as well. For example, CPU time is limited to 1 hour ( your matlab run will get killed by the system automatically after that). For other interactive limits, please see the appropriate pages for the system your are running on.

## matlabsubmit: running matlab codes on the compute nodes

TAMU HPRC provides a tool named **matlabsubmit** to automate the process of running Matlab simulations on the compute nodes without the need to create your own batch script. This is the recommended way of running Matlab simulations on the compute nodes since it guarantees all resources are set correctly.

To submit your Matlab script just type:

matlabsubmit myscript.m

When executing, matlabsubmit will do the following:

- generate boiler plate Matlab code to setup the matlab environment (e.g. #threads, #workers)

- generate a batch script with all resources set correctly and the command to run matlab

- submit the generated batch script to the batch scheduler and return control back to the user

In Addition, matlabsubmit will also save the complete workspace after the matlab script finishes executing.

### Example 1: basic use

The following example shows the simplest use of matlabsubmit. It will execute matlab script *test.m* using default values for batch resources and Matlab resources. matlabsubmit will also print some useful information to the screen. As can be seen in the example it will show resources requested (e.g. #threads, #workers), the actual submit command that will be used to submit the job, the actual batch scheduler JobID on ada, and the location of output generated by Matlab and the batch scheduler.

-bash-4.1$ matlabsubmit test.m =============================================== Running Matlab script with following parameters ----------------------------------------------- Script : test.m Workers : 0 Nodes : 1 Mem/proc : 2500 #threads : 8 =============================================== bsub -e MatlabSubmitLOG1/lsf.err -o MatlabSubmitLOG1/lsf.out -L /bin/bash -n 8 -R span[ptile=8] -W 02:00 -M 2500 -R rusage[mem=2500] -J test1 MatlabSubmitLOG1/submission_script Verifying job submission parameters... Verifying project account... Account to charge: 082839397478 Balance (SUs): 81535.6542 SUs to charge: 16.0000 Job <2847580> is submitted to default queue <sn_regular>. ----------------------------------------------- matlabsubmit ID : 1 matlab output file : MatlabSubmitLOG1/matlab.log LSF/matlab output file : MatlabSubmitLOG1/lsf.out LSF/matlab error file : MatlabSubmitLOG1/lsf.err -bash-4.1$

The matlab script *test.m* has to be in the current directory. Control will be returned immediately after executing the matlabsubmit command. To check the run status or kill a job use the respective the batch scheduler commands (**bjobs** and **bkill** for LSF). matlabsubmit will create a sub directory named **MatlabSubmitLOG<N>** (where **N** is the matlabsubmit ID). In this directory matlabsubmit will store all its relevant files; the generated batch script, the matlab driver, redirected output and error, and a copy of the workspace (after the job is done). A listing of this directory will show the following files:

**lsf.err**redirected error**lsf.out**redirected output (both LSF and Matlab)**matlab.log**redirected Matlab screen output**matlabsubmit_wrapper.m**matlab driver script (will call the user script)**submission_script**the generated LSF batch script**workspace.mat**a copy of the matlab workspace (after execution has finished)

### Options with matlabsubmit

The example above showed the most simple case of using matlabsubmit. No options where specified and matlabsubmit used default values wrt requested resources and such. matlabsubmit has a large number of options to set batch resources (e.g. walltime, memory) as well as matlab related options (e.g. number of threads to use, number of workers, etc). To see all the available options you can use the "**-h**" options. See below for the output of "**matlabsubmit -h**":

-bash-4.1$ matlabsubmit -h Usage: matlabsubmit [options] SCRIPTNAME This tools automates the process of running matlab codes on the compute nodes. OPTIONS: -h Shows this message -m set the amount of requested memory in MEGA bytes(e.g. -m 20000) -t sets the walltime; form hh:mm (e.g. -t 03:27) -w sets the number of ADDITIONAL workers -n sets the number of nodes to assign the workers to -g indicates script needs GPU (no value needed) -b sets the billing account to use -q sets the queue to be used -s set number of threads for multithreading (defaults on ada: 8 ( 1 when -w > 0) -r reservation id -f indicates a function call instead of script DEFAULT VALUES: memory : 2500 per core time : 02:00 workers : 0 gpu : no gpu threading: on, 8 threads -bash-4.1$

For example the command matlabsubmit -t "03:27" -m 17000 -s 20 myscript.m will request 17gb of memory and 3 hours and 27 minutes of computing time. It will also set the number of computational threads in Matlab to 20, and it will execute Matlab script myscript.m.

### Example 2: Utilizing Matlab workers (simple)

To utilize additional workers used by Matlab's parallel features such as *parfor*,*spmd*, and *distributed* matlabsubmit provided the option to specify the number of workers. This is done using the *-w <N>* flag (where <N> represents the number of workers). The following example shows a simple case of using additional workers; in this case 8 workers

-bash-4.1$ matlabsubmit -w 8 test.m =============================================== Running Matlab script with following parameters ----------------------------------------------- Script : test.m Workers : 8 Nodes : 1 Mem/proc : 2500 #threads : 1 =============================================== bsub -e MatlabSubmitLOG5/lsf.err -o MatlabSubmitLOG5/lsf.out -L /bin/bash -n 9 -R span[ptile=9] -W 02:00 -M 2500 -R rusage[mem=2500] -J test5 MatlabSubmitLOG5/submission_script Verifying job submission parameters... Verifying project account... Account to charge: 082839397478 Balance (SUs): 80533.2098 SUs to charge: 18.0000 Job <2901543> is submitted to default queue <sn_regular>. ----------------------------------------------- matlabsubmit ID : 5 matlab output file : MatlabSubmitLOG5/matlab.log LSF/matlab output file : MatlabSubmitLOG5/lsf.out LSF/matlab error file : MatlabSubmitLOG5/lsf.err -bash-4.1$

In this example, matlabsubmit will first execute matlab code to create a *parpool* with 8 workers (using the local profile). As can be seen in the output, matlabsubmit requests 9 cores in this case; 1 core for the client and 8 cores for the workers. The only exception is when the user requests 20 workers. In that case matlabsubmit will request 20 cores.

### Writing your own batch file

You can also write your own batch file and submit it manually to the batch system. Below is a simple example of a batch script

#PBS -l nodes=1:ppn=1,walltime=02:00:00,mem=12gb #PBS -N mymatlab #PBS -S /bin/bash #PBS -j oe # load the matlab module module load matlab #$PBS_O_WORKDIR is the directory from which the job was submitted cd $PBS_O_WORKDIR ## run the matlab command matlab -nosplash -nodesktop << EOF a = zeros(10,1); for i=1:10 a(i) = a(i) + i; end a exit EOF

The code between the EOF markers is the actual sample matlab snippet. You will replace this with your own matlab code. Always add the exit command at the end of your matlab code, it tells matlab to exit cleanly. Instead of writing the actual matlab code in your batch script you can also create a separate Matlab script file (needs to have extension .m) where you write your Matlab code. As mentioned before, make sure the last matlab command in your matlab script will be the exit command. Suppose you name your matlab script myscript.m you can replace the matlab command above with:

matlab -nosplash -nodesktop -r myscript

Screen output will be redirected to file as in any EOS batch run (in the sample batch sript it will be redirected to file mymatlab.oXXX, where XXX is the jobid).

## Parallel Matlab

Matlab has excellent capabilities to run your matlab code in parallel; either using multiple cpus or using available gpus. Currently, the Supercomputing Facility has a license for 96 tokens (which means you can run your matlab code in parallel using 96 workers). For parallel computing capabilities Matlab uses Cluster profiles. A cluster profile lets you define certain properties of your cluster (e.g. how to submit jobs, submission parameters, job requirements, etc). Matlab will use the cluster profile to offload parallel (or sequential) matlab code to one or more worker and run it there. Cluster Profiles

NOTE: Instructions below are specific for Matlab version r2012b and r2013b. Later version use a little bit different format but the current format will still work.

### Importing profile

The Supercomputing facility already created a template Cluster Profile for your convenience. Before you can use this profile you need to import it first (you only need to do this once).

1. In the Matlab window, click 'Parallel/Manage Cluster Profiles/Import' 2. Choose '/software/tamuhprc/Matlab/profiles/TAMU.settings' file to import

You can also just type on the matlab commandline:

cpname = parallel.importProfile('/software/tamuhprc/Matlab/profiles/TAMU');

(where **cpname** is the variable that holds the cluster object

#### Setting default profile

To set the default profile do the following:

1. In the Matlab window, click 'Parallel/Set Default' 2. select TAMU.

You can also type on the command line:

parallel.defaultClusterProfile(cpname)

#### Changing Profile properties

Currently the default job requirements specified for the template cluster profile (imported above) are:

'-l nodes=^N^,mem=12gb,walltime=4:00:00'

(the ^N^ will be replaced automatically by Matlab with the actual number of workers you specify).

If your job requirements are different (e.g. walltime, amount of memory) you need to modify them

1. In the Matlab window, click 'Parallel/Manage Profile/' 2. select the profile you want to adjust 3. click "Edit" 4. make the changes. 5. click "Done"

You can also change it on the command line but this requires a few more steps.

STEP 1: get a cluster object from the default cluster: dcluster=parcluster STEP 2: set the job requirements using the ResourceTemplate property: dcluster.ResourceTemplate='-l nodes=^N^,walltime=02:00:00,mem=20gb' In this case your matlab job would request 2 hours, 20GB. STEP 3: if needed, add aditional parameters (e.g. billing account) using the SubmitArguments property: dcluster.SubmitArguments='-l billto=XXX' STEP 4: Save the changes to the cluster: dcluster.saveProfile

Note: although not as flexible, you can set the number of nodes explicetely by replacing ^N^ with actual values (e.g. 2::ppn=8).

Now the default profile has been updated with the above changes.

In case you want to save it as a different profile: dcluster.saveAsProfile('NEWNAME') Where NEWNAME is the name you choose for the profile. Parallel constructs

We will discuss briefly some of the most common parallel matlab concepts. For more detailed information about these constructs, as well as additional parallel constructs consult the Parallel Computing Toolbox User Guide matlabpool

The matlabpool functions enables the full functionality of the parallel language features (parfor and spmd, will be discussed below). matlabpool creates a special job on a pool of workers, and connects the pool to the MATLAB client. For example: matlabpool open 4

: :

matlabpool close This code starts a worker pool using the default cluster profile, with 4 additional workers.

For more detailed information please visit the Matlab matlabpool page. parfor

The concept of a parfor-loop is similar to the standard Matlab for-loop. The difference is that parfor partitions the iterations among the available workers to run in parallel. For example:

matlabpool open 2 parfor i=1:1024 A(i)=sin((i/1024)*2*pi); end matlabpool close

This code will open a matlab pool with 2 workers using the default cluster profile and execute the loop in parallel.

For more information please visit the Matlab parfor page. spmd

spmd runs the same program on all workers concurrently. A typical use of spmd is when you need to run the same program on multiple sets of input. For example, Suppose you have 4 inputs named data1,data2,data3,data4 and you want run funcion myfun on all of them:

matlabpool open 4 spmd (4) data = load(['data' num2str(labindex)]) myresult = myfun(data) end matlabpool close

NOTE: labindex is a Matlab variable and is set to the worker id, values range from 1 to number of workers.

Every worker will have its own version of variable myresult. To access these variables outside the spmd block you append {i} to the variable name, e.g. myresult{3} represents variable myresult from worker 3.

For more information please visit the Matlab spmd page. batch

The parallel constructs we discussed so far are all interactive, meaning that the client starts the workers and then waits for completion of the job before accepting any other input. The batch command will submit a job and return control back to the client immediately. For example, suppose we want to run the parfor loop from above without waiting for the result. First create a matlab function myloop.m

parfor i=1:1024 A(i)=sin((i/1024)*2*pi); end

To run using the batch command: myjob = batch('myloop','matlabpool',4) This will start the parallel job on the workers and control is returned to the client immediately. To see all your running jobs click on Parallel/Monitor Jobs. Use the wait command, e.g. wait(myjob), to wait for the job to finish, use the load command, e.g. load(myjob), to load all variables from the job into the client workspace.

For more information please visit the Matlab batch page. Using GPU

Normally all variables reside in the client workspace and matlab operations are executed on the client machine (e.g. your desktop, or an eos login node). However, Matlab also provides options to utilize available GPUs to run code faster. Running code on the gpu is actually very straightforward. Matlab provides GPU versions for many build-in operations. These operations are executed on the GPU automatically when the variables involved reside on the GPU. The results of these operations will also reside on the GPU. To see what functions can be run on the GPU type:

methods('gpuArray') This will show a list of all available functions that can be run on the GPU, as well as a list of available static functions to create data on the GPU directly (will be discussed later).

NOTE: There is significant overhead of executing code on the gpu because of memory transfers.

Another useful function is: gpuDevice This functions shows all the properties of the GPU. When this function is called from the client (or a node without a GPU) it will just print an error message. Adjusting Cluster Profile

to use the gpus on EOS we need to adjust the job requirements to make sure the job is scheduled on a node with a gpu, the same way you would do it with a regular eos job.

dcluster = parcluster dcluster.ResourceTemplate='-l nodes=1:ppn=1:gpus=1,walltime=02:00:00,mem=20gb'

The above job requirements are just an example. You can adjust the various properties to suit your needs. More detailed information about changing Profile Properties can be found here Copying between client and GPU

To copy variables from the client workspace to the GPU, you can use the gpuArray command. For example:

carr = ones(1000); garr = gpuArray(carr);

will copy variable carr to the GPU wit name garr. If variable carr is not used in the client workspace you can write it as:

garr = gpuArray(ones(1000));

The two versions have the same problem. They both need to copy the 1000x1000 matrix from client workspace to the GPU. We mentioned above that Matlab provides methods to create data directly on the GPU to avoid the overhead of copying data to the GPU. For example:

garr=gpuArray.ones(1000)

This will create a 1000x1000 matrix directly on the GPU consisting of all ones.

You can find a list of all methods to create data directly on the GPU here.

To copy data back to the client workspace Matlab provides the gather operation.

carr2 = gather(garr)

This will copy the array garr on the GPU back to variable carr2 in the client workspace. Overhead

As mentioned before there is considerable overhead involved when using the GPU. Actually, there are two types of overhead. Warming up GPU (first time GPU is used). Data transfer. Warming up

When the GPU is just starting up computation, there are many things that need to be done, both on the Matlab part and the GPU device itself (e.g. loading libraries, initializing the GPU state, etc). For example: matlabpool open 1 spmd 1 tic gpuArray.ones(10,1); toc end This code only creates a 10x1 array of ones on the GPU device. The first run takes an astounding 21.5 seconds to execute while every successive run only needs about 0.00017 seconds. This shows the huge cost of warming up the GPU.

NOTE:These are running times on EOS. Other systems might have very different timing results. Data transfer

GPU operations in Matlab can only be done when the data is physically located on the GPU device. Therefore data might need to be transferred to the GPU device (and vice versa). This is a significant overhead. For example: spmd 1 tic;ag=gpuArray(ones(10000));toc; end The above code only copies a 10000x10000 matrix from client workspace to GPU device. The time it takes is almost 0.6 seconds. This is a significant overhead. Example

Here is a little example that performs a matrix multiplication on the client, a matrix multiplication on the GPU, and prints out elapsed times for both. The actual cpu-gpu matrix multiplication code can be written as: a = rand(1000); tic; b = a*a; toc; tic; ag = gpuArray(a); bg = ag*ag; toc; c = gather(cg) Almost no additional steps are required to use the gpu. Actually, copying the results to the client workspace is not even needed. Variables that reside on the gpu can be printed or plotted just like variables in the client workspace.

The above code will run without problems if Matlab is installed on a computer with a gpu attached. Since EOS does not have gpus attached to the login nodes (where the client is running) we need to ensure the above code is run on a gpu node. We will show how to do it in interactive mode (using matlabpool), and by using the Matlab batch command.

For convenience the code above is saved as mymatrixmult.m Interactive using matlabpool

A matlabpool needs to be opened since a gpu node is needed and the client is running on one of the login nodes (no gpu available) and mymatrixmult needs to be inside a spmd block to ensure code will actually run on the worker instead of the client (see matlabpool section). The code will be as follows: matlabpool open 1 spmd 1 mymatrixmult end matlabpool close Using Matlab batch command

This example is a basic sequential code (i.e. uses only one cpu core), so in this case a matlabpool is not even needed. The Matlab batch command will start the job on one of the workers (which has a gpu). The code will look as follows: batch('mymatrixmult') Warming up the GPU

there is considerable overhead involved when using the GPU. Besides the data transfer overhead mentioned before, there is another kind of overhead; warming up time. When the GPU is just starting up computation, there are many things that need to be done, both on the Matlab part and the GPU device itself (e.g. loading libraries, initializing the GPU state, etc). To get an indication how much time is needed look at the following example:

matlabpool open 1 spmd 1 tic gpuArray.ones(10,1); toc end This code only creates a 10x1 array of ones on the GPU device. The first run takes 0.026 seconds to execute while every sucessive run only needs about 0.00017 seconds (of course different runs will produce slightly different results). This shows the huge cost of warming up the GPU .

NOTE:These are running times on EOS. Other systems might have very different timing results.