RE: [eigen] About dropping C++03 compatibility

[<Daniel.Vollmer@xxxxxx>]

Hi Michael,

> I have to admit I do not understand conservativism around moving a
> codebase along with the times. As someone else said before in this
> thread, older releases do not magically disappear! Anyone can still
> use them.

Let me try to explain:

We (occasionally) write scientific software that runs on HPC clusters (and is often distributed in source form). It has dependencies which we don't necessarily control. We may have to use buggy vendor compilers, which we cannot "just" upgrade (they were sold and validated for the system they're on).

I am still hesitant to move from Eigen 3.2.x to Eigen 3.3.x due to performance regressions (which have been improved upon by point releases, but are still present – and are very difficult to locate / boil down to a simple repo). I'd love the features (and bug-fixes) of 3.3!

And still, we would like support a version Eigen that supports the newest vector extensions etc., and not be stuck on SSE2 (for example).

(Note: I also hear the other arguments for more aggressive upkeep of the code-base, but just tried to explain the perspective we find ourselves in).


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

________________________________________
Von: Michael Hofmann [kmhofmann@xxxxxxxxx]
Gesendet: Mittwoch, 20. Februar 2019 8:04
An: eigen@xxxxxxxxxxxxxxxxxxx
Betreff: Re: [eigen] About dropping C++03 compatibility

On Wed, Feb 20, 2019 at 12:13 AM David Tellenbach
<david.tellenbach@xxxxxxxxxxxxx> wrote:
> Sure, newer features could improve some internal parts but excluding
> users for fancier internals is most likely a bad idea.

This seems not very progressive to me. It's not only about the user's
perspective, but also think of a developer's perspective.

If you want a motivated base of people *maintaining and contributing
to* Eigen, by all means, get the Eigen codebase modernized and greatly
simplified in the progress! It makes a big difference.
And it does seem to me that Eigen could use a more active community
working on it. My personal impression of Eigen certainly has changed a
bit in the last few years, as these obvious modernization tasks are
not even attempted.

I have to admit I do not understand conservativism around moving a
codebase along with the times. As someone else said before in this
thread, older releases do not magically disappear! Anyone can still
use them.
Without having data to back this up, I'm pretty sure that the poor
users who are stuck with a pre-C++11 compiler don't actually care too
much about new features in Eigen. Maybe the occasional bug fix.
They're probably not even moving the version along, either because
they already can't for so many other libraries, or because they
operate in an overly conservative development environment.
And how much of the user base would actually be affected by a move to,
say, C++14 in the first place? 2%? 5%? Maybe a few more for a move to
C++17, which I'd recommend, but again, older releases do not
disappear.

Regarding the user's perspective, I share the concerns that Patrik mentioned.

Regards,
Michael

