[eigen] Eigen 3.4 release candidate 1!

[Christoph Hertzberg]

Hello Eigen users!

We are happy to announce the release of 3.4-rc1. This is a release
candidate which is considered feature complete and only will get bug
fixes until 3.4.0 is released.
This is not yet a stable release!

We encourage everyone, especially who is currently working with a 3.3
version to try upgrading to 3.4-rc1 and report any regressions with any
compilers and architectures you are using (this includes run-time
errors, compile errors and compiler warnings).
Eigen should work with any C++ standard between C++03 and C++20, with
GCC 4.8 (or later), Clang 3.3 (or later), MSVC 2012 (or later), and
recent versions of CUDA, HIP, SYCL, on any target platform. If enabled
by the compiler this includes SIMD vectorization for SSE/AVX/AVX512,
AltiVec, MSA, NEON, SVE, ZVector.

To publish test results, you can run the unit tests as described here:
[https://eigen.tuxfamily.org/index.php?title=Tests]
Please report issues until April 25th, or tell us if you are still in
the process of testing.


The 3.4 release will be the last Eigen version with C++03 support.
Support of the 3.3 branch may soon be stopped.

The next major version will certainly also stop supporting some older
compiler versions.


Regarding the version-numbering:
There was previously a 3.4 branch with recently was deleted again, as it
was done prematurely and not properly kept up-to-date.
Unfortunately, this means that the version number (specified in
Eigen/src/Core/util/Macros.h) had to be reset to 3.3.91 (the final 3.4
release will have version 3.4.0). Version test macros will work
incorrectly with any commit from master between 2021-02-17 and today. We
apologize for any inconvenience this may cause.


Cheers,
Christoph





--
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.: [phone]
Zentrale: [phone]
E-Mail: ***@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany

Geschäftsführung:
Prof. Dr. Antonio Krüger

Vorsitzender des Aufsichtsrats:
Dr. Gabriël Clemens
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------

[D***@dlr.de]

Hello all,

I've compiled our CFD Code with Eigen 3.4-rc1 and ran a few benchmarks relative to Eigen 3.2.9.

Unfortunately, I'm seeing the negative performance impact introduced by Eigen 3.3 continue to exist (which is why we're still hanging on to the 3.2 branch).

I've compiled our code with Eigen 3.2.9 as well as 3.4-rc1 with both clang and gcc, on a macOS x86-64 system (Big Sur) with the following CPU feature flags
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET BMI1 AVX2 FDPEO SMEP BMI2 ERMS INVPCID PQM FPU_CSDS MPX PQE AVX512F AVX512DQ RDSEED ADX SMAP CLFSOPT CLWB IPT AVX512CD AVX512BW AVX512VL PKU AVX512VNNI MDCLEAR IBRS STIBP L1DF ACAPMSR SSBD

Compilation settings were: -std=c++17 -fopenmp -Ofast -march=native -fno-finite-math-only -DEIGEN_DONT_PARALLELIZE=1
(we split our work up among threads ourselves, but the benchmarks are single-threaded anyway).

The clang version was homebrew's llvm: stable 11.1.0 (bottled); gcc was homebrew's gcc: stable 10.2.0 (bottled).

We're using Eigen for small, fixed-size vectors and occasionally matrices of doubles (of varying lengths, e.g. 5, 6, 7, 8, 13, ...), mainly accessing individual elements, or fixed-size (length 3) segments at compile-time known offsets (indices). Occasionally, we also have matrix-vector products of these, but they probably play a smaller role. These are the "Res" (Residual computation) benchmarks, where we do this over a whole mesh with multiple loops, gradient computations, ...

Then we do the same thing but use Eigen's (unsupported) AutoDiffScalar using a fairly big fixed-max-size (e.g. when our PDE has 6 state variables, then AutoDiffScalar has Eigen::Dynamic derivatives with a max-size of 6 * 24 + 1). These types are quite large, but it's still faster than fully dynamic heap allocation. These are the "Jac" (Jacobian computation) benchmarks, which otherwise largely mimic the "Res" benchmarks.

https://www.maven.de/stuff/coda_benchmarks_eigen.pdf

