Licensing: Parallel Computing Toolbox labs vs independent MATLAB sessions

From a licensing perspective, what's the difference between running n independent MATLAB sessions and running n Parallel Computing Toolbox labs? I sometimes wish I could have more labs on my local machine to test algorithms, but of course run into the limit of 12. But I can have unlimited (well, hardware limited) independent sessions running.

[Geoff]

Here's a thought: Run the parallel toolbox with multiple instances of MatLab =)

I'm gonna try this on my forecasting server that has 16 cores. Two instances of MatLab with parallel toolbox should utilise that quite nicely!

If you write your parallel code effectively, then you should be maxing out all your cores (up to 12, anyway) most of the time. If not, then adding an extra instance of MatLab would do the trick. I wouldn't add too many though, or the OS scheduler is going to struggle.

Generally speaking, having more workers than CPU cores reduces performance (IF all workers are actually doing work).

Answer 1

[Ken Atwell]

Independent MATLAB sessions are just that, independent. You could create more than 12 if you wanted to (and your system can handle it), but they would not be able to partition a single task with PARFOR, for example.

[Richard Brown]

Sorry, I'm not certain I communicated my question very clearly. I guess what I'm asking is whether the limit of 12 workers is related to licensing or whether it's a technical limitation.

I know that with the Distributed Computing Server you essentially pay per worker and I had assumed that the limitation on the Parallel Computing Toolbox was of the same nature. But that would seem strange given that you can run many independent MATLAB instances. However if it's a technical limitation it's a different story. I would love to be able to use any number of workers on my local machine to test parallel algorithms.

[Walter Roberson]

The limit was originally 4 workers, then it was raised to 8, then to 12. The implication to _me_ has always been that it is a licensing matter.

[Geoff]

How many logical cores does your processor have, Richard? If it's more than 12 and you want full utilisation, you may need to translate your algorithms to C/C++ and use OpenMP. If it's 12 or less, MatLab's parallel toolbox will be sufficient to do your parallel tests. You will observe no gains from using more threads than logical cores.

[Walter Roberson]

More threads than logical cores can be beneficial. It is done a lot in programming GUIs even on single-thread single-core machines. The model of having multiple threads waiting for events can be easier to write than designing a state-driven machine that has to figure out which sub-state it is in at each step before it can do any work. I/O is commonly assigned to distinct threads.

[Richard Brown]

I'm not after numerous workers for performance, rather to test my algorithms for correctness before the painful job of porting to MPI c code to run on our Blue Gene supercomputer. My development computers are just dual and quad core Core i5s

[Geoff]

@Walter: Yes, but we're talking about MatLab still, right? I commented earlier that you only reduces performance if you expect them all to be doing work (and I meant 100% load)... But threaded GUI with the parallel toolbox is not typically what you would do in MatLab is it? The whole point of multiple workers in MatLab, as I see it, is to do processing. The only time I would want more workers than the number of cores is if I know that some workers are going to be blocked on I/O. Until MatLab starts providing real threading utilities like semaphores, I don't see its parallel toolbox as particularly useful for anything other than a performance boost.

@Richard: In that case if you need to simulate more than 12 threads you might need to do it manually, but then you'll be testing the correctness of your threading simulation as much as testing your algorithms. You may as well prototype the whole thing in C to begin with. Do you use any linear algebra libraries to handle all the mundane stuff? In my opinion, proving that an algorithm works correctly with 12 threads is sufficient excuse to throw it at a machine with 1000 threads, or however well-hung your supercomputer is =) But there are some who would call me a cowboy.

[Jan]

Walter has written: "More threads than logical cores can be beneficial." A typical example is the (non-Matlab program, I know) 7zip: Distributing the work to two threads on a single core can be 25-40% faster, because one thread can create the tables, while the other is waiting for the data from the disk. Whenever waiting for data from the RAM, disk or network matters, having more threads than cores is an advantage - as long as the job can be parallelized, of course.

[Richard Brown]

@Geoff, yes I should probably prototype in C, but programming with MPI is something I'm learning at the moment, and MATLAB is just so darned easy to prototype with. I'll be using (at least) clapack and cholmod for the heavy lifting. Have you got much experience with C linear algebra libraries?

[Geoff]

No I don't have any experience with those. I've used some pretty raw BLAS stuff in the past but dunno if it was from an official library. I wanted to know what you used, then maybe check it out! ;-) I do have some code that uses Blitz++ which is a heavily templated C++ monster, but I haven't played round with it. Makes your C++ look almost like MatLab. Needs a real compiler though (ie gcc) - not sure if the latest Microsoft Visual C++ can handle the necessary optimisations.

[Kozlov Alexandre]

@Ken: is there any limit for a number of independent MatLab sessions I can run on a single computer? I don't talk about hardware limitation, but a legal one. I have an NNU licence, and I've been told that one cannot run more than 2 MatLab sessions simultaneously. But I never seen any confirmation of this limitation...

Answer 2

[Geoff]

Coming from a different programming background I would intuitively say that with parallelisation you can work concurrently with a single copy of a large dataset in memory. With multiple processes you must load that dataset into each process.

If you had a fairly sizable dataset and a moderate number of workers, the inability to share memory across MatLab processes could be a show-stopper.

However, I don't know for certain if this is really what happens in MatLab. If it doesn't share data across worker threads I'd be extremely surprised, and wonder why I paid $2000 for the toolbox.