On Wed, Feb 20, 2019 at 1:35 AM Jason Newton <nevion@xxxxxxxxx> wrote:
>
> Last time I talked on the ML about c++03 and < c++11 was that it had to be supported for a long time because it was being used.  I haven't had to care about older than c++11 for maybe 8 years now (I'm lucky).  And even for c++11 as a reference point, it's now mostly 14 even when people say 11.
>
> Between c++11 and c++14 vs older, 14 was such a modest and boring small increment change that it didn't really bring in any new problems like 11 (instead it fixed some of the little annoyances that didn't make the deadline for 11) and people running "ahead" on 11 don't seem to mind re-targeting 14..  Overall I'd just recommend shoot for 14 as a taraget rather than 11 and not striving to support all spectrum of c++ releases unless there's demand (I'm thinking there isn't ) and resources for it (I'm also thinking there isn't.).
>
> -Jason
>
> On Tue, Feb 19, 2019 at 1:55 PM Gael Guennebaud <gael.guennebaud@xxxxxxxxx> wrote:
>>
>>
>> I was rather thinking about upgrading to C++11/14 while keeping API compatibility with 3.4, so that would be for Eigen 3.5. Moving to c++17 only is definitely not option, but C++14 seems doable to me. C++14 is required if we want to properly handle scalar types with expression template.
>>
>> A key question is rather how many users will still be stuck to C++03 by the time of 3.5, say 2021? There are more than 700 members on this list, so we should quickly know if the ratio is larger or lower than ~0.1%. For a more thorough measure, we could make a little survey while releasing 3.4.
>>
>> Gaël.
>>
>> On Tue, Feb 19, 2019 at 7:26 PM Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>>>
>>> Hi!
>>>
>>> About Eigen 4.0, there are currently no plans nor anything remotely like
>>> a schedule for that. All we currently have is a meta-bug to collect API
>>> changes which we don't want to do for 3.x:
>>> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=4.0
>>> So any decision on which standard we want to require for 4.0 is very
>>> hypothetical at the moment (by that time C++17 could be completely
>>> outdated).
>>>
>>>
>>> Regarding 3.4/3.5/...
>>> Increasing the required standard to compile Eigen could simplify
>>> maintenance in the long run, but will not have any measurable impact for
>>> users of Eigen (except *maybe* better compile times, although several
>>> new features will more likely increase compile times).
>>> We already have one module (the Tensor module) which mostly depends on
>>> C++11, i.e., development in there can use "modern" (only 8 year old,
>>> instead of 20 year old ^^) C++. If, in the future, we add further new
>>> modules which are unreasonably complicated to implement without
>>> C++14/17/... we can of course make them require that standard.
>>>
>>> But, at the moment, increasing the minimal standard for Eigen 3.4 would
>>> essentially mean that we'd need to maintain Eigen 3.3 in parallel to
>>> Eigen 3.4 or lose several users that still don't have reliable C++11
>>> support. Also, so far we (almost) only backported bugfixes to 3.3 and
>>> introduced new features only to the development branch (that is kind of
>>> the idea of a stable branch). But there should be no need to exclude
>>> "old" users from new features (if implementing the feature does not
>>> require more than C++03).
>>>
>>>
>>> Cheers,
>>> Christoph
>>>
>>>
>>> On 19/02/2019 18.41, Michael Hofmann wrote:
>>> > Indeed, I completely agree that it's time to bring Eigen into the
>>> > second half of the 2010s.
>>> >
>>> > Quoting Patrik Huber:
>>> >> (...) in my opinion it would be a real back-step if the "hypothetical" Eigen 4 was stuck on C++11. I would very strongly argue to at least make the step to full C++14 and potentially C++17.
>>> >
>>> > I share the opinion that for another major release (Eigen 4), there
>>> > should be a considerable leap in required C++ standard, and I argue
>>> > this should be C++17.
>>> > Eigen 3.4 will of course still be C++03 compatible, and remain
>>> > available! So I do not see any concerns related to making a bigger
>>> > leap.
>>> > Requiring C++14 should be the minimum for a new major version, but
>>> > staying there feels a bit stagnant to me, given that it's 2019 and
>>> > C++20 is well on the horizon.
>>> >
>>> > Why C++17? Like another poster before me, I strongly suspect that a
>>> > lot of code can be considerably simplified by judicious use of 'if
>>> > constexpr'. Both C++14 and 17 have brought improvements in handling
>>> > aligned memory, so some of the Eigen macros will likely not be needed
>>> > anymore. Variable templates (i.e. sth. like is_same_v<>) can help
>>> > unclutter a lot of Eigen and user code (removing the need for
>>> > 'typename .....::type' in many places). I am quite sure there will be
>>> > good use cases for fold expressions in Eigen.
>>> > And so on. In my experience, C++ is a noticeable improvement over
>>> > C++14 for library writers. I would not want to go back, and I'm
>>> > expecting more and more libraries to follow suit these days, to stay
>>> > relevant and well maintained.
>>> >
>>> > C++17 is well supported by Clang 5+, GCC8+ (many features already in
>>> > GCC7), and VS2017. A fewexceptions still apply, like std::pmr, or
>>> > parallel STL, which are expected soon in GCC9/Clang 8. There shouldn't
>>> > be any ABI changes in implementation between C++11 and 17, so "getting
>>> > the entire ecosystem recompiled", a previously expressed concern,
>>> > should not be necessary.
>>> >
>>> > Regards,
>>> > Michael
>>> >
>>> > On Tue, Feb 19, 2019 at 3:23 PM Peter <list@xxxxxxxxxxxxxxxxx> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >>
>>> >> Am 19.02.19 um 14:58 schrieb Gael Guennebaud:> Hi,
>>> >>   >
>>> >>   > this a follow-up of another thread that deviated towards the question of what should be the minimal c++ version required for future Eigen's version.
>>> >>   >
>>> >>   > Just to be clear, the 3.4 version will be fully compatible with C++03, while exposing/taking-advantage-of a few C++11, C++14, and even C++17 features when available.
>>> >>   >
>>> >>   > There is, however, a limit in conditionally enabling features based on the available c++ version, and maintaining multiple variants is out of reach for us.
>>> >>   >
>>> >>   > Moreover, switching to c++11 or even 14 would help *a lot* in day-to-days Eigen coding with many opportunities to simplify the code base, logics, compilation-times, unit-testing, etc.
>>> >>
>>> >> I would vote for C++14 for a 4.x release.
>>> >> In my opinion it's a good reason to switch if that helps to speed up Eigen's code development.
>>> >>
>>> >> Switching to C++14 for a 4.x release won't magically destroy the 3.4 release.
>>> >> Projects which depend on older infra structure (e.g. some HPC platforms tend to be
>>> >> rather out-dated) can still use the 3.4 release.
>>> >>
>>> >>
>>> >> Best regards,
>>> >> Peter
>>> >>
>>> >>
>>> >>
>>> >>
>>> >
>>> >
>>> >
>>>
>>> --
>>>   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 für Künstliche Intelligenz GmbH
>>>    Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany
>>>
>>>    Geschäftsführung:
>>>    Prof. Dr. Jana Koehler (Vorsitzende)
>>>    Dr. Walter Olthoff
>>>
>>>    Vorsitzender des Aufsichtsrats:
>>>    Prof. Dr. h.c. Hans A. Aukes
>>>    Amtsgericht Kaiserslautern, HRB 2313
>>>    -------------------------------------------------------------
>>>
>>>
>>>