Re: [eigen] alignment issues, conversion between aligned / unaligned dat

Hello Christoph.

Thanks for your help.

Just for reference, I am using Visual Studio 2013 compiler, 64bit platform, and Eigen 3.3.5.

> You can simply copy in either direction.

Thanks, that certainly helped..

> or you can mix aligned and non-aligned data inside expressions

I just tried some expressions and the test confirms your statement. I suppose I must have mixed up some wrong dimensions errors with alignment issues.

> Rotation2D stores just a single Scalar (the angle), so there is no need/possibility to align it.

The issue I have with Rotation2D is the following:

Eigen::Matrix<double, 2, 1, Eigen::DontAlign> v, w;

Eigen::Rotation2Dd rot(3.);

// Following fails to compile:

v = rot * w;

// Explicit temporary helps:

v = rot * Eigen::Matrix<double, 2, 1>(w);

So thanks for the hint about I understand that there is always a way to rotate the vector. I am just pointing out, that as a user of a finely polished library, I would expect the Rotation2D to just work with both aligned and non-aligned types.

Gruesse nach Bremen,

Vojtech

On Mon, Aug 20, 2018 at 3:37 PM, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On 2018-08-20 15:14, bubnikv wrote:

Hello.

We are developing a 3D printing software https://github.com/prusa3d/slic3r
(fork of http://slic3r.org/)

We are now trying to replace the homebrew point classes with the Eigen
fixed size types. As the code base is quite large, we want to avoid
alignment issues by declaring fixed vector types with the Eigen::DontAlign
attribute. So far so good, with the exception of Eigen::Rotation2D, which
is not templated with the alignment attribute, so it cannot be used against
the fixed size matrices with Eigen::DontAlign. Is there any reason for
that? Would you guys please extend the class with the alignment template
attribute?

Rotation2D stores just a single Scalar (the angle), so there is no need/possibility to align it.
Alternatively, you could store a 2D rotation as a 2x2 matrix, or as a complex number (neither of them inherits from RotationBase, though).

We are thinking of using https://github.com/libigl/libigl for some
operations on triangle meshes, where the vectorized operations may or may
not be beneficial. We may just disable alignment / vectorization for the
whole application. We are not sure about the performance penalty, but
looking at the evaluation of Eigen 2 from 2008
http://eigen.tuxfamily.org/index.php?title=Benchmark-August2008
the loss may be significant.

On modern CPUs the difference between aligned and not-aligned is far less or even non-existing (except for effects like crossing cache-lines). And with Eigen 3.3 it is possible to use vectorization on unaligned data (enabled by default):
http://eigen.tuxfamily.org/bz/show_bug.cgi?id=256#c10

So make meaningful benchmarks on the CPU you want to target to decide if you need to invest time into that.

We may then think about converting between the aligned / non aligned
values. Does Eigen support any conversion between aligned / unaligned
types? I know about the .cast<>() operator, but it does not allow me to
change the alignment attribute.

You can simply copy in either direction, or you can mix aligned and non-aligned data inside expressions. No need to cast here.

Christoph

Thanks for your time,
Vojtech

--
Dr.-Ing. Christoph Hertzberg

Besuchsadresse der Nebengeschäftsstelle:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 5
28359 Bremen, Germany

Postadresse der Hauptgeschäftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Straße 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4021
Zentrale: +49 421 178 45-0
E-Mail: christoph.hertzberg@xxxxxxx

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Straße 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/672/50006
-----------------------------------------------------------------------