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

2015-01-29 16:21 GMT-05:00 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:

On Thu, Jan 29, 2015 at 5:02 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

2015-01-28 1:27 GMT-05:00 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
Or maybe it's time to just make Eigen itself default to visibility=hidden attributes?

I would like to push for this. Otherwise, the user has to remember to build all his different Eigen-using DSOs with -fvisibility-inlines-hidden.

Eigen is a pure headers-only library, so normal users expect to use in a TU only the Eigen code compiled in that TU, from Eigen headers. To match that expectation, we need to make Eigen default to hidden visibility. Any objection? We can always offer a preprocessor switch to opt out from that.

I'm concerned about binary size explosion, for instance matrix product asm is pretty heavy.

What is the scenario where binary size would increase?

Benoit

gael

Benoit

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