Changing octave to exploit multi-core hardware

[Jaroslav Hajek]

On Tue, Mar 25, 2008 at 7:30 PM, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
> On 25-Mar-2008, Jaroslav Hajek wrote:
>
>  | A single OpenMP directive could do that, or even autoparallelization
>  | with some compilers,
>  | e.g. Intel C++. But there are two obstacles: first, the OCTAVE_QUIT
>  | macro (which breaks independence of cycles) and second, there is no
>  | guarantee that F has no side effects.
>
>  OK.  Suppose the function has no side effects (at least when compiling
>  with GCC, this property could be declared with the "pure" or "const"
>  attribute).  The OCTAVE_QUIT macro checks a global variable and calls
>  a function to handle an interrupt signal.  How should that be handled
>  if the loop is executing in parallel?
>
>  jwe
>

I'm not sure about the details of using C++ exceptions in
OpenMP-parallelized blocks,
a general advice is to avoid such practice. I think a possible OpenMP
solution for this particular loop is (note that break statement is not
allowed inside an OpenMP parallel for)

#pragma omp parallel for schedule(dynamic)
   for (octave_idx_type i = 0; i < len; i++)
     {
        if (! octave_signal_caught)
          p[i] = fcn (m[i]);
     }

  OCTAVE_QUIT;

when compiled with -fopenmp (for GCC 4.2.0+) or similar option for
other compilers,
the loop will automatically be multithreaded.

personally, I guess that it's the indirect call (i.e. the fact that
fcn is a function argument) that would prevent some optimizations here
(inlining etc); compilers are known to be generally bad at propagating
functional constants, so I'd consider helping here using templates.
This can be done by modifying the ARRAY_MAPPER and similar macros in
src/ov-re-mat.cc etc.
Also, it may be beneficial not to check octave_signal_caught in every
cycle, but rather use some chunking, but I guess that's really a minor
issue.


-- 
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz