[eigen] State of the problem with std::vector

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


Hi,

THE PROBLEM

(as discussed since yesterday on IRC)

std::vector<value_type> (both GCC and MSVC implementations) has a
resize() method that takes a value_type by value.

Since attributes don't work on function parameters (with GCC and
MSVC), this means that this program,

#include <Eigen/Core>
#include <vector>

int main()
{
  std::vector <Eigen::Vector4f> v(10);
  v.resize(20);
}

triggers the unaligned-array-assert (unless of course by pure chance
(50%) the copied vector happens to be aligned).
If we disabled the asserts, it will crash when trying to use aligned
SSE insns on this unaligned location.

THE ONLY POSSIBLE SOLUTION WE CAN SEE
thanks a lot to "alexs" from ##c++ IRC channel...

[18:09] <bjacob> ggael: so i got help on ##c++
[18:09] <bjacob> the only idea that seems to have a chance of working,
[18:09] <bjacob> is to define a separate vector type inheriting Vector4f,
[18:10] <bjacob> this vector type has a copy constructor that doesn't
use SSE insns
[18:10] <bjacob> and a default constructor that doesn't do the
unaligned array assert
[18:10] <bjacob> and use inheritance and implicit conversions to let
the user use std::vector on that vector type
[18:11] <bjacob> while using it as std::vector<Vector4f>
[18:13] <bjacob> so could make this templated .... template<typename
MatrixType> class AllowUnaligned : public MatrixType;
[18:13] <bjacob> std::vector <  AllowUnaligned <Vector4f> >
[18:14] <ggael> ok, I see
[18:17] --> alexs_ a rejoint ce canal (n=alexs@unaffiliated/alexs).
[18:17] <alexs_> Looks interesting :)
[18:19] <bjacob> ok some backlog pasting....
[18:19] <bjacob> http://rafb.net/p/C27reW66.html
[18:20] <bjacob> alexs_: ^
[18:20] <alexs_> yeah :)
[18:20] <bjacob> ggael: http://rafb.net/p/TDr0X549.html
[18:25] <alexs_> You could probably use a specialisation of
vector<Vector4> that statically sets the value_type to the right
thing, to hide it from the user?
[18:29] <bjacob> hm. and by the way set an aligned allocator. good idea.
[18:30] <bjacob> this will mean inheriting from std::vector, never
tried, hope it's easy (don't know what's the best way to preserve the
ctors, assignment operators, etc, that don't get inherited)
[18:30] <alexs_> composition should work ok
[18:30] <alexs_> it's not too many things :)
[18:31] <alexs_> operators are not members of vector anyway
[18:31] <bjacob> you'd recommend composition (i guess this means
having-as-a-member) over inheritance?
[18:31] <bjacob> not even assignment operators?
[18:31] <alexs_> composition for the things that inheritance doesnt bring in
[18:32] <bjacob> oh, i see
[18:46] <bjacob> alexs_: by the way it is not just MSVC that doesn't
allow align attribute on function parameters
[18:46] <bjacob> here, gcc 4.3.2 allows this code to compile but the
attribute isn't honored and i get my assertion at runtime saying the
object is unaligned
[18:48] <alexs_> bjacob: Oh :(
[18:49] <alexs_> is it a function parameter if you want aligned arguments?
[18:49] <alexs_>     -mpreferred-stack-boundary=num
[18:50] <bjacob> hm good idea
[18:50] <alexs_> default is 16 bytes
[18:50] <bjacob> oh -- so it's not what we want then -- as 16 bytes should be OK
[18:51] <alexs_> Unless you use -Os
[18:51] <bjacob> ++ -mpreferred-stack-boundary=16 -I
kde/kdesupport/eigen2/ a.cpp -o a && ./a
[18:51] <bjacob> a.cpp:1: error: -mpreferred-stack-boundary=16 is not
between 2 and 12
[18:51] <alexs_> Yeah, it is raised to a power of 2
[18:51] <bjacob> oops, "++" should be "g++"
[18:51] <alexs_> you want 4 :)
[18:51] <bjacob> ah ok
[18:51] <alexs_> but my man page says that is the default
[18:51] <bjacob> yes and with 4 is still get the same problem
[18:52] <bjacob> "preferred" is probably not strictly honored
[18:52] <alexs_> So it's not aligning them...
[18:52] <alexs_> It does say "attempt"

Cheers,
Benoit

---


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