The Hidden Cost of C++ • Hacker News Board

Re: The Hidden Cost of C++

#31

Post by groby_b » Tue, Oct 20, 2009, 6:39 PM UTC

blub wrote: post #29

kmavm wrote: post #6

Earlier quoted context omitted.

Pop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's code reviews? There are, after all, languages out there that do not force this insanity on us. The alternative for performance-critical applications is not Java, but C. C remains surprisingly tough competition after all these years for those rare pieces of so…

I am surprised to see that so many programmers still like to reason and guess what the performance of their program is instead of profiling it... And hearing C proposed as an alternative to C++ is mind boggling. I don't want to match malloc/free calls, strcat strings together or realloc pointers. I don't want to declare a bunch o function pointers in a struct and call it OOP. I don't want to use macros because C99 ha…

I propose a lower level than C++ for the kernel, and a higher level for the rest.

C++ is simply at the wrong abstraction level.

Oh, and I don't want to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of.

You did notice I was talking about game development, right? ;)

Re: The Hidden Cost of C++

#32

Post by groby_b » Tue, Oct 20, 2009, 6:43 PM UTC

huhtenberg wrote: post #28

uriel wrote: post #10

Earlier quoted context omitted.

What he is pointing out is that C++ makes it harder to 'know the code you are working with'.

I understand the point, and I am saying it is a trivial one. Calling func(x) in C may as well be causing x to be cloned or have some other nasty side effects that are not immediately obvious from looking at the code. Similarly how one should always keep in mind the existence of macros when reading C code, one should also keep in mind the existence of constructors and casting operators with C++. That's hardly the hidd…

The point is that, with a rational team, I can tell (roughly) what a function is doing, based on the name. It's not going to be called 'dot_product' and clone data passed in ;)

What I can't tell is how much extra code the compiler will generate at this point, and that is the problem.

> If there is a hidden cost to C++, it is the fact that it requires higher level of competence. Not that it has constructors.

I didn't say the cost is in the constructors. They're a symptom of the cost. The cost is creating the mental model of your app.

Sure, if the entire team consisted of C++ superstars, we might be able to get away with this. Given the team size on current games, (and the fact that superstars are rare) that's unlikely to be the case.

Re: The Hidden Cost of C++

#33

Post by nuserame » Tue, Oct 20, 2009, 6:54 PM UTC

groby_b wrote: post #32

huhtenberg wrote: post #28

Earlier quoted context omitted.

I understand the point, and I am saying it is a trivial one. Calling func(x) in C may as well be causing x to be cloned or have some other nasty side effects that are not immediately obvious from looking at the code. Similarly how one should always keep in mind the existence of macros when reading C code, one should also keep in mind the existence of constructors and casting operators with C++. That's hardly the hidd…

The point is that, with a rational team, I can tell (roughly) what a function is doing, based on the name. It's not going to be called 'dot_product' and clone data passed in ;) What I can't tell is how much extra code the compiler will generate at this point, and that is the problem. > If there is a hidden cost to C++, it is the fact that it requires higher level of competence. Not that it has constructors. I didn't…

If there's no enough "superstars", then perhaps your coding guidelines should accommodate that so that the "mental model" of the app would be more managaeble for the code monkeys.

Re: The Hidden Cost of C++

#34

Post by timr » Tue, Oct 20, 2009, 7:00 PM UTC

groby_b wrote: post #25

timr wrote: post #22

Earlier quoted context omitted.

