Scientific computing is quickly moving to parallel platforms and most software vendors are following suit. The MathWorks, which started parallelizing MATLAB and the company’s other numerical and scientific computing products four years ago, is now setting its sights on cluster and grid computing — and even computing in the cloud. With this in mind, MATLAB has recently been enhanced to work more intimately with distributed computing environments.

The enhancements consist of refinements to The MathWorks’ Parallel Computing Toolbox and MATLAB Distributed Computing Server that allow MATLAB sessions to run transparently over cluster and grid platforms. In addition, new MATLAB compiler and builder upgrades now let developers incorporate MATLAB libraries or functions into standalone executables, which can then be run on clusters or grids, themselves.

The latest MATLAB upgrade includes built-in support for the European EGEE grid (Enabling Grids for E-sciencE). This was accomplished by integrating the Parallel Computing Toolbox and MATLAB Distributed Computing Server with EGEE’s middleware, gLite. This enables MATLAB parallel applications to utilize the European grid infrastructure while running from the desktop. Since EGEE contains more than 70,000 CPUs spread across the continent, that represents almost unlimited computing power for an application.

It’s also now possible for MATLAB users to tap Amazon’s Elastic Compute Cloud. This requires a little more fiddling than hooking up to EGEE, since a system admin person will be required to deal with EC2 licensing and network issues. The MathWorks has written a technical paper on how to configure its products for EC2 and has a consulting service available to help you get started. And while EC2 is not specifically geared for scientific workloads, it might provide a useful platform for loosely-coupled, but highly-scalable technical computing applications.

Making MATLAB cluster- and grid-friendly solves the problems of two related groups of customers: desktop technical computing users and traditional HPC users. The desktop contingent — engineers, analysts, scientific algorithm developers — are already heavily invested in MATLAB products, but their challenges are growing larger. “The problem they have today is that their applications exceed the capacity of their desktop machines,” explains Silvina Grad-Freilich, manager of parallel computing and application deployment marketing at The MathWorks. In many cases they want to move up to HPC clusters, but would rather not leave their familiar MATLAB environment behind.

Traditional supercomputing users, on the other hand, are looking for ease of programming, but don’t want to give up the portability and scalability of the traditional MPI/C and Fortran model. “They want a simple technical computing environment so that they can focus on their science and not on the parallel programming aspects of the problem,” says Grad-Freilich.

Whether on a local cluster or a distributed grid, the underlying model is essentially the same: Use MATLAB parallel constructs and libraries to distribute workloads off the desktop. The way this is accomplished is via the MATLAB Distributed Computing Server, which manages remote MATLAB workers in a compute cluster. A remote worker is essentially the same as a desktop MATLAB process, but it operates remotely and runs its own process in parallel. In truth, multiple workers can also be run locally on the desktop if the user wants to take advantage of multiple CPU cores and doesn’t require the level of parallelism of a distributed solution.

To the MATLAB user, the execution of the workers is usually transparent. Their presence and location is managed underneath the covers and is determined by the hardware configuration visible to MATLAB. The configuration is selected by the user before beginning a MATLAB session if something other than the default setup is required. For example, if a user wants to override his default configuration — say his desktop — he/she could select a local cluster, a remote cluster, or even Amazon’s EC2. When the user initiates the session, any parallelism encountered in the software will try to take advantage of the hardware resources available.

There are multiple ways to inject parallelism into a MATLAB program depending on the nature of the problem and how hard the developers want to work. If they don’t want to make any extra effort, developers can just rely on the latest versions of the MATLAB libraries (the Optimization Toolbox and Genetic Algorithm and Direct Search Toolbox), which come pre-parallelized. No application code changes are needed. If developers are willing to make some minimal changes, they can employ MATLAB parallel constructs in their own application code to achieve additional parallelization. The parallel-for loop (parfor) can be used to execute a loop in parallel, while the new spmd (single program, multiple data) construct allows a developer to distribute data, such as large matrices or arrays, and their associated operations across a distributed system.

Application code and the pre-built MATLAB toolbox libraries are portable across desktops, clusters and grids, since the low-level parallelization is performed by the runtime system based on the configuration resources it sees. Even for a single-core CPU environment, MATLAB is smart enough to fall back to serial execution when it encounters parallel code. Developers can insist on parallelization by specifying a number of workers to employ for a particular instance of a parfor or spmd construct. In this case, if the workers are not available (not enough resources or not enough licenses), an error is thrown back to the application, which then must deal with it.

Another way The MathWorks is expanding MATLAB’s horizons is by leveraging this new distributed functionality for standalone applications. Using the MATLAB compiler and builder, developers can construct MATLAB executables or shared libraries, which can be hooked into C, Fortran, or even Java applications. The resulting programs can take advantage of MATLAB’s parallelization abilities while maintaining portability across different platforms.

For example, a quantitative analyst (quant) could develop a MATLAB-based financial model on his or her desktop and then incorporate that model into a portfolio manager’s high-level spreadsheet application. The idea is an old one in software engineering: build a repository of portable software libraries to be used for a wide range of applications. In this case, since the libraries can utilize MATLAB’s distributed computing capabilities, it becomes a path to parallelization.

There are no royalty fees associated with deployed MATLAB code. But the end user has to buy enough MATLAB worker licenses to support the level of parallelization required by the application. A worker license is checked out from the license manager when a worker starts up and is returned to the pool when the worker is shut down. The hardware that the application is being executed upon is only indirectly related to the number of licenses purchased. It’s up to the user how to map workers to hardware.

Loren Dean, director in the MATLAB development organization, says their general recommendation is to map one worker per socket. And although MATLAB supports multithreading to some extent, one computational thread per worker is probably optimal in most cases, especially if the application is memory bound. While in many cases, that means cores are going to be idle, the economics of distributed computing may allow for such inefficiencies. Says Dean: “When you look at the cloud and grid resources that are becoming available, for the most part, that’s all about multi-processing. So when you really want to have once piece of code that’s going to scale naturally, multi-processing just seems more logical.”