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

41–50 of 66 posts

Re: The Hidden Cost of C++

#41

Post by psyklic »

groby_b wrote: post #24
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 avail…

When I code in a team, we don't just write one big mass of C++ and hope that all the interactions work out okay!

Instead, we follow modular programming practices. If some interactions are too slow, we know who didn't optimize his section and we kick the problem back to him.

Re: The Hidden Cost of C++

#42

Post by groby_b »

psyklic wrote: post #40
groby_b wrote: post #30

Earlier quoted context omitted.

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

_Sloppy code vs. "slow" code are vastly different._

Not really. Some amount of up-front investment can avoid a lot of pain at the end. Do I obsess about every single call? No, of course not - but I try to avoid obvious performance issues.

While you can optimize them after the fact, it's more time you're spending.

_CPU speed has not been the limiting factor in games for a LONG time_

Yes, actually, it is. It might not be raw speed - we're talking cache misses instead - but you still have to be careful with your resource usage.

_There is a big difference between what is essentially a graphics engine (you reference the Unreal engine) and a video game_

Yes, and no. Unreal is more than a "graphics" engine - it's an entire game engine. (There's way more than graphics there.) And CPU performance still is discussed at GDC. See here, for example: http://www.scribd.com/doc/15118967/Hitting-60Hz-in-Unreal-En...

And the games built on top of it use some scripting. And often dive into C++ and even the engine itself to make the game actually perform well.

But that's exactly the model I'm advocating. Write the kernel in a low-level language (preferrably not C++, for many reasons, some of them mentioned in my post), and do the game logic in a scripting layer on top.

The faster you can get the kernel, the more resources you can devote to a language that makes life much easier for the rest of the world.

So yes, I wasn't exact. When saying "game development", I was referring to "engine development". The point still stands - I think C++ is inappropriate for low-level tasks (too much "magic") as well as high-level tasks. (Incredibly convoluted language. No, I'm not saying Stroustrup is a bad designer. I'm saying the constraints he imposed on himself forced C++ to head that direction. And design by committee helped.)

If you look at modern games,

I do. Every day. Intimately. I work on them. That's why this topic matters to me. It'd be kind of stupid to complain about C++ usage in game development without knowing about it ;)

Re: The Hidden Cost of C++

#43

Post by groby_b »

nuserame wrote: post #33
groby_b wrote: post #32

Earlier quoted context omitted.

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.

This is not a question of "code monkeys". It's simply a question of having some programmers that are less experienced than others. And that's kind of unavoidable if you ever want to hire new people...

Re: The Hidden Cost of C++

#44

Post by groby_b »

psyklic wrote: post #41
groby_b wrote: post #24

Earlier quoted context omitted.

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

When I code in a team, we don't just write one big mass of C++ and hope that all the interactions work out okay! Instead, we follow modular programming practices. If some interactions are too slow, we know who didn't optimize his section and we kick the problem back to him.

That would be nice. Except that - again, for performance reasons - we often have to break the boundaries between modules. Most game engines are a tangled web, since many parts are talking to many other parts. (I think there are ways around that, and there will certainly be a post on it. But that's the way things work right now)

So it's not always that easy to just find a guilty party and blame them.

Re: The Hidden Cost of C++

#45

Post by groby_b »

blasdel wrote: post #38
groby_b wrote: post #23

Earlier quoted context omitted.

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!

The difference is that the API can change without visible API changes. If you add a virtual destructor to your class, I won't notice that by looking at the call site. I've just been burdened with additional overhead, without knowing about it.

And yes, large projects have large project issues. It is kind of telling that C++ needs an entire tome on large project issues, though... (Lakos, Large Scale C++ Software Design)

Re: The Hidden Cost of C++

#46

Post by groby_b »

blub wrote: post #37
toadpipe wrote: post #20

Earlier quoted context omitted.

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.

Yes, really careful... "Oh look, another shiny feature. Let's add it!" ;)

