Thread Subject: Low-tech distributed computing?

I run a lot of fairly computation heavy simulations and I'm
in the market for a new computer to speed things up.

At the moment, I'm considering buying a top of the line
machine with two Xeon quad-core processors and 32GB of RAM.
This would give me 8 cores with 4GB per core.

I'm considering a couple ways of trying to use all the cores
to their best advantage.

1. The low-tech approach: Invoke 8 separate matlab sessions
on the computer and run completely independent matlab code
on each. This would be the easiest approach given my current
code which is not set up for parallel computing.

2. The hi(gher) tech approach: Get a license for the
distributed computing toolbox and the distributed computing
engine and run 8 separate workers in the same matlab
session. My sense is that this is the "right" way to do
this, but I know that I'll need to modify my code a bit to
get this to work. This should be possible--my code is
essentially embarrassingly parallel, but currently relies on
the previous iteration for starting points. So, if I can
figure how to address the starting point problem, this
should work.

Does anyone have thoughts on the relative merits of these
approaches?

Also, does anyone know how well the 32GB of memory will be
distributed to all the cores? I know this isn't a matlab
thing, but an operating system/chip thing, but thought
someone might know.

Thanks!

Susan,

You have a good handle on the different approaches that could be taken.

Starting 8 individual MATLABs means that you have to manage the launching of
computations and the storage of input/output data. You will have to write
resource/data management code to coordinate between your 8 MATLABs..

In your case, the chief advantages of using the toolbox and the engine are
the ease of programming, management of computations and management of data.
You do your programming within the MATLAB environment and add parallelism to
your MATLAB code by using simple constructs like parfor. The distribution of
computations to the available MATLAB workers is done automatically, without
any intervention from you. The same goes for the storage and retrieval of
data.

Btw, it might or might not be a good idea to try and run 8 MATLABs or 8
MATLAB workers. If your program uses large data sets, the contention for the
memory bus might increase, thus slowing down the program. You probably want
to experiment with 4 instead of 8.


In addition to the two options that you mentioned:
3. The toolbox allows you to run 4 local MATLAB workers. Additionally, you
could also explore:
    a) Using the maxNumCompThreads function to make each of the 4 workers
use 2 threads.
    b) Running 2 MATLABs, each with 4 local workers. Although this option is
less than ideal, it is better than
        (1) because it involves you coordinating 2 MATLABs instead of 8.


FYI, Distributed Computing Toobox has been renamed to Parallel Computing
Toobox, while MATLAB Distributed Computing Engine has been renamed to MATLAB
Distributed Computing Server.

Cheers,
Arjav


"Susan Stratton" <susanestratton@hotmail.com> wrote in message
news:fq1np6$ote$1@fred.mathworks.com...
>I run a lot of fairly computation heavy simulations and I'm
> in the market for a new computer to speed things up.
>
> At the moment, I'm considering buying a top of the line
> machine with two Xeon quad-core processors and 32GB of RAM.
> This would give me 8 cores with 4GB per core.
>
> I'm considering a couple ways of trying to use all the cores
> to their best advantage.
>
> 1. The low-tech approach: Invoke 8 separate matlab sessions
> on the computer and run completely independent matlab code
> on each. This would be the easiest approach given my current
> code which is not set up for parallel computing.
>
> 2. The hi(gher) tech approach: Get a license for the
> distributed computing toolbox and the distributed computing
> engine and run 8 separate workers in the same matlab
> session. My sense is that this is the "right" way to do
> this, but I know that I'll need to modify my code a bit to
> get this to work. This should be possible--my code is
> essentially embarrassingly parallel, but currently relies on
> the previous iteration for starting points. So, if I can
> figure how to address the starting point problem, this
> should work.
>
> Does anyone have thoughts on the relative merits of these
> approaches?
>
> Also, does anyone know how well the 32GB of memory will be
> distributed to all the cores? I know this isn't a matlab
> thing, but an operating system/chip thing, but thought
> someone might know.
>
> Thanks!