Comments on: Using Parallel For Loops (parfor) with MATLAB® and Jacket http://blog.accelereyes.com/blog/2010/02/10/using-parallel-for-loops-parfor-with-matlab-and-jacket/ Helpful posts about GPU computing. Discussion of Jacket and ArrayFire. Real speedups on real code! Wed, 02 Feb 2011 15:32:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: brett http://blog.accelereyes.com/blog/2010/02/10/using-parallel-for-loops-parfor-with-matlab-and-jacket/comment-page-1/#comment-120 brett Fri, 26 Feb 2010 15:10:05 +0000 http://www.accelereyes.com/blog/?p=128#comment-120 Let me explain a little about ideal configuration, first. If you want to use Jacket within a parfor loop, you ought to have a number of GPUs equal to the number of workers you have started in PCT. So, for example, if you have a 4 CPU machine and have it configured to use a matlab pool of 4 workers, you would to have 4 GPUs. If you have fewer GPUs than CPUs, our recommendation is to use fewer workers. If you use more workers than GPUs, you will get into a situation called thrashing. This is essentially where the different workers are competing with each other for access to the GPUs. The end result is poor performance because the GPUs spend too much time flipping from task to task, rather than staying focused. So, let's assume you have an optimal configuration with "n" number of CPUs and GPUs matching. In this case, with Jacket MGL, each of the workers would have their own GPU. Your parfor loop will then split the iterations across each of the CPU/GPU pairs, and each worker would accomplished 1/n of the iterations. Assuming you use the Jacket gsingle or gdouble data types, your FFTs would then be offloaded by the workers to the GPU for computation. In small matrices, your FFTs may not see much speed up, but if you are using large matrices, we've seen extremely significant performance improvements. Let me explain a little about ideal configuration, first. If you want to
use Jacket within a parfor loop, you ought to have a number of GPUs equal to
the number of workers you have started in PCT. So, for example, if you have
a 4 CPU machine and have it configured to use a matlab pool of 4 workers,
you would to have 4 GPUs.

If you have fewer GPUs than CPUs, our recommendation is to use fewer
workers. If you use more workers than GPUs, you will get into a situation
called thrashing. This is essentially where the different workers are
competing with each other for access to the GPUs. The end result is poor
performance because the GPUs spend too much time flipping from task to task,
rather than staying focused.

So, let’s assume you have an optimal configuration with “n” number of CPUs
and GPUs matching. In this case, with Jacket MGL, each of the workers would
have their own GPU. Your parfor loop will then split the iterations across
each of the CPU/GPU pairs, and each worker would accomplished 1/n of the
iterations. Assuming you use the Jacket gsingle or gdouble data types, your
FFTs would then be offloaded by the workers to the GPU for computation.

In small matrices, your FFTs may not see much speed up, but if you are using
large matrices, we’ve seen extremely significant performance improvements.

]]> By: none http://blog.accelereyes.com/blog/2010/02/10/using-parallel-for-loops-parfor-with-matlab-and-jacket/comment-page-1/#comment-115 none Thu, 25 Feb 2010 21:29:24 +0000 http://www.accelereyes.com/blog/?p=128#comment-115 How does CUDA/Jacket handle scheduling if I have say, 8 CPUs all doing CUDA FFTs within a parfor loop? I've tried this before (without Jacket) but the computer locked up (I have a separate video card). Is this kind of functionality supported and/or stable? How does CUDA/Jacket handle scheduling if I have say, 8 CPUs all doing CUDA FFTs within a parfor loop? I’ve tried this before (without Jacket) but the computer locked up (I have a separate video card).

Is this kind of functionality supported and/or stable?

]]>