But kidding aside - the constraints imposed on C++ during its design (C backwards compatible) combined with a desire to have every feature under the sun available has led to an overly complex beast.

Don't tell me you looked at e.g. C++ lambda functions and thought that was "good design". It gets the job done, but that's the best you can say about it.

Re: The Hidden Cost of C++

#47

Post by dkarl »

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

No, my counterargument is to use the features of C++ when they help and not when they hurt. I claim that C++ doesn't hurt C programmers. It just brings out their deficiencies in different ways. For instance, embracing features you don't understand and then complaining about the consequences is stupid, and stupid people don't write good code in any language. You understand C++ well enough to know the pros and cons (or at least the cons) of various C++ language features, but you complain that your fellow programmers might not:

The issue is that in many instances, I own the caller, but not the callee. And the person owning the callee can unintentionally make my code perform worse by simply changing the API. Or adding a destructor.

This is just bad programming practice on their part. The performance cost of a destructor shouldn't be a surprise to the person who writes it. If someone is messing with the performance of types you use or removing functions(+) you call without consulting you and without themselves taking responsibility for calls to that functionality, then obscure features of C++ is just one of the many ways they're going to screw you on a regular basis. How would those programmers screw you in C? I don't know, but I know they would.

Nobody who knows C++ well enough to use it effectively would call it a "decent" language in the sense of "not obscene," but it is definitely "decent" in the sense of "adequate." It's easiest to define C++'s deficiencies with respect to other languages (for instance, memory management in C++ is much more intrusive in source code than in Java) but comparing it to C is way too simple. After all, the primary problem with C++ is that it doesn't remove any of C's dangers; it just gives you better ways of abstracting them away in some cases. The second problem with C++ is that it's extremely complicated and takes a long time to learn. And that's it. Every other supposed misfeature of C++ (relative to C) seems to stem from people hitting the second problem without realizing it. In your case, your coworkers should be more conservative about messing with things (such as defining expensive automatic type conversion functions) when they don't understand the consequences (such as those type conversions actually being invoked.)

(+) This is the most plausible explanation for different type conversions suddenly being invoked. It could also happen by adding a function that invokes a more expensive type conversion to a type that is more closely related to the type declared by the caller, thus making the new function a better match than the old one, but it's unlikely that a conversion between two types that are more closely related would actually be more expensive.

Re: The Hidden Cost of C++

#48

Post by groby_b »

timr wrote: post #34
groby_b wrote: post #25

Earlier quoted context omitted.

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

_why C++ is becoming the language of choice in the HPC world._

And yet, the HPC world looks for a new language: http://www.cs.sandia.gov/Conferences/SOS10/presentations/Tue...

And a lot of the HPC world still writes FORTRAN or C. (I.e. BLAS, LAPACK, et.al.)

But then again, I don't spend that much time in the true HPC world. Maybe I'm missing a trend there. But from the outside, it looks like C++ is not quite what people wanted.

Re: The Hidden Cost of C++

#49

Post by groby_b »

blub wrote: post #39
groby_b wrote: post #31

Earlier quoted context omitted.

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.

_Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages._

I'll concede that as a valid concern, especially for smaller projects where everybody touches many areas of the code. As projects grow, a separation becomes easier.

Add to that the fact that most games need scripting support anyways, and you'll see that the logistics overhead is at least not much different.

Re: The Hidden Cost of C++

#50

Post by aceofspades19 »

groby_b wrote: post #45
blasdel wrote: post #38

Earlier quoted context omitted.

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!

The difference is that the API can change without visible API changes. If you add a virtual destructor to your class, I won't notice that by looking at the call site. I've just been burdened with additional overhead, without knowing about it. And yes, large projects have large project issues. It is kind of telling that C++ needs an entire tome on large project issues, though... (Lakos, Large Scale C++ Software Design…

Well if you are working on an embedded platform, then its just poor discipline to add a virtual destructor and it boils down to bad programmers.
Post reply on HN