Re: [eigen] How do you link multiple versions (e.g. AVX vs SSE) of the same Eigen code?

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

So after a day of thinking about this, this actually sounds like the least-bad approach.

In fact, like you mention, this approach has a unique advantage, since it allows to load only the useful path at runtime, if we use dlopen() / dlsym() instead of linking.

We will still have to make sure that these shared libraries are built with visibility=hidden. Or maybe it's time to just make Eigen itself default to visibility=hidden attributes?

Benoit

2015-01-27 16:45 GMT-05:00 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:

You're right, that approach works.

However, having to put paths in separate DSOs has undesirable effects (loss of optimization opportunities, longer application startup times).

Is there a way to achieve this without separate DSOs?

Really it seems that all I want is a way to tell the compiler a stronger version of visibility(hidden) : I want it to be so hidden that it's not even visible to other TUs within the same DSO. Does that exist?

Benoit

2015-01-27 16:42 GMT-05:00 Rob Conde <rob.conde@xxxxxxxxxxxxxxxx>:

Create interfaces to the high level functions (e.g. foo) and create a dll compiling with each option, then load the correct one at run-time?

Rob

---

From: Benoit Jacob <jacob.benoit.1@xxxxxxxxx>
Sent: Tuesday, January 27, 2015 4:29 PM
To: eigen
Subject: [eigen] How do you link multiple versions (e.g. AVX vs SSE) of the same Eigen code?

 

Hi List,

The question has been around for a long time: one often needs to compile Eigen code with multiple sets of compiler flags, and select at runtime between them, to take advantage of possibly-present CPU features such as AVX.

I always thought that I could simply compile the same Eigen-using code multiple times, with just a different namespace around my Eigen-using function each time, like

#include <Eigen/Core>

namespace avx_code_path {
void foo(Eigen::Vector4f& v)
{
    v += v;
}
}

However, there is a problem with this: each of these code paths compiles Eigen code under the same, non-prefixed, Eigen namespace, each time with different resulting binary code due to different compiler flags. We are thus in a case of undefined behavior due to multiple definitions of inline functions (Eigen's funtions) actually being different.

I was hoping that this wasn't a big deal, that in practice the linker would do the right thing and let the code in each TU use the Eigen symbols defined in the same TU, so there would be no mixup. I was wrong... I'm seeing mixups on a basic testcase here, where my AVX codepath uses Eigen code from the non-AVX codepath.

So this approach doesn't work.

An approach that works is to #define Eigen EigenAVX, but this is very annoying because you can't anymore pass around Eigen objects, you have to somehow reinterpret_cast them to EigenAVX objects.

Any better approach?

Thanks,
Benoit