Hi all, I'm a quite sad to see this post got no replies. I can only add that I fully agree and think along the very same lines. I would love to see Eigen move forward, move to C++14 in the 3.5 release, and drop the old cruft. It's 2020 now, 6 years after C++14.
Best wishes, Patrik On Wed, 8 Apr 2020 at 17:20, Martin Beeger <[email protected]> wrote: > Hallo! > > This is continuation of the discussion from last year about > compatibility, but I wanted to bring it up again, because I have some > new data from my experience. > > Our company uses Eigen extensively and has a larger ecosystem built on > it, as do many of the voices on this list. We are in the embedded world, > so we are often hindered to adapt quickly to new tools, very much like > the HPC community has been. > But we managed to move to C++14 with our codebase in 2019. When doing > that, we somewhat monitored performance and compile time during the > adaption. > > When we starting compiling our C++98 codebase as is with C+14, > performance already went up slightly. C++14 does silently move or elide > copies, and modern compiler have better optimizers, and the quality of > implementation of STL types got better. So if you are at all bound by > performance of STL types, I would really recommend using a new compiler > in C++14 mode even with your old code. > > This was the obvious part. Another part was less obvious. We profiled > compile time, which didn't change much after the switch and started to > look into stuff which was expensive to compile. And then selectively in > places, where the compile time was bad we simplified the code using > C++14 features to improve compile time. This allowed us with very > localized changes to cut our compile time by almost in half, while, at > the same time, making the code in question often a lot simpler and new > features (e.g. for performance improvements) easier to implement. > > This is also the experience which was observed with other template heavy > codebases like boost::mpl in comparison to hana and other stuff. The > gains in simplicity and compile time, especially from constexpr and > lambda features are not minor. They can often cut your code in half and > more than double the compile time. > > The problem is, I am at a point where its hard to do much more to > improve the compile time of my codebase significantly, because most of > the compile time is brought in by 2 libraries: boost.test and Eigen. We > will most likely at some point abandon boost.test due to this, like many > others have already (which slowed the development and improvement of > boost.test further, while the alternatives got better and getting into > this downwards spiral). I would be vary happy if I am not forced to > abandon Eigen after the great 10 years we had with this library. In > order to avoid this I pulled a lot of tricks like explicit template > instatiations, tricks to reduce includes, even pimpl-like encapsulation > at performance cost to isolate from the problem, but that gets you only > so far. > > I may well be that my use case is special, but I strongly assume that > new users which today want to adopt Eigen and have to look into its > internals (as you inevitable need to do at some points), will see how > its written and quickly run for alternatives. This amount of macros, > boilerplate and similar stuff will be an argument against this great > library some day and this day may already have come. > > The important part is here: Eigen compile time and internal expression > template engine code readability it was great by 2010s standards, it was > ok by 2015 standards, it is borderline by 2020 standards, and unless > something changes, it will be unacceptable by 2025 standards, unless the > Eigen library moves along. > > As C++ users, we do care about backwards compatibility greatly and that > is even good for me, but we should not go the C way and care about too > ancient compilers. The C++ comittee doesn't (that why int is required to > be 2s complement in C++20), so Eigen library maintainers IMHO should > follow. > > What are the chances to get Eigen 3.4 out of the door with C++98 support > and drop it on the devel branch afterwards and jump to C++14? > What is the Eigen promises about how old yours compilers may be? > Can we explicitly agree on a statement like: We vow to support up to 3 > year old compilers (or 5 years)? > > If we could agree on clear and conservative rules like we will go 3 > years back or 5 years back and state these on the Eigen front page, > Eigen user may look at our codebase and be much more willing to accept > older standards code, knowing that it will improve over time and that > the user gets some useful guarantees about the future in return. > There is agrument to be made that if you use a 5+ years old compiler, > you really do not care about performance, something Eigen uses generally > care about. So you are not in a targeted user group of Eigen. Little HPC > clusters do not at all offer any way to install a more recent compilers > that 5 years (this has changed a lot from a decade ago) and even in the > embedded world, vendors tend to drop support or upgrade for platforms > with more than 5 years old toolchains too (this has also very much > changed from 10 years ago). > > Eigen users should be able to get a clear answer on the question when we > drop C++98 (of if). That belongs on the front page IMHO. > > Kind regards, > Martin > > > > > > > > >
