> 1 - There is absolutely no reason to assume it would. There is indeed in theory no reason to expect any speed drop but in practice the "cleanup" could just simply generate some bugs/regressions.
> 2 - By all means, let's confidently move into the future (or rather present: > C++17). I would be much more pragmatic : "let's safely move into the present: at least C++11 : in the industry, the minimum standard is today C++11, perhaps C++14 but not at all C++17. Kind WT. ________________________________ From: Michael Hofmann <[email protected]> Sent: Friday, March 15, 2019 10:19 AM To: [email protected] Subject: Re: [eigen] About dropping C++03 compatibility 1 - There is absolutely no reason to assume it would. 2 - I would be *very* unhappy happy if Eigen did try to keep support for such ancient compilers for any new major release. By all means, let's confidently move into the future (or rather present: C++17). As already mentioned, existing releases can still be used with such old toolchains. Also, it's not difficult to install a recent compiler. Best, Michael On Fri, Mar 15, 2019, 4:57 PM William Tambellini <[email protected]<mailto:[email protected]>> wrote: I would nt mind eigen to move to C++11 but just to check : 1- it would nt imply any perf drop ? 2- it would keep compatibility with the default centos7 gcc aka gcc 4.8.5 ? W. ________________________________ From: Rasmus Munk Larsen <[email protected]<mailto:[email protected]>> Sent: Friday, February 22, 2019 11:18:26 AM To: eigen Subject: Re: [eigen] About dropping C++03 compatibility BTW: Regarding language standards, we at Google would be ecstatic if Eigen moved to c++11 or beyond. On Wed, Feb 20, 2019 at 11:11 AM Rasmus Munk Larsen <[email protected]<mailto:[email protected]>> wrote: On Wed, Feb 20, 2019 at 10:39 AM Patrik Huber <[email protected]<mailto:[email protected]>> wrote: Hi Gael / all, >> this is off topic but with c++17 and gcc 7+ or clang 7+ and the head of >> Eigen, it was already possible to get rid of EIGEN_MAKE_ALIGNED_OPERATOR_NEW >> in user code. >> As of today, this is also conditionally removed from Eigen's classes and, >> more importantly, documented: >> http://eigen.tuxfamily.org/dox-devel/group__TopicUnalignedArrayAssert.html That's awesome! Thank you a lot for this, that's a great change and a serious gotcha removed from Eigen. >> Recall that Eigen is developed on spare time. I apologise, I think that my sentence in the parentheses came across wrong and you may have misunderstood my intention. I understand Eigen is mainly developed in people's spare time and I am very grateful to everyone. What I meant was what Christoph said, that I thought I should get emails from the bugtracker if I'm on the CC list, but I haven't received those automated update emails from the bugtracker. Now that Christoph mentioned it again, I remember I actually logged this bug last year (http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1640) and it is indeed misconfigured SPF (which would affect not only gmail but all/most spam filters, gmail just seems more aggressive). Indeed I found those emails in the Spam folder, thanks Christoph for reminding me. On the note of developing/contributing to Eigen, I wholeheartedly agree with what Michael said earlier in this thread. More people might be inclined to contribute to Eigen, if the project moves forward a bit instead of keeping tons of old cruft. Agree with Christoph that Eigen will always be complex code, but there's different levels of complex. I would actually be quite a bit concerned about the future / long-term survival of Eigen. How many people are significantly and actively contributing? I can only name Gael and Christoph (the bitbucket commit log shows a few others but with rather small commits, focused on some specific areas). So the "truck factor" of Eigen might pretty much be 2? Which is quite concerning, given that Eigen very likely powers a very significant portion of today's world, from AI, robots, to possibly things like space travel or even nuclear power plants. I wonder why there's not more of the big companies allowing employees to dedicate some of their paid work time to Eigen. Just for the record: I work for Google, in the TensorFlow team, and part of my job is to help maintain Eigen and the many many (literally millions) of build targets that depend on it across the Alphabet companies. As you say, Eigen is used widely for AI, machine learning, mobile, AR/VR, robotics, signal processing etc. and really in most places where numerical computation in C++ is needed. We are very grateful for the efforts of the Eigen maintainers and the community and are committed to continue our support for a free and open Eigen library. Anyway, moving to C++14/17 will certainly not suddenly improve all that but I can only say I so much agree with what Michael said. With regards to C++ standards usage / survey, the JetBrains developer survey might be interesting too: https://www.jetbrains.com/research/devecosystem-2018/cpp/ It's from Jan 2018, so the numbers are a bit dated now, but the 2019 survey should come out in a few weeks or so I guess. And I think doing our own small survey would be a great idea. Best, Patrik On Wed, 20 Feb 2019 at 16:58, Gael Guennebaud <[email protected]<mailto:[email protected]>> wrote: On Wed, Feb 20, 2019 at 3:52 PM Christoph Hertzberg <[email protected]<mailto:[email protected]>> wrote: On 20/02/2019 08.04, Michael Hofmann wrote: > [...] > > 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. "Simplifying" the codebase by using C++14/17 would for many parts essentially mean to rewrite them --> _May_ save work in the long run, but not feasible or worth the effort for now. Large parts of Eigen are complicated regardless of the standard we use. without rewriting everything, many new features, bug fixes and improvements could have been implemented much more rapidly if c++11/14 could be used without bothering about c++03. #if CXX11 guards are perfectly fine when the goal is to expose a specific feature that only exist with CPP11 and that does not interact with the rest of Eigen's code base. But for all other cases #if guards just make everything even more complicated. Just one example, look at this mess: https://bitbucket.org/eigen/eigen/src/fed0f93f7118b9eae028c9342ed5e3d7a735b17f/Eigen/src/Core/ArithmeticSequence.h#lines-17 and after moving to C++14: https://pastebin.com/KWNfzdXJ<http://webdefence.global.blackspider.com/urlwrap/?q=AXicY2Rm8FrCwHB9AQNDUU6lkVmiXnFRmV5uYmZOcn5eSVF-jl5yfi5DhaGvl1ehpYuBgamhoRlDeUliblJqTk5mXqZDcQpESUZJSUGxlb5-QWJxSWpSZh5IUN873C-tKiXCi4GBoXMKAwMAhsojLw&Z> Believe me, I really don't want to make any additional change to ArithmeticSequence without cleaning it first! > 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. It is also an issue of having to maintain code bases which largely diverged. Currently, many bug fixes can simply be grafted to the 3.3 branch. yes, that's a real concerns I had too. So let's make 3.4 super robust ;) > Without having data to back this up, [...] Perhaps we should conduct some kind of survey about * Which Eigen versions are currently used (3.1??, 3.2, 3.3, default) * What CPU/OS/Compiler/C++-standard/... * What modules of Eigen/what kind of problems/... * Most concerning issues/wanted features/... * ... Anyone willing to collect questions and set this up? (Maybe start brainstorming questions in a new mail-thread) It would be very nice if someone would set this up! I'd advise to keep the survey as short as possible with a focus on questions for which we really have no clue and of interest for the evolution of Eigen. For instance, the results on CPU/OS are very predictable and of little use IMO. On the other hand the compiler versions and maximal c++ versions (today and expected within, say, 3 years) are of utmost importance. gael. 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.: +49 421 178 45-4021 Zentrale: +49 421 178 45-0 E-Mail: [email protected]<mailto:[email protected]> 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 ------------------------------------------------------------- Click here<https://www.mailcontrol.com/sr/MZbqvYs5QwJvpeaetUwhCQ==> to report this email as spam.
