Re: [eigen] enabling OpenMP in only a subset of a library

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


Hi,

sorry for late reply but I guess the only solution is to recompile everything.

In the future, if we want to support hybrid OpenMP/non-OpenMP code, we
could make each function whose implementation depends on the
activation of OpenMP has a related template parameter, e.g.:

template<....., bool omp_enabled = EIGEN_OMP_ENABLED>
void foo(....);

This way the parallel and sequential versions will have different
mangling names.

cheers,
Gael.

On Fri, May 10, 2013 at 4:24 AM, Jim Bosch <talljimbo@xxxxxxxxx> wrote:
> We have a large software framework that uses Eigen in a lot of places (many
> libraries linked together; often these are linked into Python modules).
> We're almost always using Eigen in single-threaded processes that can only
> use a single core (because any other cores will be busy with other similar
> processes), and we're quite happy just using Eigen without any threading or
> OpenMP options.
>
> However, we also have a larger problem for which we'd like to turn on OpenMP
> support in Eigen, and utilize multiple cores in a single process - but we
> want to be able to link the OpenMP-enabled code against the rest of the
> framework that uses Eigen without any kind of threading.
>
> As I understand it, that's not possible to do naively, as it means we end up
> defining some inline functions (e.g. nbThreads) in different ways in
> different compilation units, and that's Undefined Behavior.
>
> Is there any way to make this work without having to recompile all the
> non-OpenMP code with OpenMP support while calling setNbThreads(1) to disable
> it until we want it?  Or other recommendations on how to accomplish what we
> want to do here?
>
> Thanks in advance!
>
>
> Jim
>
>



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/