C++20, How Hard Could It Be • Hacker News Board

Re: C++20, How Hard Could It Be

#301

Post by MauranKilom » Sun, Sep 25, 2022, 7:29 PM UTC

f1shy wrote: post #282

Honest question, do not want to insult anybody: I've heard lots of times, that the reason why C++ sometimes is weird and complex, is because utter care is taking in maintaining backward compatibility. Sorry if I'm wrong, but I remember seeing a video about variable initialization, which showed many ways of initializing variables, and at the end, the excuse was "all because we have to maintain compatibility to C". No…

> This presentation seems to show the compatibility between most recent releases is not very good.

Half of the "features" shown in the presentation are exceedingly niche. It's just that a 20 million LOC (or however many Chrome has right now) code base is almost guaranteed to exercise every niche feature somewhere.

Having helped with C++ standard transitions of a code base half an order of magnitude smaller, the amount of issues requiring code changes was minuscule so far. You tend to have much more boring problems, like:

- "We can't use newer C++ because C++/CLI doesn't support it"

- "We can't use newer C++ in these headers because they end up included in CUDA code, and that compiler only supports C++14"

- "We have to wait for a new version of before we can lint/sanitize/profile/format our code"

- "This third-party code has the compiler up in arms now because it does questionable things"

Re: C++20, How Hard Could It Be

#302

Post by bialpio » Sun, Sep 25, 2022, 7:29 PM UTC

kwant_kiddo wrote: post #186

I started reading the link "bans everything to start with anyway" in the slides: https://chromium.googlesource.com/chromium/src/+/HEAD/styleg... And I noticed the ban of shared_ptr and . I know the use of shard_ptr should be done cautiously, but just banning it from use? How do the Chromium devs solve a problem that requires shared ownership? I guess you can come a long way with singletons and consumer/producer queue…

As for , the link you provided also has a (short) justification behind the decision: https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...

Regarding smart pointers, not sure if you also found this: https://chromium.googlesource.com/chromium/src/+/HEAD/base/m...

Re: C++20, How Hard Could It Be

#303

Post by DannyBee » Sun, Sep 25, 2022, 7:38 PM UTC

ncmncm wrote: post #95

loxias wrote: post #62

Earlier quoted context omitted.

Whoa, really? Since when?? After a lifetime of using GCC, I (like many others) moved to clang a few years ago, out of frustration with the slow development of GCC, a desire to use new C++ features, and stayed because of the superior error messages and, in my use cases anyway, superior code generation. In addition, I gather it's a much cleaner and easier to maintain code base. As a result, we get to have cool things l…

Gcc pretty consistently delivers slightly faster code.

This is often true for SPEC, but not true for real world code.

Or at least, we extensively tested this at Google, before, during, and after the move to LLVM.

On many thousands of libraries, binaries, etc, made up of hundreds of millions of lines of C++.

While there were wins and losses, on average, LLVM was a consistent net positive.

That was true despite having spent 5+ years of having a large team dedicated to doing nothing but finding places to improve performance of GCC compiled code (and contributing back patches), and doing so very successfully.

That said, as time approaches infinity, the compilers are going to generate the best code for the things that someone took the time to analyze and make the compiler better at.

There is, in the end, no magic that makes GCC better than LLVM or vice versa. The vast majority of it is tuning and improving things little by little for whatever targets someone is trying to improve.

Re: C++20, How Hard Could It Be

#304

Post by jandrewrogers » Sun, Sep 25, 2022, 7:44 PM UTC

phao wrote: post #260

synergy20 wrote: post #149

Say I have a new project to start today. I need pick a language to use: 1. a well-tested language 2. can not use garbage collector due to *performance* requirement 3. easy to hire if project expands. 4. ready to use tooling support 5. widely available tutorials and info on the web. 6. language is itself alive and updated 7. project can be scaled over time. what options do I have? I have to pick up c++ in this case. i…

I wonder how much of (2) is speculative and how much of it is a real need in actual projects.

The negative performance impact of GC in performance-engineered code is neither small nor controversial, it is mechanical consequence of the architecture choices available. Explicit locality and schedule control makes a big difference on modern silicon. Especially for software that is expressly engineered for maximum performance, the GC equivalent won't be particularly close to a non-GC implementation. Some important optimization techniques in GC languages are about effectively disabling the GC.

While some applications written in C++ are not performance sensitive, performance tends to be a major objective when choosing C++ for many applications.

Re: C++20, How Hard Could It Be

#305

Post by DannyBee » Sun, Sep 25, 2022, 7:46 PM UTC

loxias wrote: post #109

ncmncm wrote: post #95

Earlier quoted context omitted.

Gcc pretty consistently delivers slightly faster code.

Not in my experience! Though it was a few years ago, I'll have to re-evaluate. In the past, when doing numeric/scientific programming -- lots of dataflow, it was much easier to "coax" clang to generate the right (performant) assembly than GCC. I guess my use is less typical -- the internet agrees with you. :) Hurrah for competition! (of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble…

"(of course, neither GCC or clang could _ever_ beat ICC at some of my tests.. grumble)"

They never tried, honestly - ICC had plenty of defaults that were targeted at performance above correctness.

That's fine - but it wasn't what either clang or gcc was going to go for. Even when trying to compare apples to apples, folks often compared them by trying to get GCC/Clang to emulate the correctness level of ICC (IE give GCC/Clang more freedom), rather than the other way around :)

Which, again, similarly understandable, but also a thing that you'd have to spend a while on in GCC/Clang to get to a reasonable place)

