Writing in C for Performance?

Question

I know I have quite frequently heard that C typically has a performance advantage over C++. I didn't really think anything else of it until I realized that MSVC doesn't even seem to support the newest standard of C, but the newest it supports it C99 (as far as I know).

I was planning on writing a library with some code to render in OpenGL so I could reuse it. I was planning to write the library in C since any performance increase is welcome when it comes to graphics.

But would it really be worth it? The code using the library would likely be written in C++ and I prefer to code in C++ generally.

However, if it would produce even a small difference in performance, I would likely go with C.

It may also be noted that this library would be something that I would make to work across Windows/OS X/Linux, and I would likely compile everything natively (MSVC for Windows, Clang or GCC for OS X, and GCC for Linux...or possibly Intel's compilers for everything).

I've looked around and I've found some benchmarks and such, but everything I've seen has dealt with GCC rather than MSVC and Clang. Also, the benchmarks don't mention the standards of the languages used. Anyone have any thoughts on this?

EDIT: I just wanted to share my viewpoint on this question after a couple years more experience. I ended up writing the project I was asking this question for in C++. I started another project around the same time in C as we were looking to get out any small amount of performance we could and needed the project to be linkable in C. A couple months ago, I reached the point where I really needed maps and advanced string manipulation. I knew of the abilities for this in the C++ standard library and eventually came to the conclusion that those structures in the standard library would likely outperform and be more stable than maps and strings I could implement in C in a reasonable amount of time. The requirement to be linkable in C was easily satisfied by writing a C interface to the C++ code, which was done quickly with opaque types. Rewriting the library in C++ seemed to go much faster than when writing it in C and was less prone to bugs, especially memory leaks. I was also able to use the standard library threading library, which has been much easier than using platform-specific implementations. In the end, I believe writing the library in C++ led to great benefits with possibly a small performance cost. I haven't benchmarked the C++ version yet, but I believe that it may even be possible that I have gained some performance by using standard library data structures than ones I wrote.

Answer 1

I guess people often claim that C is faster than C++ because it's easier to reason about performance in C. C++ is not inherently slower or faster, but certain C++ code might obscure hidden performance penalties. For example, there can be copies and implicit conversions which are not immediately visible when looking at some piece of C++ code.

Let's take the following statement:

foo->doSomething(a + 5, *c);

Let's further assume that doSomething has the following signature:

void doSomething(int a, long b);

Now, let's try to analyse this particular statement's possible performance impact.

In C, the implications are quite clear. foo can only be a pointer to a struct, and doSomething must be a pointer to a function. *c dereferences a long, and a + 5 is integer addition. The only uncertainty comes from the type of a: If it's not an int, there will be some conversion. but apart from that, it's easy to quantify the performance impact of this single statement.

Now let's switch to C++. The same statement can now have very different performance characteristics:

1. doSomething could be a non-virtual member function (cheap), virtual member function (a little more expensive), std::function, lambda... etc. What's worse, foo could be a class type overloading operator-> with some operation of unkown complexity. So in order to quantify the cost of calling doSomething, it's now necessary to know the exact nature of foo and doSomething.
2. a could be an integer, or a reference to an integer (additional indirection), or a class type which implements operator+(int). The operator could even return another class type which is implicitly convertible to int. Again, the performance cost is not apparent from the statement alone.
3. c could be a class type implementing operator*(). It could also be a reference to a long* etc.

You get the picture. Due to C++'s language features, it is much harder to quantify a single statement's performance costs than it is in C. Now in addition, abstractions like std::vector, std::string are commonly used in C++, which have performance characteristics of their own, and hide dynamic memory allocations (also see @Ian's answer).

So, bottom line is: In general, there's no difference in the possible performance achievable using either C or C++. But for really performance-critical code, people often prefer using C because there are way less possible hidden performance penalties.

Answer 2

Code written in C++ can be faster than in C, for certain types of tasks.

If you prefer C++, use C++. Any performance issues are going to be insignificant compared to algorithmic decisions of your software.

Answer 3

One of the design principles of C++ is that you don't pay for features you don't use. So, if you write code in C++ and avoid features that don't exist in C, then the resulting compiled code should be equivalent in performance (though you would have to measure this).

There is negligible cost to using classes, for example, compared to structs and a bunch of associated functions. Virtual functions will cost a bit more, and you'd have to measure the performance to see whether it matters for your application. The same goes for any other C++ language feature.

Answer 4

One reason that higher level languages are sometimes slower is that they can hide behind the scenes a lot more memory management than lower level languages.

Any language (or library, API, etc) that abstracts away low level detail can potentially be hiding costly operations. For example, in some languages simply trimming trailing whitespace from a string results in a memory allocation and a copy of the string. Memory allocation and copying in particular can get expensive if they are happening repeatedly in a tight loop.

If you wrote this kind of code in C it would be blatantly obvious. In C++ possibly less so, because the allocations and copying could be abstracted away into a class somewhere. They might even be hidden behind an innocent-looking overloaded operator or copy constructor.

So use C++ if you want to. But don't be beguiled by the seeming convenience of abstractions when you don't know what lies beneath them.

Of course, use a profiler to find out what is really slowing your code down.

Answer 5

For what it's worth, I tend to write my libraries in C++11 for the enhanced feature set. I like being able to take advantage of things like shared pointers, exceptions, generic programming, and other C++ only features. I like C++11 because I've found that a good bit of it is supported on all of the platforms I care about. Visual Studio 2013 has a lot of the core language features and library implementations ready to go and supposedly is working on adding the remainder. As you well know, Clang and GCC both support the entire feature-set as well.

With that said, I recently read about a really great strategy regarding library development that I think is directly relevant to your query. The article is titled "A C error handling style that plays nice with C++ exceptions" Stefanu Du Toit refers to this strategy as an "hourglass" pattern. The first paragraph of the article:

I've written a lot of library code using what I call an "hourglass" pattern: I implement a library (in my case, typically, using C++), wrap it in a C API which becomes the only entry point to the library, then wrap that C API in C++ or some other language(s) to provide a rich abstraction and convenient syntax. When it comes to native cross-platform code, C APIs provide unparalleled ABI stability, and portability to other languages via FFIs. I even restrict the API to a subset of C that I know is portable to a wide variety of FFIs and insulates the library from leaking changes in internal data structures — expect more on that in future blog posts.

---

Now to address your primary concern: performance.

I would suggest, like many of the other answers here, that writing code in either language would work just as well on a performance standpoint. From a personal standpoint, I find writing correct code in C++ to be easier due to the language features, but I think that's a personal preference. Either way, compilers are really smart and tend to write better code than you anyways. That's to say that the compiler will likely optimize your code better than you could.

I know a lot of programmers say this, but the first thing you should do is write your code, then profile it and make optimizations where your profiler suggests you do. Your time will be much better spent producing features and then optimizing it once you can see where your bottlenecks are.

---

Now for some fun readings about how language features and optimizations can really work in your favor:

std::unique_ptr has zero overhead

constexp allows for compile-time computation

move semantics prevent unnecessary temporary objects

Answer 6

The performance difference between C++ and C is not due to anything in the language, strictly speaking, but in what it tempts you to do. It's like a credit card vs. cash. It doesn't make you spend more, but you do anyway, unless you're very disciplined.

Here's an example of a program written in C++, which was then aggressively performance tuned. You need to know how to do aggressive performance tuning, regardless of language. The method I use is random pausing, as shown in this video.

The kinds of costly things C++ tempts you to do are excessive memory management, notification-style programming, trusting your program counter to multi-layered abstraction libraries (as @Ian said), slowness hiding, etc.

Answer 7

C doesn't have any performance advantage compared to C++ if you do the same things in both languages. You can take any old C code written by any decent C programmer and turn it into valid and equivalent C++ code, which will run just as fast (unless both you and your compiler know what the "restrict" keyword does and you use it effectively, but most people don't).

C++ can have have hugely different performance, either slower or faster, if (1) you use the standard C++ library to do things that can be done much faster and easier without using the library, or (2) if you use the standard C++ library to do things much easier and faster than by reimplementing the library in bad C.

Now one important consideration: Much more important than the language is how much time I spend on making the implementation fast. I would say it is easier to creat working C++ code, and then you have more time to make it fast. And C++ makes it easier to put performance critical things into some class so that ugly complex and fast speed-optimised code isn’t visible to the caller. And with more time spent on optimisations, your C++ code can run substantial faster.