Re: [eigen] Alignment issues

[Nicola Gigante <nicola.gigante@xxxxxxxxx>]

Il giorno 14/feb/2014, alle ore 10:19, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> ha scritto:

> On 14.02.2014 03:26, Nicola Gigante wrote:
>> [...]
>> 
>> So if you’re requesting a 32bytes alignment and the program compiles, operator new must return a 32bytes aligned address. If not,
>> the compiler has a bug. So, again, I think it would be useful to make a mapping of behavior/bugs of actual compiler/arch/OS combinations.
> 
> Ok, that's not as bad (or useless) as I originally thought. Another question for clarification:
> Is the compilation supposed to fail immediatly, or if and only if operator new/new[] is used at some point?
> The former would make some working Eigen code not compile anymore (namely code with classes containing Eigen types, that are never new-allocated).
> 

It depends... The standard seems to allow the implementation to support a certain alignment in a specific context and not in another. For example, it could be supported to declare the struct, but it could be supported only on the stack (it makes no sense, but it’s an example), so you get a compile error using operator new. Or it could be unsupported at all and fail directly in the declaration.
It depends on the implementation.

That said, note that Eigen doesn't need exotic alignment requirements (for example, someone on StackOverflow was complaining that he couldn’t use this feature to align memory to page boundaries, i.e. alignas(4096)). 16 or 32 bytes of alignment are more than sensible,
taking into account that a very important platform feature as vectorization instructions depends on that. I think it's very unlikely to find
a compliant implementation that doesn’t support 16 or 32 byte alignment, even on 32bit systems.

>> Of course, nothing guarantees that C++11 alignas() semantics apply to the GNU and VC++ attributes, especially the guarantee that
>> unsupported requirements gives to compilation errors. So it might be a win to use alignas() when supported, instead of the attributes,
>> to get precise guarantees (modulo bugs, again). Then in the documentation you can say “in C++11 mode we take care about alignment issues for you, unless you have a buggy compiler, in which case do as you would in C++98”.
> 
> I think it would rather be:
>> "In (fully compliant) C++11 mode, alignment works automatically or your code will fail to compile. To be safe add EIGEN_MAKE_ALIGNED_OPERATOR_NEW to all classes containing Eigen types."
> But essentially, we already seem to be at the "works automatically" point on 64bit systems (until, if ever, we require higher alignments).
> Maybe we could make EMAON automatically fall back to the default if alignof(std::max_align_t)>=16, but I think that falls into the code cosmetics category.
> 

Code cosmetics is not that unimportant anyway :)

>> If I find the time, I could setup a battery of virtual machines to make extensive comparisons.
> 
> That would be nice, but from Eigen's POV we already found some compilers/libstdc++s (which we want to support for a while) that require work-arounds anyway.
> 

Of course they do, but currently you’re targeting C++98 compilers. I imagine a scenario where you test the availability of alignas() and
enable its use instead of non-standard attributes and custom aligned allocators. This way you (can) make life easier for users and avoid
useless over-allocations. But of course you want to do it only if the compiler truly supports it without bugs.

Does it make sense?


> Christoph

Nicola