In these graphs everything is relative to the clang Eigen 3.2.9 baseline being 1.0. Higher numbers are faster (2.0 would be twice as fast as the clang Eigen 3.2.9 using build).

The first two benchmarks (Closure/...) are actual micro-benchmarks. In the first one, we have an input vector with 6 doubles, and from that compute a vector with 13 doubles (the first six are the same as the input, and the remaining 7 are derived values computed from those input values). The 2nd version also augments gradients, which means it also has input gradients (Matrix<Matrix<double, 3, 1>, 6, 1>) and outputs augmented gradients (Matrix<Matrix<double, 3, 1>, 13, 1>).

The next set of benchmarks is the residual computation (which performs multiple loops over a mesh with various computations). One (small) part of this is the Closure-stuff from the first two benchmarks.

The final set is the computation / approximation of the derivative using AutoDiffScalar instead of double on a local level.

For these benchmarks (Res and Jac), the sizes of the vectors & matrices roughly increases for each set of equations (Euler <= NavierStokes < RANSSAneg < ...).

For the first microbenchmark Closure/AugmentGF we seem to be hitting a pathological case in the partial vectorization as disabling that seems to fix the problem. The input vector contains 6 double, the output 13. Remember this mainly uses individual values or segment<3> access to the momentum-sub-vector.

The bigger "Res" benchmarks are generally a bit slower (even though not majorly so), but more so with gcc.

The even bigger "Jac" benchmarks do see big slow-downs (performance 0.7 down do 0.3), which seem to get worse as we include more (and larger) AutoDiffScalars. We didn't see this relative decrease for the otherwise roughly similar "Res" benchmarks, so something seems to be strange there (either in AutoDiffScalar, or in the use of custom scalar types itself). I'm wondering whether some Eigen internal operations may accidentally (or purposely) create more (temporary) copies of scalars, which for a custom type might be costly...


