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

The Hidden Cost of C++

rachelslabnotes.com

Post reply on HN
Print view View original

21–30 of 66 posts

Re: The Hidden Cost of C++

#21

Post by st3fan »

Wow it is C++ bashing season again it seems.

Yes you have to know what you are doing in C++. But this is not different in other languages. Understanding and optimizing code is a touch discipline. No matter what language.

There is also another side to this story. C++ can absolutely generate highly efficient code. Code that performs much better than C equivalents.

For example, I've looked a lot at generated (iPhone/ARM) code for cases where (function) templates are used and C++ wins most of the time. Doing compile-time configuration of code is usually much more efficient than having runtime-configured code. By using templates and inline functions the compiler can do some seriously cool performance tricks.

Sire, there may be more code (bigger text segment) but that is a small sacrifice for what you gain in speed. Specially these days where a 8MB fart app is easily downloaded over a 3G connection without hesitation.

Re: The Hidden Cost of C++

#22

Post by timr »

kmavm wrote: post #6
icefox wrote: post #3

And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it. For a game shop who is worried about performance there are…

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…

"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 popular.)

Also, you're exaggerating. I wrote C++ for well over a decade, and I wrote in C before that, and used it again in graduate school for my research. While I can count on one hand the number of times that I was affected by "hidden" C++ costs, I was routinely blindsided by bad C code, where pointer errors, type safety gotchas, and inefficiency due to aliasing are de rigeur. You'd be crazy to write a non-trivial application in C today that wasn't an operating system.

Re: The Hidden Cost of C++

#23

Post by groby_b »

aceofspades19 wrote: post #18
groby_b wrote: post #14

Earlier quoted context omitted.

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++…

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?

Re: The Hidden Cost of C++

#24

Post by groby_b »

st3fan wrote: post #21

Wow it is C++ bashing season again it seems. Yes you have to know what you are doing in C++. But this is not different in other languages. Understanding and optimizing code is a touch discipline. No matter what language. There is also another side to this story. C++ can absolutely generate highly efficient code. Code that performs much better than C equivalents. For example, I've looked a lot at generated (iPhone/ARM…

Yes, you can use C++ to do amazing things. In large-scale projects, that usually backfires, though, unless you contain the "magic", because interactions in C++ are harder to predict.

The problem with C++ is not that you have to know what you are doing - you also have to know what everybody else is doing.

And the "small sacrifice" of a bigger text segment is a big one in this particular domain. We only have 512M available, and a tremendous chunk of that is eaten up by graphics. An executable seriously exceeding ~20MB would spell trouble.

And I'd argue that AAA games are slightly more complex than a fart app ;)

Re: The Hidden Cost of C++

#25

Post by groby_b »

timr wrote: post #22
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…

"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 well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage.

Re: The Hidden Cost of C++

#26

Post by kmavm »

timr wrote: post #22
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…

"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…

Profiling tools are post-mortem, and often not able to be enabled in production. What about when the code is not yet running, and you're trying to reason about it as you write it? What about when the performance problem is workload dependent, and only emerges in production, and you need to reason inductively from the source code about what could be going wrong?

Re: The Hidden Cost of C++

#27

Post by psyklic »

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 affect the time taken to call a function by ten times, but this is not a large performance hit at all for 95% of your code, and even less since most high performance items are on the GPU. If it ends up that it does affect performance in a critical area (found via profiling), the author even suggested how it can easily be fixed.

I don't see what the big deal is. If you're a game programmer, change your coding conventions so that you don't get into problems like this.

Re: The Hidden Cost of C++

#28

Post by huhtenberg »

uriel wrote: post #10
huhtenberg wrote: post #4

There are constructors in C++. The water is wet, how sneaky of it. You either know the code you are working with or you don't. C++ or not.

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 hidden cost.

It is easier to write messy or obscure code in C++, especially for a novice programmer. But this has less to do with the language per se and more with established coding practices within specific team. If there is a hidden cost to C++, it is the fact that it requires higher level of competence. Not that it has constructors.

Re: The Hidden Cost of C++

#29

Post by blub »

kmavm wrote: post #6
icefox wrote: post #3

And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it. For a game shop who is worried about performance there are…

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 has poor adoption rate and C89 doesn't have inline. I don't want to watch the compiler blissfully convert unrelated types to one another just because it can. I don't want to pass types around as void* and lose any useful type information I might have had. I don't want to fumble with return codes.

And in C++ I don't have to. I can use Qt, the STL and Boost and be very productive. Telling me to program in C is not even funny.

Re: The Hidden Cost of C++

#30

Post by groby_b »

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 are already GPU-bound, so you want to take load off of it. (Also, with the arrival or LRB et al., the GPU/CPU distinction becomes moot)

If those issues were irrelevant, I wouldn't care about them. There's one thing I do care about: Shipping high quality games, developed as fast as possible. C++ hurts that goal.

And no, the 95%/5% rule does not hold true in game development. But don't trust me - read, for example, Tim Sweeny, the guy behind the Unreal engine. According to him, there are not hotspots. Another Unreal programmer: http://lambda-the-ultimate.org/node/1277#comment-14238

"Dan Vogel, was fond of pointing out that UE2 had a basically flat profile"

That is the big deal. In a flat profile, things like calling overhead matter everywhere.

Post reply on HN