The Hidden Cost of C++
rachelslabnotes.com
The Hidden Cost of C++
1–10 of 66 posts
Re: The Hidden Cost of C++
#2I 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.
Re: The Hidden Cost of C++
#3And 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 many little things you can have your developers do to prevent the compiler from doing many of these things and you should have it be part of your normal API reviews to make sure that developers follow them. A simple example
class Box { public: Box(int x); };
class Foo { public: Foo(Box a) };
... Foo(1); ...
Pop Quiz: How would you change Foo (or the whole api) to cause Foo(1) to cause an error?
Re: The Hidden Cost of C++
#4There 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.
Re: The Hidden Cost of C++
#5And 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…
I'm pretty sure the author was comparing C++ to C, not to Java, but that's kinda beside the point, because as the article says, "The real hidden cost is that now, instead of looking at one piece of source -- the function itself -- I need to look at up to four different classes. Add possible ancestors to find out if a call is virtual."
Put another way, the performance details we so often care about in projects for which we're using C++ are often non-local to the calling site. In order to know the performance characteristics of "a = foo(b, c)" I need to know a lot of things about the types of a, b, c, and foo, in addition to knowing what "foo" does inside its curly braces. In contrast, while it's hard to reason about the instructions being executed in Java in the same way we do in C or even to a large degree in C++, the types of a, b, c, and foo don't really matter, since passing in b and c is always a pass by reference or a primitive value copy, and foo is pretty much always going to be dispatched the same way (and constructors are preceded by a "new" operator at the call site, so we don't have to worry about that, either). Now, the only thing I care about is what's inside the foo method.
I am of course not disputing that you need to know the language you're using. It's just that even when you know C++, if you can't trust everyone who ever touched the code, you need to check in a bunch of different places to reason about the performance characteristics of this one piece of code.
Also, reasoning about the performance of C is all well and good right up until you realize that your compiler is better at translating C to assembler than you are and also, some jackass wrote a preprocessor macro called "foo" which does 18 different things. At some point, writing high-performance code is not about assuming you can guess what will happen but about seeing what's happening and trying to make something better happen.
Disclaimer: it's been a good 4 years or so since I worked with Java, and on top of that, I've never cared too much about Java performance, so please take this with a grain of salt.
Re: The Hidden Cost of C++
#6And 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 software where programmer time is cheap compared to hardware resources. Having had non-trivial experience of both languages, reasoning about the performance of a C program is much, much easier than reasoning about non-trivial C++ programs' performance. Guesses based on local code inspection have an order of magnitude less uncertainty attached to them, which is basically what Rachel is saying here.
Re: The Hidden Cost of C++
#7And 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…
Oh, and make Box's constructor explicit.
Re: The Hidden Cost of C++
#8The 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 expression, then the equivalent C code would be correspondingly large and hard to understand, and it would be just as complicated to figure out its cost. The not-so-hidden cost of C is that even simple things end up being many, many lines of code. C++ was invented because certain kinds of C programs -- programs that were already being written in C -- were painfully verbose to express and complicated to change.
If writing your code in C would be simple and clear, then you would have to be stupid to write it as complex, obscure C++. When your C++ code gets complex and you start banging your head against a wall, imagine re-expressing it in C. If the result would be an improvement, then you screwed up. If you blame C++ for screwing up, then you're a language feature junkie. Admit it and check yourself into rehab.
That is the hidden cost. The mental model for a simple function call became incredibly large and complex, and every function call is potentially as complex. Which makes reasoning about performance a rather hard thing to do.... All that translates ultimately into either worse performance or longer development time. Neither one is something you like to hear about.
I don't know how it is a "hidden cost," because it's quite well understood that any reasonably expressive language can say more in a single line of code than C. Anyway, the size of the mental model of your program is what you should be worried about. C++ doesn't give you worse performance or longer development time. It gives you more choices for how you express your program. It means more different problems, because you can write C-style code and have C-style problems, or you can use the possibilities C++ offers and have different problems. If you already know that the choices forced on you by C are usually the right ones for your domain, then by all means apply that knowledge to how you write C++. For instance:
Worse, it makes profiling harder than necessary. All the type coercions that happen at the API level will show up as separate functions, not attributed to the callee, but the caller.
If you want them attributed to the callee, it's pretty simple. Do the coercions in the callee, just like you would have in C.
Re: The Hidden Cost of C++
#9And 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…
Ugh. Try attacking the vector math required for most games programming these days in C, using macros and magic instead of classes and templates and operator overloading. I'd rather blow my own leg off with a bit of C++ any day.
Re: The Hidden Cost of C++
#10There 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'.