"Guesses based on local code inspection have an order of magnitude less uncertainty attached to them" ...which is why we have profiling tools that make it easy to detect performance hotspots. For the other 95% of our code, the expressiveness of C++ makes it easier to do more work in fewer lines. This is a far more important metric to any working developer (and it's a big reason why languages like Python and Ruby are…

Given that games more or less have to implement their own OS, I hope I'm not completely crazy yet ;) I am not talking about "business apps" (whatever that is). I'm talking about down-to-the-metal resource management, task scheduling, etc. I could probably live with those issues in the higher logic layers (although I'd argue a scripting language would make you much more efficient there). But the underlying "OS" as wel…

" But the underlying "OS" as well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage."

No. C++ has some pretty huge advantages for performance-critical software. Generic programming makes it possible to write extremely succinct, high-performance code. Operator overloading allows the creation of vector and matrix libraries that look like real mathematical expressions, while evaluating to code that's as fast as anything you'll get from Fortran.

I didn't write "business apps" (not sure where you got that). I wrote software that simulated proteins -- in other words, high-performance computing -- and except for FORTRAN, C++ was the best choice for the job. Doing the equivalent optimizations of a library like Boost::MPL in C is a nightmare of pointer arithmetic.

When you throw in the fact that C++ makes it easy to avoid the memory leak, corruption and type safety issues that plague C code, you can easily see why C++ is becoming the language of choice in the HPC world.

Re: The Hidden Cost of C++

#35

Post by scott_s » Tue, Oct 20, 2009, 7:06 PM UTC

groby_b wrote: post #14

dkarl wrote: post #8

The argument boils down to the fact that C++ can express more in a single line of code than C can. a = func(b,c); .... Is it a function call, a member function call, or is it an anonymous constructor? Are b and c implicitly invoking copy constructors for other classes as part of type coercion? Is that a normal assignment, or an assignment operator? Is there a cast operator involved? If it's such a complicated express…

Your counterargument boils down to "use C instead". That is exactly what I am currently advocating. I don't blame C++ for screwing up - I blame it for being an ill-designed language that makes it easy to screw up. Any of the high-level features of C++ are well-implemented in any number of decent languages that don't obfuscate your code and incur horrible link times. And my argument (for game development) is that C++…

His first two paragraphs do not "boil down to 'use C instead.'" His first paragraph explains a situation in which C++ is a win over C.

Re: The Hidden Cost of C++

#36

Post by hazzen » Tue, Oct 20, 2009, 7:14 PM UTC

JoeAltmaier wrote: post #2

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Do you know how to fix almost every one of these cases for good? Just don't allow implicit copying of your classes. Problem solved. If someone tries to write that horrible code, they can't.

This is more a question of knowing what you are doing and less of C++ sucking. C doesn't solve this - you still have to know what you are doing there or you end up shooting yourself in the foot. I much prefer having an interface with virtual methods to a struct with function pointers.

Re: The Hidden Cost of C++

#37

Post by blub » Tue, Oct 20, 2009, 7:15 PM UTC

toadpipe wrote: post #20

dkarl wrote: post #8

The argument boils down to the fact that C++ can express more in a single line of code than C can. a = func(b,c); .... Is it a function call, a member function call, or is it an anonymous constructor? Are b and c implicitly invoking copy constructors for other classes as part of type coercion? Is that a normal assignment, or an assignment operator? Is there a cast operator involved? If it's such a complicated express…

Expressiveness in a single line of code is such a stupid metric. magic() What's that? It's a function call. What does it do? Anything. Everything. Why does it need a complex grammar? It doesn't. Spend your time thinking about the problem, not the language. What a concept! Do simple things take many lines of code in C? Yes. If you only have a few data structures and algorithms in your mental toolbox, simple things wil…

Wrong: C++ promotes library features before language features. Language features are carefully considered before they are included or dropped.

In fact the entire language is designed with care, which should be obvious to anyone who has read The design & evolution of C++ or has followed C++'s evolution.

Re: The Hidden Cost of C++

#38

Post by blasdel » Tue, Oct 20, 2009, 7:16 PM UTC

groby_b wrote: post #23

aceofspades19 wrote: post #18

Earlier quoted context omitted.

And you can make your code slower by changing it! Oh the horror. C++ is, imo, a good language for a lot of domains. What goes wrong is when people try to use all of the features that C++ offers instead of just using the ones applicable to their domain, eg. I don't think you would really want to use exceptions in embedded programming. If you are on a platform where performance is the key, then you should be careful of…

The point is not that I can make the code slower by changing it. The point is that it can get slower by changes to the API, without any changes to functionality.Made by somebody else, unintentionally impacting me. Let me ask you this: Have you ever worked on a large scale C++ project that didn't have performance issues? Or memory issues?

None of what you've said is in any way specific to C++

APIs can easily lose performance when refactored for correctness or code clarity. Large projects have large project issues!

Re: The Hidden Cost of C++

#39

Post by blub » Tue, Oct 20, 2009, 7:21 PM UTC

groby_b wrote: post #31

blub wrote: post #29

Earlier quoted context omitted.

I am surprised to see that so many programmers still like to reason and guess what the performance of their program is instead of profiling it... And hearing C proposed as an alternative to C++ is mind boggling. I don't want to match malloc/free calls, strcat strings together or realloc pointers. I don't want to declare a bunch o function pointers in a struct and call it OOP. I don't want to use macros because C99 ha…

I propose a lower level than C++ for the kernel, and a higher level for the rest. C++ is simply at the wrong abstraction level. Oh, and I don't want to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of. You did notice I was talking about game development, right? ;)

My reply was not targeted at you and I don't do game programming.

Anyway:

* smart pointers don't need an OS.

* for me, C++ is at the exactly right abstraction level to allow me to use only C++ instead of "C++ + other language" or "other language and C for speed". Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages.

Re: The Hidden Cost of C++

#40

Post by psyklic » Tue, Oct 20, 2009, 7:25 PM UTC

groby_b wrote: post #30

psyklic wrote: post #27

The author is worried about optimizing . He should know that in high-performance applications, you should just write the code then profile it. We all know that C++ is fast; the real question the author should be asking is whether C or C++ can more quickly express ideas/is more maintainable/etc. This post about not knowing how a function is called is really splitting hairs, bordering on irrelevant imo -- sure, it can…

She does know that you need to profile, TYVM. But ideally, you pay at least cursory attention to performance even when you write the code. Writing code with complete disregard to performance, saying "oh, the profiler will find it" is not an acceptable choice. You don't write sloppy code and argue that you can find bugs in the debugger, either, do you? And no, most high-performance items are not on the GPU. Most games…

Worrying about not knowing how functions are called on your first iteration is such a moot point. Simple programming conventions (e.g. no multiple inheritance) can eliminate this problem. Even if each function call does take 10x longer, I would argue that in 99% of the cases you wouldn't even notice the difference, practically speaking.

Shipping high quality games, developed as fast as possible.

If this is what you care about, then you should care about optimizing AFTER you write the initial version and identify hot spots.

You don't write sloppy code and argue that you can find bugs in the debugger, either, do you?

Sloppy code vs. "slow" code are vastly different. I would much much rather have slow code, since 99% of the time it isn't even noticed by the user. Hence, it was worth not thinking about how to improve it.

most high-performance items are not on the GPU.

I agree that you want to take load off the GPU. However, CPU speed has not been the limiting factor in games for a LONG time. In fact, in conferences such as the GDC it is rarely discussed any longer, only in the context of using more CPU if available for non-engine tasks such as AI.

And no, the 95%/5% rule does not hold true in game development.

There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game. If you look at modern games, do you think it is a waste that they are based on interpreted scripting languages? They can do this because as I said above, CPU isn't as limiting a factor as before.