Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C++20, How Hard Could It Be

docs.google.com

Post reply on HN
Print view View original

241–250 of 444 posts

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

#241

Post by igouy »

bugfix-66 wrote: post #204
galangalalgol wrote: post #198

Earlier quoted context omitted.

Even with version 1.18 the median is 3x slower than c++ in the benchmark game. And most of those programs don't even exercise the GC (other than binary trees benchmark). If you are targeting a quadcore arm embedded type thing with no gpu, go is going to take something that saturated one core, and make it saturate 3, if you are lucky enough it is easily parallelized. Even when a gpu is available, it often isn't a good…

I don't know if you've read the benchmark code from The Benchmark Game, but anyone who has looked at the code takes those results with a grain of salt, or discards them entirely. For example, the C/C++ implementations use arena allocators, and they could do the same for the Go implementations, but they don't. The Benchmark Game is a joke. Here it is, for anyone who wants a good laugh: https://benchmarksgame-team.page…

Compare GC Java with GC Go.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

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

#242

Post by pclmulqdq »

pornel wrote: post #38
izacus wrote: post #22

Earlier quoted context omitted.

Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?

Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it). Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code. Rust has a standard project layout, standard test runner,…

> Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run").

I'm not sure why this is treated as a selling point. It helps projects up to a point, but the minute you want to do something that doesn't fit the mold, it makes things a lot harder. All of these products are orthogonal to a language, and yet they are very tightly bundled with the idea of using the Rust language. It certainly makes "business logic" systems and web backends easier to implement, but I'm not sure many people were building those in C++ to begin with (except in legacy systems, where you are stuck with what you have).

Also, I'm not sure how a language that is less than 10 years old (in its released, 1.x versions) has any claim to having no problems with evolution over the next 10 years.

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

#243

Post by B1FF_PSUVM »

GnarfGnarf wrote: post #97

The Boeing 377 Stratocruiser was the epitome of piston technology: 28-cylinder radial engine that needed more maintenance than flying time. It vibrated so hard that it separated from the wing. https://en.wikipedia.org/wiki/Boeing_377_Stratocruiser

Leads to https://en.wikipedia.org/wiki/Aero_Spacelines_Pregnant_Guppy

As some comedian used to quip, Pregnant Guppy would be a good band name.

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

#245

Post by jandrewrogers »

bugfix-66 wrote: post #192
synergy20 wrote: post #182

Earlier quoted context omitted.

Go will give me VSS of hundred of Gigabits on a MIPS board that has only 64MB memory, it's a known 'feature' by design. Its binary size is at least 10x larger than C/C++. Go also has the stop-the-world GC problem, GC is great but it does have a price tag. I like Go a _lot_ and use it in some projects, but I certainly will not claim it can replace C++ 'generally', not at all.

Sure, you can always find extremely constrained, embedded, or real-time safety-critical applications where only a carefully chosen subset of C is applicable. You shouldn't be using the sprawling C++20 there, either. But for pretty much everything else (see the caveats in my comment above) you are better off, a lot better off, using Go.

C++17/20 is superior to Go, and widely used, for anything that looks like high-performance data infrastructure, which is a broad class of software. There are classes of common architectural optimizations that aren't feasible with a garbage collector because of how it interacts with scheduling and CPU caches. Even 1 millisecond for a GC pause -- often considered "low latency" -- is much too slow when standard operation rates are tens of millions per second.

Go is very good for many things but it does not offer competitive performance for these types of applications because design elements that have a large impact on throughput are poorly supported.

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

#246

Post by pclmulqdq »

philliphaydon wrote: post #126

This might be a stupid question. But is there performance degradation between versions of c++? I saw a couple of stack overflow questions last week of people complaining about c++ 17 being slower 14, and 14 being slower than 11. But I find it hard to believe. I just started learning c++ recently and can’t find a conclusive answer.