Small-number-of-target compilers like ICC are also fundamentally easier. Lots of techniques (IE optimal register allocation[1], etc) that add up to performance gains are a lot more tractable to really good applied engineering when they don't have to be so general.

Similarly small-target-market compilers are also easier. Over time, high performance was literally ICC's only remaining market. So they can spend their days working on that. GCC/Clang had to care about a lot more.

[1] This happens to now be a bad example because advances finally made this particular thing tractable. But it took years more, and feel free to replace it with something like "optimal integrated register allocation and scheduling" or whatever is still intractable to generalize.

Re: C++20, How Hard Could It Be

#306

Post by llanowarelves » Sun, Sep 25, 2022, 7:49 PM UTC

phao wrote: post #258

scottLobster wrote: post #208

Earlier quoted context omitted.

Fortran is easy to hire for?

For numerical and scientific (high performance) jobs, possibly not that much harder than C++. For other jobs, I doubt it and would stick to C++. The issue is that, for example, you might be getting people with poor software engineering training per se. You risk hiring some very smart phd that writes code that works and runs really fast, but isn't that readable, extendable, maintainable, testable, etc.

Your second paragraph describes what I see with Python ML guys.

Re: C++20, How Hard Could It Be

#307

Post by evouga » Sun, Sep 25, 2022, 7:51 PM UTC

tialaramex wrote: post #152

codeflo wrote: post #53

Many are of the listed items are merely being deprecated. These shouldn’t really qualify as breaking changes. In fact, the ability to migrate away incrementally is precisely the point of deprecating instead of removing a feature. What surprises me is that a lot of the deprecated functionality seems really recent — C++14 or newer. Compatibility is C++’s big thing, that’s historically why it kept almost all of C as a s…

Mostly deprecations mean something was deemed to be a bad idea, which means it's at the very least worth taking a moment to evaluate whether somehow they were a good idea when you did them. For example should I have a method whose parameters are volatile? Well, why did I do that? It didn't do anything in C++ 17 and it still doesn't do anything in C++ 20 but now it's deprecated. Programs are written first and foremost…

The volatile parameters deprecation is one of the stranger decisions, though, since there are plenty of constructions that don’t do anything but are still allowed by the language. I see this as a matter of style that might be useful to warn about, but shouldn’t be policed as an error by the compiler.

Re: C++20, How Hard Could It Be

#308

Post by f1shy » Sun, Sep 25, 2022, 7:51 PM UTC

mrazomor wrote: post #290

f1shy wrote: post #281

Earlier quoted context omitted.

I agree with this comment, and cannot understand why is downvoted. I would like the one that downvoted comments on why. My thinking, more or less in line with the comment is: instead of investing energy, time and resources in writing laws of what is allowed and what no (often without rationale). Use that time, effort and energy in educating developers, so that, if those prohibitions are really sensible, they will any…

What's easier: writing set of rules to drop language features or educating 10k engineers? It's difficult alone to have those engineers follow the style guide (even with help from linters etc). Average engineer, in any company, doesn't care about the language they use. Just wants to get stuff done. And that's how it should be.

My experience says, if you want to do one project. By all means, it's easier to have a standard where you drop features. -- But beware: you need either good engineers or you have to educate them, anyway.

If you have constant new projects, each one with very different requirements and needs, it will not be so easy to make a standard "one size fits all".

Also, again, you will not be doing "just one" standard, I would not subestimate the effort of such rulesets. You will have to the modify and modify it constantly (I know it from the company I'm, there are whole teams working on that, doing meetings constantly with stakeholders, and replying to exception requirements). In the long run, I would prefer to have good engineers, that do not need to be lead in each little step. --and having to check if they adhere to the rules!

I like the phrase: "If you think education is expensive, try with ignorance" Or: - I'm afraid to waste money educating our employees, and then they leave us - What if we do not educate them, and they stay?!

Re: C++20, How Hard Could It Be

#309

Post by f1shy » Sun, Sep 25, 2022, 7:53 PM UTC

p1esk wrote: post #295

f1shy wrote: post #288

Earlier quoted context omitted.

In the company I work most of it is done in matlab for "putting together" then goes to C++. Again not neural networks. I'm saying all the other machine learning. Maybe rare case.

What kind of machine learning does your company do? It's probably something simple, because for anything complicated, like computer vision, speech recognition, any non-trivial NLP, and large scale recommender systems you do need neural networks.

Autonomous driving, including, for example, computer vision. No NLP or speech. About the "need" or neural networks, there is a lot of discussion going on. As you may know, the "black box" nature of NNs make them a little more difficult than other means, when you have to validate them for safety critical systems.

Re: C++20, How Hard Could It Be

#310

Post by alternatetwo » Sun, Sep 25, 2022, 7:59 PM UTC

jdougan wrote: post #99

jmillikin wrote: post #94

Earlier quoted context omitted.

When I was going to university the computer science department's primary system had two compilers available, GCC 2.96[0] and TenDRA. GCC was generally more popular but it didn't have std::string and any code that threw an exception would crash, so adventurous students would use TenDRA for development. One of the stranger behaviors of TenDRA was that it put all standard library symbols, including the C headers , into…

GCC 2.96 was a development version that incorrectly got released by Redhat on Redhat 7 (and possibly other distros). https://gcc.gnu.org/legacy-ml/gcc-announce/2000/msg00003.htm...

Fairly sure some PS2 SDKs also shipped GCC 2.96, which is why I know this tidbit of info.