Re: [eigen] ABI break?

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

ok, done. The Eigen trunk version number is now 2.0.52.
Benoit

2009/3/23 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
> Hi,
>
> IMO, it is pretty clear we have to change the value of AutoAlign to 0.
>
> About Dynamic, I would say that unless some users cannot tolerate such
> an ABI break, I would change its value for a prime number and add a
> limit anyway.
>
> gael.
>
> On Mon, Mar 23, 2009 at 6:18 AM, Patrick Mihelich
> <patrick.mihelich@xxxxxxxxx> wrote:
>> 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
>>>
>>>
>>
>>
>
>
>