The "idiomatic" version is slowly getting slower because the idioms are getting higher-level and more expressive. If you don't use the idioms, you can have the same speed. Smart pointers (including unique_ptr) have non-zero overhead compared to Foo*. The object oriented parts can introduce significant slowdowns. Template code can have huge code footprints if you are not careful, which slows things down.

If you are looking for cycle-level performance, you likely need to use a more C-like subset of the language, but you can still use many conveniences like RAII and the smart pointers with 0 overhead (when construct/destruct are not in the critical path).

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

#247

Post by layer8 »

misnome wrote: post #51

Wait, so the words "concepts" and "requires" were newly made keywords, and this breaks code, but the words "yield" and "await" were determined too important and too common to standards members that they needed to be renamed to the horrifically ugly "co_await" and "co_yield"? Also, last time I actually tried to use C++20 none of the standard library implementations had std::format; has this changed now?

`std::this_thread::yield` already existed at the time, and “yield” was presumed to also be a common identifier in financial and agricultural contexts.

I’m nevertheless surprised that new noncontextual and previously-unreserved-identifier keywords were added at all. In earlier times, the approach would have been to use a reserved identifier like “_Yield” for the keyword, and to provide a standard opt-in header that would `#define yield _Yield`. Maybe they don’t want to add dependencies on the preprocessor anymore.

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

#248

Post by oconnor663 »

jokoon wrote: post #151
diceduckmonk wrote: post #3

Is there a case for or against incrementally adopting Rust ?

Rust is too hard to learn. I like it, but it only aims at replacing ada, not c++. I asked around and there is currently no good way to make modern native ui apps with rust. It would be okay if the syntax of rust looked a bit more like C, but it doesn't, it can be a bit difficult to read.

Rust's learning story has some interesting dichotomies in it. For sure, no one disputes that learning Rust is harder than say Python or Java. But how does it compare to C or C++? My take (which I have no proof for, to be clear) is that learning Rust is much easier than either of those if you're truly starting from zero. Some scattered thoughts about this:

- Experienced C and C++ devs have to unlearn certain patterns when they start Rust. C++ experience can be a huge help, but if you insist on using the patterns you're used to in Rust, you often have a terrible time and feel like the compiler can't handle useful programs.

- Particularly with C, what we usually mean when we say "learn" has gotten kind of out of date. If someone with a few years of programming experience says they "know" Python, we might assume they can make an HTTP request and parse some JSON with a couple minutes of googling the relevant API docs. But of course in C, those tasks are much more challenging, and we often allow that someone has "learned" C even if they can't do those things without great difficulty. Part of C's reputation for being (comparatively) easy to learn is that we don't expect programmers to be able to do the same variety of tasks with it.

- A lot depends on what standard of correctness and security we want to apply. For example, writing multithreaded code in Rust has an extra steep learning curve, but the resulting code is data-race-free once it compiles. Writing big multithreaded programs without data races takes many years of experience in C and C++, and it might be genuinely impossible for sufficiently large projects. So depending on what we understand "learning to write multithreaded programs" to mean, we could say that Rust is much harder but also that Rust is much easier.

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

#249

Post by synergy20 »

bugfix-66 wrote: post #213
surajrmal wrote: post #209

Earlier quoted context omitted.

go has other problems that preclude it from being a good option including binary size, memory usage, and portability. There are certainly a lot of places it is a good choice for, but I can't really imagine using it anywhere I use c++ today.

Portability? Are you saying Go has portability problems? Can you elaborate on that very surprising claim?

when you talk about macos/windows/linux without CGO yes Go is very portable and easy to use, when you need CGO, or you need work on other architecture or OSes, Go is pretty much a no-go. and c/c++ are still the only ones close to the claim "runs on everything".

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

#250

Post by echelon »

worker767424 wrote: post #244

In a few months, I might be switching to a team with a C++ project. A lot of the team is new to C++, and there's nothing about the project that needs C++, Java would have been fine. This doesn't look very fun.

If there's ever a big production outage, you can make the case for Java.
Post reply on HN