Re: [eigen] ABI break? |

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

*To*: eigen@xxxxxxxxxxxxxxxxxxx*Subject*: Re: [eigen] ABI break?*From*: Patrick Mihelich <patrick.mihelich@xxxxxxxxx>*Date*: Sun, 22 Mar 2009 22:18:07 -0700*Dkim-signature*: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=Ftrhgt8Do2owQngqTEUFueoPFtyaHo+4V4yZVVhcBcs=; b=Lo2hC9VDJWHdsz8ZsLzDZH6zJPjExL2w/ZMN8usBkcDN6YIGsZREYyB0/XyKbiO/0n nxnI4AUxTh29HaekpPL8KvR83/Y0A6Xvhm7sj7CsLC22kLWjruWCYedsh8N9Iw19XGay gPNcuhkRhqR1oQWiJr3+/0mfXikC1SobnNGec=*Domainkey-signature*: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Pw1vLcx3v24g8/NaaJOXCgEVLSCSUzPVZmo8oLG5BDF2NZwCGks1Fb8ZjDwImgvSIc Gji9koVSffSjBZzKB3X9DQNLLqR/2LBM1MZWqQNlc7OKhFnkGL6gyO0Y0lX95YZ5IZIH sm6opyObGPoo717M+h60Op0jDVEiW/14hRgLw=

If you don't need ABI stability until 2.1, I say go ahead and make these sorts of mainly internal changes. Especially if it means fixing something nasty like the RowMajor bug.

I don't have a strong opinion on the Dynamic issue either. Enforcing a hard limit on fixed sizes makes sense, otherwise you will have the occasional user who doesn't realize exactly what the difference is and blows out the stack.

Patrick

On Sat, Mar 21, 2009 at 9:55 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:

Hi,

at the moment there are 2 issues in Eigen 2.0 that can make us

considering breaking the ABI for 2.1

First of all, since Eigen is pure template, it doesn't have an ABI by

itself. So what I am speaking of, is the ABI of binary libraries

exposing Eigen objects.

In any case, we must not break the ABI after the 2.1 release (e.g.

libavogadro wants a stable ABI, and will make their 1.0 release soon).

The question is whether it's still OK to break the ABI between 2.0 and

2.1.

Here are the reasons why I'm considering breaking the ABI.

1) (the main reason). The "Options" template parameter to the Matrix

class is a bit-field, with one bit controlling RowMajor/ColMajor

storage, and another bit controlling automatic alignment. The default

is column-major and automatic alignment. We made a mistake in Eigen

2.0: the value 0 corresponds to NO automatic alignment. This means

that if you want a RowMajor matrix and you pass just "RowMajor" as the

Options parameter, then you don't get automatic alignement ... you

have to pass RowMajor|AutoAlign if you want automatic alignment. What

this means is that people using row-major fixed-size vectorizable

matrices can be puzzled as to why they don't get vectorization. The

obvious solution is to set AutoAlign=0 and

DontAlign=the_corresponding_bit. However this means that in a binary

library, functions taking Matrix arguments will have a different

mangled name, so this change breaks the ABI.

2) See this bug report:

http://forum.kde.org/strange-bug-for-large-fixed-sized-matrices-t-38426.html

Basically, a user had a fixed-size 100x100 matrix, so the size was

10000, which gave him errors as 10000 is the value of our constant

Dynamic. So we have 2 options:

a) we can enforce a hard limit on fixed-sizes, e.g. size <= 4096;

b) or we can change the value of Dynamic.

If we do b), that breaks the ABI, as Dynamic is often used as a

template parameter for the Matrix class template.

We've already discussed possible values for Dynamic; the obvious

choice of -1 is dangerous as e.g. a condition like this,

SizeAtCompileTime <= 16

would be satisfied by all dynamic-size matrices; whence our choice of

a large positive value; but then since we're often squaring this

value, in order to avoid integer overflow we don't want to go above

sqrt(MAX_INT) which is roughly 46000; also, we want a value that's

easily recognizable in backtraces and compiler output; finally, the

above bug report shows that this value shouldn't be a square (10000 =

100^2) and more generally should be a prime number; so I propose

33331.

Well, there is always the option of finally setting Dynamic=-1 but

then we have to be extremely careful, not only at the time we make

this change, but ever after! Perhaps some helper macros would help

then.

I don't have a strong opinion between a) and b) but again the big

drawback of b) is breaking the ABI.

Cheers,

Benoit

**Follow-Ups**:**Re: [eigen] ABI break?***From:*Gael Guennebaud

**References**:**[eigen] ABI break?***From:*Benoit Jacob

**Messages sorted by:**[ date | thread ]- Prev by Date:
**[eigen] ABI break?** - Next by Date:
**[eigen] Signed-ness of size types, and better constructors for Matrix** - Previous by thread:
**[eigen] ABI break?** - Next by thread:
**Re: [eigen] ABI break?**

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