Hi William, enabling C++11 will not decrease performance but will likely increase it in some cases (e.g. due to move semantics).
GCC 4.8 supports almost all C++11 features as you can see here: https://gcc.gnu.org/gcc-4.8/cxx0x_status.html <https://gcc.gnu.org/gcc-4.8/cxx0x_status.html> For further information make sure to check this page: https://gcc.gnu.org/projects/cxx-status.html#cxx11 <https://gcc.gnu.org/projects/cxx-status.html#cxx11> Cheers, David > On 15. Mar 2019, at 16:56, William Tambellini <[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]> > 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 > >> <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 > <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/ > <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 > > <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 > <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/0JYxv2ScOhHGX2PQPOmvUg5_3elP1qzzbnG4d_r1EP0iIm7trXtadBT4t_0XItBgMEtsjCueQ7weq4Nrivo6iw==> > to report this email as spam.
