The hidden cost of C++ (2009)

http://www.rachelslabnotes.com/2009/10/the-hidden-cost-of-c/

by fogus • 14 years ago

41 70 14 years ago

jon6• 14 years ago

I don't necessarily disagree with this assessment but you can easily create functionality in C that requires looking at multiple source files to understand whats going on.

    x = foo(bar(), baz());

Now you have to look at the definitions for bar and baz to understand the cost of this line.

I guess this is the trade-off with using a high level language. Expressivity vs transparency.

mpyne• 14 years ago

This page gives another "nice" demonstration of C (in actual usage, not an obfuscated code contest): http://oldhome.schmorp.de/marc/bournegol.html

What's especially nice is that TRUE is defined as -1 in that source, not 1, which could easily confuse someone who isn't intimately familiar with C's boolean operators and conditional expressions (since something like if((a < b) == TRUE) { ... } would actually be incorrect).

Even with that in mind, it would still be nice to have a "safer to use" systems language than C++ generally available. Perhaps Go or D can fill that role (though good luck making that happen for game development on Windows...)

pjmlp2• 14 years ago

For many years that language for me was Turbo Pascal, but then it faded away. :(

BudVVeezer2• 14 years ago

Awesome! Another "I don't understand writing good code in language X, thus that language has 'hidden' deficiencies." post.

You can write non-performant code in any language you'd like, and obscure it in non-trivial ways. That's not the fault of the language.

BudVVeezer2• 14 years ago

Lest I come across as grousing without contributing to the discussion, let's take a peek at the author's main point on hidden costs.

Most of the argument revolves around objects. There are two ways you can run into "hidden" surprises with objects in C++ that the author is pointing out. One involves failing to use the language features given, the other involves writing some seriously odd code.

  class C {
  public:
    /*explicit*/ C( int );  // Adding explicit avoids hidden costs

    // This combination (or something like it) is lethal.
    C( int, double );
    operator bool() const;
  };

So for the author's code to have hidden performance concerns, they would need a constructor taking two parameters of the proper type and an automatic conversion operator that converts to a type assignable as their result. Basically, the stars have to align right and you have to knowingly write some dangerous code.

Don't get me wrong, you can hide costs pretty easily in C++ and write some atrocious code. But usually this issue is alleviated by following basic best practices. The hard part is knowing what those best practices are.

strlen• 14 years ago

Making the copy constructor and operator= private (see boost::noncopyable to take care some of that boilerplate) takes care of some of the other hidden costs.

I do agree that C++ is a complex and hodgepodge language, but I am not sure there are acceptable alternatives yet. It would be great if JVM had native support for value types, i.e., a way to use manual memory management, bypass bounds checks, or call native code without incurring serialization costs.

Yes, I am aware that C# does this (and I like C# and F# a great deal as languages), but a) I am not deploying Windows in production b) Mono is not yet a viable high performance server side platform (it does look promising for desktop and mobile application or for simpler ASP.NET webapps).

C is a beautiful and simple language (one I have strong affinity for) but manually implementing vtables is a bit painful (see a large pure C project for an example of that), nor is there any support for type-safe generic programming (which is an issue I have with Go as well -- even though I fully understand their reasons for omitting generics).

Avshalom• 14 years ago

I feel like--in 2012--claiming C++ has 'hidden' deficiencies/costs/complexities/problems requires a willful ignorance of the last 20 odd years of people C++ bashing.

tsahyt4• 14 years ago

True in a way. C++ programmers like to think that they're writing efficient code because of the language they're using. The same applies to some C programmers (although at a lesser extent I think). In fact, the biggest gains are made on an algorithmic level. That's something a lot of people like to forget.

Then again, the reverse isn't true. There are languages (or more precisely their implementations) that just are slow.

dllthomas• 14 years ago

The biggest gains are often at the algorithmic level, but once you are using a reasonable algorithm there are often large gains to be had in your bottlenecks.

Furthermore, good asymptotic complexity doesn't always correlate with faster code for values of n you actually encounter. Linear search is much faster than binary search, because of cache behavior, up to a surprisingly large n on many architectures.

rubashov3• 14 years ago

> the biggest gains are made on an algorithmic level

I have had a few experiences of simply porting something rather directly to C++ and seeing 10X speed and memory improvements. The 'hidden costs' in other languages are loads of unavoidable heap allocations and pointer indirection that really don't happen with C++. And C++ compilers do a ton of very smart optimization these days.

With the generic programming constructs and static polymorphism approaches in C++ you can often get really big performance increases over what's practical in C or Java. std::sort in C++, for example, has often been found a few times faster than stdlib.h qsort. It's because of compile time optimizations that languages like C and Java can't do.

fauigerzigerk5• 14 years ago

Your ad hominem attack is totally uncalled for. I've been using C++ for over 20 years and what she says is completely obvious to me.

The mental effort you have to make to determine the overhead of an expression by looking at the call site is greater in C++ than it is in C.

That's an undeniable consequence of features like operator overloading, constructors, destructors, virtual functions, etc. It has nothing to do with how well you understand the language. The information just isn't there at the call site for you to see.

The question is a different one. It's whether that fact is compensated for by the power and reduced mental effort these features enable elsewhere. Constructors and destructors make RAII possible. That arguably makes memory management a lot easier than in C.

lutorm• 14 years ago

The mental effort you have to make to determine the overhead of an expression by looking at the call site is greater in C++ than it is in C.

Isn't this just a specific example of saying "the mental effort you have to make to determine the overhead of an expression by looking at the call site is greater in higher-level languages than in lower-level ones"?

It's true, precisely because you are using higher-level abstractions. I'd be more interested in seeing an example where this wasn't true.

hythloday3• 14 years ago

No, sorry. There are a bunch of factors that make the point a little more complicated.

If you're writing, let's say, scenegraph traversal, it's really tempting to get it working on the PPU and then port it to run on an SPU. A vtable dereference to main memory will crash your SPU job and it is not always obvious why. Obviously, you can't use static analysis tools to make sure the right instructions are transferred, so you have to do it by hand. A modern PS3 game has on the order of low hundreds f different SPU jobs...not much fun. Even discounting that, SPUs will work best when fed branchless parallelized jobs, I wouldn't be surprised to see an order of magnitude difference between a vtable call on a pointer array and a static call on an object array.

Keeping pointers to objects in a polymorphic array is a games performance anti-pattern because of the dereferencing cost, but it's necessary to call virtual functions...there's a hidden cost right there.

Which loop is faster, by eyeballing, and by how much?

  void load(Assets* a) {
    for (int j=0; j<m_numAssets; j++) {
      loadAsset(a[j]);
      m_numLoadedAssets++;
    }
  }

  void load(Assets* a) {
    int numLoadedAssets=0;
    for (int j=0; j<m_numAssets; j++) {
      loadAsset(a[j]);
      numLoadedAssets++;
    }
    m_numLoadedAssets = numLoadedAssets;
  }

I've seen the former style run literally 1000 times slower than the latter...that's obvious? I submit in a world of out-of-order processors it is not at all.

I don't think that all the author's points are spot on...Koenig lookup is Byzantine but IDEs do a good job of it, ditto source-level reasoning about dispatch. The underlying theme, that C++ is not a good fit for modern game development, shouldn't be so trivially dismissed.

rubashov3• 14 years ago

How is your example a language thing? Would a JITed language improve the locality of the m_numLoadedAssets variable? I'm not quite sure I get it.

loup-vaillant5• 14 years ago

Nitpick: didn't you mean something like this?

  void load(Assets* a) {
      for (int j=0; j<m_numAssets; j++) {
        loadAsset(a[j]);
      }
    m_numLoadedAssets += j; // Increment once, out of the loop
  }

dude_abides• 14 years ago

The same underlying point can be made in such contrasting styles: Linus ( http://harmful.cat-v.org/software/c++/linus ) vs the OP.

tsahyt4• 14 years ago

Still they're both effectively right about it. "Object oriented niceness" comes at a cost. With C++ it might be smaller than in dynamic languages like Python, where things like function call overhead can be ridiculously big, but it's still there.

zwieback• 14 years ago

I think they are both wrong about it. What the argument boils down to is that the limitations of C prevent you from using things that might lead you astray. That's not an argument for or against C++ it's just an argument against large languages in general and an argument for programmer discipline in specific. It might work for Linus if he reimplements C++ features in a better way but it does not help all users and doesn't help all the time. Do we honestly believe a beginning programmer will be better off reimplementing std::vector or just using a fixed array instead?

If I remember correctly somewhere further down in that particular Linus rant he was saying that you can look at a call site and tell what's going on, the same argument the poster here is making, but do we honestly believe Linus never uses function pointers? And the argument about the name of the function giving us a rough estimate of the overhead does not sound valid to me.

As a C programmer and former C++ programmer I can see a valid argument hidden in these types of posts but I think we'd be better off with a little less attitude and a little more useful guidelines.

halayli• 14 years ago

Abstraction in general comes at a cost.

tsahyt4• 14 years ago

Obviously, yes. One can't expect jumps across multiple levels of libraries, wrappers and APIs to be free of cost. That's what Carmack referred to as "20 layers of crap". He's effectively right about it. On the other hand we can't reinvent the wheel everything we write a line of code.

One of the most important aspects of balancing productivity with performance is knowing which parts of code are crucial to performance and should be written with that in mind. That's one of the toughest parts as well. Usually one is better off profiling than guessing but I believe an educated guess can go a long way nevertheless.

IsTom• 14 years ago

That's true and the thing with C++ is that its philosophy is "if you don't use a feature, you're not getting performance hit associated with it". Be it anonymous functions or virtual calls.

cjensen• 14 years ago

Slapping an "explicit" modifier on all your constructors eliminates what the author is complaining about.

cobrausn• 14 years ago

I really wish 'explicit' was default and the keyword was 'implicit'.

nostrademons2• 14 years ago

With modern optimizing compilers and CPU architectures, you can't really predict the cost of code merely by looking at it anyways. Not in any language.

Will that function call be inlined? Does it have side-effects? Are the arguments constant, so that it might even be evaluated at compile-time? Can it be hoisted out of a loop? Do its pointer args alias, preventing many of these operations? Is it big enough to blow the cache, or will it all fit in L1 and benefit from really fast memory accesses? Can branch-prediction operate effectively on its loops, or does it have an unpredictable pattern that will flush the pipeline many times?

I've heard that the best way to get your program to run fast is to get it into a compiler benchmark suite, so that compiler-writers account for it when writing optimizations. Failing that, it's all about profiling so you can measure the actual cost rather than relying on what you think you know about the programming language.

fauigerzigerk5• 14 years ago

These are good points, but I don't think it relieves you of having to know whether your making a virtual function call or not, or wether you're passing an argument by value or by reference. You do have to know that, and in C++ you cannot know that by looking at the call site. In C and in many other languages you can.

eridius6• 14 years ago

In C there's nothing stopping the function you're calling from turning around and invoking dynamic dispatch.

As a trivial example, objc_msgSend(). This is a C function, but it's also the entry point for objective-C's message sending (e.g. dynamic dispatch).

Basically, what I'm trying to say is, focusing on the cost of the function call itself is useless if you don't know the cost of the function implementation.

alexchamberlain2• 14 years ago

I agree with a lot of points. However, if the function can be evaluated outside the loop, you should move it, not the compiler. It will - probably - be easier to read and understand; it will be easier to debug when it goes wrong too.

VikingCoder• 14 years ago

The days when you can reason about performance by looking at function signatures are, in my opinion, long gone.

I can count on one hand the number of times that I thought that changing the function signature of a few methods was going to impact whole application performance. Every time, it was in a low-level function that was called all over the place. Or, more to the point, I dug into function signatures when evidence pointed me there.

I can't even begin to list all of the other problems I worry about that actually do impact whole application performance on a regular basis.

kqr2• 14 years ago

Note: post is from 2009.

She also has a followup where she explores the "pressure points" of writing games in C++:

http://www.rachelslabnotes.com/2009/11/there-are-never-enoug...

16s• 14 years ago

I use C++ daily for systems level programming and I love it. If I could only have one programming language it would be C++. I can write anything in it and I actually enjoy doing so. Maybe I'm weird or something, but I know a lot of other guys who feel this way too.

And, I know some other guys who do hard core embedded C programming and they are migrating to C++. They love it compared to C and can't wait until every line of their C code has been reimplemented in C++.

C++ will be around for decades to come and many folks actually enjoy writing it, they just don't advertise that fact.

alexchamberlain2• 14 years ago

There's 2 of us!?!

Shorel• 14 years ago

Add me to the club.

Except that I also enjoy some Lisp from time to time.

dkarl2• 14 years ago

Decades might be right. I can't think of a compelling reason for anyone to learn C++ today, but having put in the time to learn it reasonably well, I won't be surprised if I find myself still using it occasionally twenty years from now.

mike-cardwell2• 14 years ago

I started learning C and C++ about three months ago. My reasoning is, they're used all over the place. My operating system is written using C and nearly all the applications I use are too. I want to be able to modify the programs I use, and I want to be able to write native applications that run quickly. Those are my motivations. And I haven't been this happy learning a language for years.

eridius6• 14 years ago

I'm disappointed. I expected this to be a post along the lines of Ridiculous Fish's two posts on C++ features that you pay for even if you don't use:

1. http://ridiculousfish.com/blog/posts/i-didnt-order-that-so-w...

2. http://ridiculousfish.com/blog/posts/i-didnt-order-that-so-w...

Thankfully one of C++11's requirements was to not introduce any new functionality that had penalties even if you aren't using it. Too bad that wasn't a requirement for the original design of the language.

JoeAltmaier4• 14 years ago

While that was informative, its not really C++ specific. The runtime example was library routines.

eridius6• 14 years ago

What do you mean, it's not C++ specific? The runtime example is very explicitly fallout from a requirement of the C++ specification, which affects C++ extern inline functions.

sltkr3• 14 years ago

I've read the first article and I'm not convinced the problem this guy describes incurs real costs in reality. After all, there is no reason to include inline function definition in dynamic objects unless they are called without being inlined or their address is taken; both of which are extremely unlikely for class-inline methods. The author fails to convince me that if C++ didn't require taking the address of an inline functions to yield a consistent value, real-world C++ code could/would run significantly faster.

The second article is pretty much obsolete with C++11, which makes copy-on-write string implementations impractical.

eridius6• 14 years ago

How does C++11 make copy-on-write string implementations impractical? I know the short string optimization is used now, but I don't see how that's incompatible with COW (for strings that are too large to use the short string optimization). And I don't see how move constructor/assignment is incompatible either. Is there some other C++11 change that I'm overlooking?

dkarl2• 14 years ago

The second link is not a good example of C++ imposing a cost for something you don't use. It's just a bad performance trade-off in std::string. The standard library types aspire to be useful in a wide range of performance-sensitive applications, but if they don't work for you, you are free to use alternatives. Programmers at my company use a variety of C++ containers that are faster than the STL containers for particular uses.

The first link is a reasonable example of paying a cost for something you might not use. However, I disagree with the article when it says there's no good reason for it. People really do compare function pointers for equality. A common example is when different functions implement different "strategies" (to use the GOF term.) A simulation might customize the behavior of simulation objects using pointers to different strategy functions, and you might compare the pointers to find all the simulation objects that follow a particular strategy, or to check whether two objects use the same strategy. Since implementations are free to inline functions that are not declared "inline," there would be no valid way to compare function pointers if an inlined function could have different addresses in different translation units.

Adding performance at the expense of sanity should be voluntary, not the default behavior. (It definitely counts as insanity if comparing &my_handy_function and &my_handy_function for equality returns false in a language where function pointers are the only way to treat a function as data.) Anyone who is picky enough about performance to be concerned about link time is on intimate terms with their implementation(s) anyway, so I think it's perfectly acceptable for such an optimization to be available through non-standard flags. Although, if any language were to standardize insanity, perhaps it would be appropriate for it to be C++.

malkia• 14 years ago

in 1999 I was a total C++ dude. I had to work that year on a port of metal gear solid for PC. I was surprised to see such well written C code by the konami developers, with nice oo system that had certain tcl element to it. There were only comments in japanese but that did not stopped us from understanding how it worked.

justinhj• 14 years ago

Exactly. I started working in video games programming in '93 when C was considered high level, and most games were written in assembler. C has an elegant simplicity about it that both enables you to implement the high level features in the way you want to, without being able to obfuscate your work with hidden or automatically generated functionality. Whenever I've worked on all C codebases I've always had less pain and more productivity than C++.

gte910h3• 14 years ago

Object oriented C is a great paradigm when done right.

pjmlp2• 14 years ago

Problem is that 99% of the developers that work in the industry usually do it wrong.

LiveTheDream• 14 years ago

Can we get a [2009] in the headline?

lelele2• 14 years ago

For me, the hidden cost of C++ was the mental overhead of programming in it. I had to be constantly alert about the many many ramifications of almost every line I wrote.

The hidden cost of C++ (2009)

Related Stories