Unfortunately providing minimized, self-contained reproducers exhibiting the same behavior is quite difficult... :(

I will try to work on figuring out a reproducer for the first microbenchmark where partial vectorization has a negative effect.


If anyone has any ideas what could be happening (or things they would like me to try), I'm all ears. We really would like to move to a current Eigen version!


Best regards

Daniel Vollmer

--------------------------
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Daniel Vollmer | AS C²A²S²E
www.DLR.de

________________________________________
From: Christoph Hertzberg <***@informatik.uni-bremen.de>
Sent: Monday, 19 April 2021 10:14:15
To: ***@lists.tuxfamily.org
Subject: [eigen] Eigen 3.4 release candidate 1!

Hello Eigen users!

We are happy to announce the release of 3.4-rc1. This is a release
candidate which is considered feature complete and only will get bug
fixes until 3.4.0 is released.
This is not yet a stable release!

We encourage everyone, especially who is currently working with a 3.3
version to try upgrading to 3.4-rc1 and report any regressions with any
compilers and architectures you are using (this includes run-time
errors, compile errors and compiler warnings).
Eigen should work with any C++ standard between C++03 and C++20, with
GCC 4.8 (or later), Clang 3.3 (or later), MSVC 2012 (or later), and
recent versions of CUDA, HIP, SYCL, on any target platform. If enabled
by the compiler this includes SIMD vectorization for SSE/AVX/AVX512,
AltiVec, MSA, NEON, SVE, ZVector.

To publish test results, you can run the unit tests as described here:
[https://eigen.tuxfamily.org/index.php?title=Tests]
Please report issues until April 25th, or tell us if you are still in
the process of testing.


The 3.4 release will be the last Eigen version with C++03 support.
Support of the 3.3 branch may soon be stopped.

The next major version will certainly also stop supporting some older
compiler versions.


Regarding the version-numbering:
There was previously a 3.4 branch with recently was deleted again, as it
was done prematurely and not properly kept up-to-date.
Unfortunately, this means that the version number (specified in
Eigen/src/Core/util/Macros.h) had to be reset to 3.3.91 (the final 3.4
release will have version 3.4.0). Version test macros will work
incorrectly with any commit from master between 2021-02-17 and today. We
apologize for any inconvenience this may cause.


Cheers,
Christoph





--
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.: [phone]
Zentrale: [phone]
E-Mail: ***@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany

Geschäftsführung:
Prof. Dr. Antonio Krüger

Vorsitzender des Aufsichtsrats:
Dr. Gabriël Clemens
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------

[D***@dlr.de]

Hello,

after a lot of measuring, profiling, and digging a small update:

The Closure benchmark slow-down has been reported with a repo as https://gitlab.com/libeigen/eigen/-/issues/2225 .

Interestingly, this slow-down also seems to affect the cases where we're mainly working with vectors / matrices of AutoDiffScalar<Dynamic Matrix with large in-line storage>, see for example the differences of Jac/FV/RANSSAneg for "clang 3.4-587a6915" vs "clang 3.4-587a6915 EIGEN_UNALIGNED_VECTORIZE=0". So this probably isn't just due to the compiler being able to keep stuff in registers more (as the AutoDiffScalars are way too large for that anyway).

One large problem that causes a big discrepancy in the Jac/ tests was naive copying of (unused) storage for dynamically sized storage, reported as https://gitlab.com/libeigen/eigen/-/issues/2229 and already fixed. As you can see, the fix improves performance for the Jac/ tests a lot. Thank you!

Some cases are still a fair bit worse (Res/FV/Euler, Res/FV/RANSSAneg, Res/DG/Euler, Jac/FV/NavierStokes) but overall it's not looking as bad as it used to. :)

I'm still investigating some crashes when using 3.4 (which are not there with 3.2) but I cannot yet say whether that is a problem in Eigen 3.4 or somewhere else.



Best regards

Daniel Vollmer

--------------------------
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Daniel Vollmer | AS C²A²S²E
www.DLR.de

________________________________________
From: ***@dlr.de <***@dlr.de>
Sent: Monday, 19 April 2021 16:27:51
To: ***@lists.tuxfamily.org
Subject: Re: [eigen] Eigen 3.4 release candidate 1!

Hello all,

I've compiled our CFD Code with Eigen 3.4-rc1 and ran a few benchmarks relative to Eigen 3.2.9.

Unfortunately, I'm seeing the negative performance impact introduced by Eigen 3.3 continue to exist (which is why we're still hanging on to the 3.2 branch).

I've compiled our code with Eigen 3.2.9 as well as 3.4-rc1 with both clang and gcc, on a macOS x86-64 system (Big Sur) with the following CPU feature flags
machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET BMI1 AVX2 FDPEO SMEP BMI2 ERMS INVPCID PQM FPU_CSDS MPX PQE AVX512F AVX512DQ RDSEED ADX SMAP CLFSOPT CLWB IPT AVX512CD AVX512BW AVX512VL PKU AVX512VNNI MDCLEAR IBRS STIBP L1DF ACAPMSR SSBD

Compilation settings were: -std=c++17 -fopenmp -Ofast -march=native -fno-finite-math-only -DEIGEN_DONT_PARALLELIZE=1
(we split our work up among threads ourselves, but the benchmarks are single-threaded anyway).

The clang version was homebrew's llvm: stable 11.1.0 (bottled); gcc was homebrew's gcc: stable 10.2.0 (bottled).

We're using Eigen for small, fixed-size vectors and occasionally matrices of doubles (of varying lengths, e.g. 5, 6, 7, 8, 13, ...), mainly accessing individual elements, or fixed-size (length 3) segments at compile-time known offsets (indices). Occasionally, we also have matrix-vector products of these, but they probably play a smaller role. These are the "Res" (Residual computation) benchmarks, where we do this over a whole mesh with multiple loops, gradient computations, ...

Then we do the same thing but use Eigen's (unsupported) AutoDiffScalar using a fairly big fixed-max-size (e.g. when our PDE has 6 state variables, then AutoDiffScalar has Eigen::Dynamic derivatives with a max-size of 6 * 24 + 1). These types are quite large, but it's still faster than fully dynamic heap allocation. These are the "Jac" (Jacobian computation) benchmarks, which otherwise largely mimic the "Res" benchmarks.

https://www.maven.de/stuff/coda_benchmarks_eigen.pdf

In these graphs everything is relative to the clang Eigen 3.2.9 baseline being 1.0. Higher numbers are faster (2.0 would be twice as fast as the clang Eigen 3.2.9 using build).

The first two benchmarks (Closure/...) are actual micro-benchmarks. In the first one, we have an input vector with 6 doubles, and from that compute a vector with 13 doubles (the first six are the same as the input, and the remaining 7 are derived values computed from those input values). The 2nd version also augments gradients, which means it also has input gradients (Matrix<Matrix<double, 3, 1>, 6, 1>) and outputs augmented gradients (Matrix<Matrix<double, 3, 1>, 13, 1>).

The next set of benchmarks is the residual computation (which performs multiple loops over a mesh with various computations). One (small) part of this is the Closure-stuff from the first two benchmarks.

The final set is the computation / approximation of the derivative using AutoDiffScalar instead of double on a local level.

For these benchmarks (Res and Jac), the sizes of the vectors & matrices roughly increases for each set of equations (Euler <= NavierStokes < RANSSAneg < ...).

For the first microbenchmark Closure/AugmentGF we seem to be hitting a pathological case in the partial vectorization as disabling that seems to fix the problem. The input vector contains 6 double, the output 13. Remember this mainly uses individual values or segment<3> access to the momentum-sub-vector.

The bigger "Res" benchmarks are generally a bit slower (even though not majorly so), but more so with gcc.

The even bigger "Jac" benchmarks do see big slow-downs (performance 0.7 down do 0.3), which seem to get worse as we include more (and larger) AutoDiffScalars. We didn't see this relative decrease for the otherwise roughly similar "Res" benchmarks, so something seems to be strange there (either in AutoDiffScalar, or in the use of custom scalar types itself). I'm wondering whether some Eigen internal operations may accidentally (or purposely) create more (temporary) copies of scalars, which for a custom type might be costly...


Unfortunately providing minimized, self-contained reproducers exhibiting the same behavior is quite difficult... :(

I will try to work on figuring out a reproducer for the first microbenchmark where partial vectorization has a negative effect.


If anyone has any ideas what could be happening (or things they would like me to try), I'm all ears. We really would like to move to a current Eigen version!


Best regards

Daniel Vollmer

--------------------------
Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
German Aerospace Center
Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany

Daniel Vollmer | AS C²A²S²E
www.DLR.de

________________________________________
From: Christoph Hertzberg <***@informatik.uni-bremen.de>
Sent: Monday, 19 April 2021 10:14:15
To: ***@lists.tuxfamily.org
Subject: [eigen] Eigen 3.4 release candidate 1!

Hello Eigen users!

We are happy to announce the release of 3.4-rc1. This is a release
candidate which is considered feature complete and only will get bug
fixes until 3.4.0 is released.
This is not yet a stable release!

We encourage everyone, especially who is currently working with a 3.3
version to try upgrading to 3.4-rc1 and report any regressions with any
compilers and architectures you are using (this includes run-time
errors, compile errors and compiler warnings).
Eigen should work with any C++ standard between C++03 and C++20, with
GCC 4.8 (or later), Clang 3.3 (or later), MSVC 2012 (or later), and
recent versions of CUDA, HIP, SYCL, on any target platform. If enabled
by the compiler this includes SIMD vectorization for SSE/AVX/AVX512,
AltiVec, MSA, NEON, SVE, ZVector.

To publish test results, you can run the unit tests as described here:
[https://eigen.tuxfamily.org/index.php?title=Tests]
Please report issues until April 25th, or tell us if you are still in
the process of testing.


The 3.4 release will be the last Eigen version with C++03 support.
Support of the 3.3 branch may soon be stopped.

The next major version will certainly also stop supporting some older
compiler versions.


Regarding the version-numbering:
There was previously a 3.4 branch with recently was deleted again, as it
was done prematurely and not properly kept up-to-date.
Unfortunately, this means that the version number (specified in
Eigen/src/Core/util/Macros.h) had to be reset to 3.3.91 (the final 3.4
release will have version 3.4.0). Version test macros will work
incorrectly with any commit from master between 2021-02-17 and today. We
apologize for any inconvenience this may cause.


Cheers,
Christoph





--
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.: [phone]
Zentrale: [phone]
E-Mail: ***@dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-------------------------------------------------------------
Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
Trippstadter Straße 122, D-67663 Kaiserslautern, Germany

Geschäftsführung:
Prof. Dr. Antonio Krüger

Vorsitzender des Aufsichtsrats:
Dr. Gabriël Clemens
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------

[Rasmus Munk Larsen]

Hi Daniel,

Thanks a lot for the update and your continued help with this!

Rasmus

On Fri, Apr 23, 2021 at 3:23 AM <***@dlr.de> wrote:
>
> Hello,
>
> after a lot of measuring, profiling, and digging a small update:
>
> The Closure benchmark slow-down has been reported with a repo as https://gitlab.com/libeigen/eigen/-/issues/2225 .
>
> Interestingly, this slow-down also seems to affect the cases where we're mainly working with vectors / matrices of AutoDiffScalar<Dynamic Matrix with large in-line storage>, see for example the differences of Jac/FV/RANSSAneg for "clang 3.4-587a6915" vs "clang 3.4-587a6915 EIGEN_UNALIGNED_VECTORIZE=0". So this probably isn't just due to the compiler being able to keep stuff in registers more (as the AutoDiffScalars are way too large for that anyway).
>
> One large problem that causes a big discrepancy in the Jac/ tests was naive copying of (unused) storage for dynamically sized storage, reported as https://gitlab.com/libeigen/eigen/-/issues/2229 and already fixed. As you can see, the fix improves performance for the Jac/ tests a lot. Thank you!
>
> Some cases are still a fair bit worse (Res/FV/Euler, Res/FV/RANSSAneg, Res/DG/Euler, Jac/FV/NavierStokes) but overall it's not looking as bad as it used to. :)
>
> I'm still investigating some crashes when using 3.4 (which are not there with 3.2) but I cannot yet say whether that is a problem in Eigen 3.4 or somewhere else.
>
>
>
> Best regards
>
> Daniel Vollmer
>
> --------------------------
> Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
> German Aerospace Center
> Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany
>
> Daniel Vollmer | AS C²A²S²E
> www.DLR.de
>
> ________________________________________
> From: ***@dlr.de <***@dlr.de>
> Sent: Monday, 19 April 2021 16:27:51
> To: ***@lists.tuxfamily.org
> Subject: Re: [eigen] Eigen 3.4 release candidate 1!
>
> Hello all,
>
> I've compiled our CFD Code with Eigen 3.4-rc1 and ran a few benchmarks relative to Eigen 3.2.9.
>
> Unfortunately, I'm seeing the negative performance impact introduced by Eigen 3.3 continue to exist (which is why we're still hanging on to the 3.2 branch).
>
> I've compiled our code with Eigen 3.2.9 as well as 3.4-rc1 with both clang and gcc, on a macOS x86-64 system (Big Sur) with the following CPU feature flags
> machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 FMA CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC MOVBE POPCNT AES PCID XSAVE OSXSAVE SEGLIM64 TSCTMR AVX1.0 RDRAND F16C
> machdep.cpu.leaf7_features: RDWRFSGS TSC_THREAD_OFFSET BMI1 AVX2 FDPEO SMEP BMI2 ERMS INVPCID PQM FPU_CSDS MPX PQE AVX512F AVX512DQ RDSEED ADX SMAP CLFSOPT CLWB IPT AVX512CD AVX512BW AVX512VL PKU AVX512VNNI MDCLEAR IBRS STIBP L1DF ACAPMSR SSBD
>
> Compilation settings were: -std=c++17 -fopenmp -Ofast -march=native -fno-finite-math-only -DEIGEN_DONT_PARALLELIZE=1
> (we split our work up among threads ourselves, but the benchmarks are single-threaded anyway).
>
> The clang version was homebrew's llvm: stable 11.1.0 (bottled); gcc was homebrew's gcc: stable 10.2.0 (bottled).
>
> We're using Eigen for small, fixed-size vectors and occasionally matrices of doubles (of varying lengths, e.g. 5, 6, 7, 8, 13, ...), mainly accessing individual elements, or fixed-size (length 3) segments at compile-time known offsets (indices). Occasionally, we also have matrix-vector products of these, but they probably play a smaller role. These are the "Res" (Residual computation) benchmarks, where we do this over a whole mesh with multiple loops, gradient computations, ...
>
> Then we do the same thing but use Eigen's (unsupported) AutoDiffScalar using a fairly big fixed-max-size (e.g. when our PDE has 6 state variables, then AutoDiffScalar has Eigen::Dynamic derivatives with a max-size of 6 * 24 + 1). These types are quite large, but it's still faster than fully dynamic heap allocation. These are the "Jac" (Jacobian computation) benchmarks, which otherwise largely mimic the "Res" benchmarks.
>
> https://www.maven.de/stuff/coda_benchmarks_eigen.pdf
>
> In these graphs everything is relative to the clang Eigen 3.2.9 baseline being 1.0. Higher numbers are faster (2.0 would be twice as fast as the clang Eigen 3.2.9 using build).
>
> The first two benchmarks (Closure/...) are actual micro-benchmarks. In the first one, we have an input vector with 6 doubles, and from that compute a vector with 13 doubles (the first six are the same as the input, and the remaining 7 are derived values computed from those input values). The 2nd version also augments gradients, which means it also has input gradients (Matrix<Matrix<double, 3, 1>, 6, 1>) and outputs augmented gradients (Matrix<Matrix<double, 3, 1>, 13, 1>).
>
> The next set of benchmarks is the residual computation (which performs multiple loops over a mesh with various computations). One (small) part of this is the Closure-stuff from the first two benchmarks.
>
> The final set is the computation / approximation of the derivative using AutoDiffScalar instead of double on a local level.
>
> For these benchmarks (Res and Jac), the sizes of the vectors & matrices roughly increases for each set of equations (Euler <= NavierStokes < RANSSAneg < ...).
>
> For the first microbenchmark Closure/AugmentGF we seem to be hitting a pathological case in the partial vectorization as disabling that seems to fix the problem. The input vector contains 6 double, the output 13. Remember this mainly uses individual values or segment<3> access to the momentum-sub-vector.
>
> The bigger "Res" benchmarks are generally a bit slower (even though not majorly so), but more so with gcc.
>
> The even bigger "Jac" benchmarks do see big slow-downs (performance 0.7 down do 0.3), which seem to get worse as we include more (and larger) AutoDiffScalars. We didn't see this relative decrease for the otherwise roughly similar "Res" benchmarks, so something seems to be strange there (either in AutoDiffScalar, or in the use of custom scalar types itself). I'm wondering whether some Eigen internal operations may accidentally (or purposely) create more (temporary) copies of scalars, which for a custom type might be costly...
>
>
> Unfortunately providing minimized, self-contained reproducers exhibiting the same behavior is quite difficult... :(
>
> I will try to work on figuring out a reproducer for the first microbenchmark where partial vectorization has a negative effect.
>
>
> If anyone has any ideas what could be happening (or things they would like me to try), I'm all ears. We really would like to move to a current Eigen version!
>
>
> Best regards
>
> Daniel Vollmer
>
> --------------------------
> Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR)
> German Aerospace Center
> Institute of Aerodynamics and Flow Technology | Lilienthalplatz 7 | 38108 Braunschweig | Germany
>
> Daniel Vollmer | AS C²A²S²E
> www.DLR.de
>
> ________________________________________
> From: Christoph Hertzberg <***@informatik.uni-bremen.de>
> Sent: Monday, 19 April 2021 10:14:15
> To: ***@lists.tuxfamily.org
> Subject: [eigen] Eigen 3.4 release candidate 1!
>
> Hello Eigen users!
>
> We are happy to announce the release of 3.4-rc1. This is a release
> candidate which is considered feature complete and only will get bug
> fixes until 3.4.0 is released.
> This is not yet a stable release!
>
> We encourage everyone, especially who is currently working with a 3.3
> version to try upgrading to 3.4-rc1 and report any regressions with any
> compilers and architectures you are using (this includes run-time
> errors, compile errors and compiler warnings).
> Eigen should work with any C++ standard between C++03 and C++20, with
> GCC 4.8 (or later), Clang 3.3 (or later), MSVC 2012 (or later), and
> recent versions of CUDA, HIP, SYCL, on any target platform. If enabled
> by the compiler this includes SIMD vectorization for SSE/AVX/AVX512,
> AltiVec, MSA, NEON, SVE, ZVector.
>
> To publish test results, you can run the unit tests as described here:
> [https://eigen.tuxfamily.org/index.php?title=Tests]
> Please report issues until April 25th, or tell us if you are still in
> the process of testing.
>
>
> The 3.4 release will be the last Eigen version with C++03 support.
> Support of the 3.3 branch may soon be stopped.
>
> The next major version will certainly also stop supporting some older
> compiler versions.
>
>
> Regarding the version-numbering:
> There was previously a 3.4 branch with recently was deleted again, as it
> was done prematurely and not properly kept up-to-date.
> Unfortunately, this means that the version number (specified in
> Eigen/src/Core/util/Macros.h) had to be reset to 3.3.91 (the final 3.4
> release will have version 3.4.0). Version test macros will work
> incorrectly with any commit from master between 2021-02-17 and today. We
> apologize for any inconvenience this may cause.
>
>
> Cheers,
> Christoph
>
>
>
>
>
> --
> 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.: [phone]
> Zentrale: [phone]
> E-Mail: ***@dfki.de
>
> Weitere Informationen: http://www.dfki.de/robotik
> -------------------------------------------------------------
> Deutsches Forschungszentrum für Künstliche Intelligenz GmbH
> Trippstadter Straße 122, D-67663 Kaiserslautern, Germany
>
> Geschäftsführung:
> Prof. Dr. Antonio Krüger
>
> Vorsitzender des Aufsichtsrats:
> Dr. Gabriël Clemens
> Amtsgericht Kaiserslautern, HRB 2313
> -------------------------------------------------------------
>
>

[Rob McDonald]

I'm trying 3.4 rc1 on my program. Everything seems to work fine on Windows
and MacOS. However, there seems to be some sort of conflict when I try to
build on Linux.

We are currently using 3.3.7 and everything works fine. I suppose I could
try 3.3.9 if that would be helpful.

The problems only crop up in the graphics part of my program (which does
not use Eigen intensively, it just gets included relatively incidentally).
My program can also be compiled in a non-graphical version (no GUI, OpenGL,
or XWindows libraries allowed at all) - and that works fine. I use FLTK as
a cross-platform GUI library. The most significant difference on Linux is
the use of X Windows.

I've attached the gcc error log from trying to compile one file -- sorry,
it is 884 lines long...

My gut says something is getting #defined that then gives Eigen fits.
However, I can't find anything that looks wrong in the code the messages
are pointing to.

Any help tracking this down will be very much appreciated.

Rob

[Antonio Sanchez]

My best guess is that somewhere there is a

#define Status int

somewhere in your code, which is then conflicting with the enum value
"Status = 3", which is being converted to "int = 3" by the preprocessor.

You may need to undef it before including Eigen.

On Tue, Apr 20, 2021 at 10:48 PM Rob McDonald <***@gmail.com>
wrote:

> I'm trying 3.4 rc1 on my program. Everything seems to work fine on
> Windows and MacOS. However, there seems to be some sort of conflict when I
> try to build on Linux.
>
> We are currently using 3.3.7 and everything works fine. I suppose I could
> try 3.3.9 if that would be helpful.
>
> The problems only crop up in the graphics part of my program (which does
> not use Eigen intensively, it just gets included relatively incidentally).
> My program can also be compiled in a non-graphical version (no GUI, OpenGL,
> or XWindows libraries allowed at all) - and that works fine. I use FLTK as
> a cross-platform GUI library. The most significant difference on Linux is
> the use of X Windows.
>
> I've attached the gcc error log from trying to compile one file -- sorry,
> it is 884 lines long...
>
> My gut says something is getting #defined that then gives Eigen fits.
> However, I can't find anything that looks wrong in the code the messages
> are pointing to.
>
> Any help tracking this down will be very much appreciated.
>
> Rob
>
>
>
>
>

[Dijk, Jan van]

Dear Antonio, Rob,

Indeed, Xwindows.h (on my OpenSuSE system) has a #define Status int

It seems reasonable to solve this the same as issue 253: let Eigen produce an understandable #error if Status is already defined. See https://gitlab.com/libeigen/eigen/-/issues/253

Regards, Jan.

________________________________________
From: Antonio Sanchez <***@google.com>
Sent: Wednesday, April 21, 2021 5:13 PM
To: ***@lists.tuxfamily.org
Subject: Re: [eigen] Problem with 3.4 rc1

My best guess is that somewhere there is a

#define Status int

somewhere in your code, which is then conflicting with the enum value "Status = 3", which is being converted to "int = 3" by the preprocessor.

You may need to undef it before including Eigen.

On Tue, Apr 20, 2021 at 10:48 PM Rob McDonald <***@gmail.com<mailto:***@gmail.com>> wrote:
I'm trying 3.4 rc1 on my program. Everything seems to work fine on Windows and MacOS. However, there seems to be some sort of conflict when I try to build on Linux.

We are currently using 3.3.7 and everything works fine. I suppose I could try 3.3.9 if that would be helpful.

The problems only crop up in the graphics part of my program (which does not use Eigen intensively, it just gets included relatively incidentally). My program can also be compiled in a non-graphical version (no GUI, OpenGL, or XWindows libraries allowed at all) - and that works fine. I use FLTK as a cross-platform GUI library. The most significant difference on Linux is the use of X Windows.

I've attached the gcc error log from trying to compile one file -- sorry, it is 884 lines long...

My gut says something is getting #defined that then gives Eigen fits. However, I can't find anything that looks wrong in the code the messages are pointing to.

Any help tracking this down will be very much appreciated.

Rob

[Rob McDonald]

Thanks Antonio and Jan,

I have already hit the #define Success problem sometime in the past -- so I
was able to #undef Status in the same place and everything is working fine
now.

In addition to a better error message (which may be out of your control),
perhaps Eigen could add a simple test program in the unit tests that builds
against XWindows (as it seems to be a huge offender) -- and perhaps a page
of documentation about working with XWindows to help resolve these problems.

Thanks for everything,

Rob


On Wed, Apr 21, 2021 at 8:41 AM Dijk, Jan van <***@tue.nl> wrote:

> Dear Antonio, Rob,
>
> Indeed, Xwindows.h (on my OpenSuSE system) has a #define Status int
>
> It seems reasonable to solve this the same as issue 253: let Eigen produce
> an understandable #error if Status is already defined. See
> https://gitlab.com/libeigen/eigen/-/issues/253
>
> Regards, Jan.
>
> ________________________________________
> From: Antonio Sanchez <***@google.com>
> Sent: Wednesday, April 21, 2021 5:13 PM
> To: ***@lists.tuxfamily.org
> Subject: Re: [eigen] Problem with 3.4 rc1
>
> My best guess is that somewhere there is a
>
> #define Status int
>
> somewhere in your code, which is then conflicting with the enum value
> "Status = 3", which is being converted to "int = 3" by the preprocessor.
>
> You may need to undef it before including Eigen.
>
> On Tue, Apr 20, 2021 at 10:48 PM Rob McDonald <***@gmail.com
> <mailto:***@gmail.com>> wrote:
> I'm trying 3.4 rc1 on my program. Everything seems to work fine on
> Windows and MacOS. However, there seems to be some sort of conflict when I
> try to build on Linux.
>
> We are currently using 3.3.7 and everything works fine. I suppose I could
> try 3.3.9 if that would be helpful.
>
> The problems only crop up in the graphics part of my program (which does
> not use Eigen intensively, it just gets included relatively incidentally).
> My program can also be compiled in a non-graphical version (no GUI, OpenGL,
> or XWindows libraries allowed at all) - and that works fine. I use FLTK as
> a cross-platform GUI library. The most significant difference on Linux is
> the use of X Windows.
>
> I've attached the gcc error log from trying to compile one file -- sorry,
> it is 884 lines long...
>
> My gut says something is getting #defined that then gives Eigen fits.
> However, I can't find anything that looks wrong in the code the messages
> are pointing to.
>
> Any help tracking this down will be very much appreciated.
>
> Rob
>
>
>
>
>
>
>