[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Changing octave to exploit multi-core hardware
From: |
Jaroslav Hajek |
Subject: |
Re: Changing octave to exploit multi-core hardware |
Date: |
Tue, 25 Mar 2008 20:52:59 +0100 |
On Tue, Mar 25, 2008 at 7:30 PM, John W. Eaton <address@hidden> 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
- Re: Changing octave to exploit multi-core hardware, (continued)
- Re: Changing octave to exploit multi-core hardware, Michael Goffioul, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Aaron Birenboim, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Quentin Spencer, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, Jaroslav Hajek, 2008/03/25
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
- Re: Changing octave to exploit multi-core hardware,
Jaroslav Hajek <=
- Re: Changing octave to exploit multi-core hardware, John W. Eaton, 2008/03/25
Re: Changing octave to exploit multi-core hardware, Michael Creel, 2008/03/25