Comparing C and C++ usage and performance with a real world project

The minor discussion on the C version's memory leaks reminded me of a neat trick. If you're developing a short lived application, like pkg-config, you can opt to never deallocate. i.e. leak everything. In lightweight, short lived applications there's usually not a lot of incentive to deallocate; your application will never use much memory anyway and the deallocations waste time.

You can think of it like treating C as a garbage collected language, except the garbage collection cycle occurs only once at the end of the program :P

It really can be an effective trick. Deallocation isn't free, and under certain loads can be quite expensive.

The 1000+ leaks in the C version might actually be what's giving it the slight run-time advantage.

Re: Comparing C and C++ usage and performance with a real world project

#5

Post by userbinator » Sun, Sep 03, 2017, 3:37 PM UTC

I'm going to be the first to point out the one major flaw in this comparison: "plain C using GLib" is not comparable to "C++ standard library only" --- what should be compared is "C++ standard library only" and "C standard library only". Reimplementing pkg-config in pure C without GLib would be necessary for that.

As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free". I've seen and done this many times myself.

I've seen projects that turned from simple and straightforward to buggy (and harder to debug), slow, and bloated because someone decided they wanted to "use C++" and would try to make use of as many "modern C++" features as they could.

Converting an existing C program into C++ can yield programs that are as fast, have fewer dependencies and consume less memory. The downsides include a slightly bigger executable and slower compilation times.

My experience has been the complete opposite.

Re: Comparing C and C++ usage and performance with a real world project

#6

Post by andreasgonewild » Sun, Sep 03, 2017, 3:39 PM UTC

fpgaminer wrote: post #4

The minor discussion on the C version's memory leaks reminded me of a neat trick. If you're developing a short lived application, like pkg-config, you can opt to never deallocate. i.e. leak everything. In lightweight, short lived applications there's usually not a lot of incentive to deallocate; your application will never use much memory anyway and the deallocations waste time. You can think of it like treating C as…

Or take that even further and allocate a slab that's big enough to last the entire runtime and send malloc on vacation. It's worth repeating, with todays focus on web-frameworks, cloud-providers and dogmatics these ideas are slipping into obscurity; which is a shame given how beneficial they can be if your program fits the use case.

Re: Comparing C and C++ usage and performance with a real world project

#7

Post by jgh » Sun, Sep 03, 2017, 3:40 PM UTC

userbinator wrote: post #5

I'm going to be the first to point out the one major flaw in this comparison: "plain C using GLib" is not comparable to "C++ standard library only" --- what should be compared is "C++ standard library only" and "C standard library only". Reimplementing pkg-config in pure C without GLib would be necessary for that. As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-…

Reminds me of this anecdote I came across on the internets one time: https://groups.google.com/forum/message/raw?msg=comp.lang.ad...

Re: Comparing C and C++ usage and performance with a real world project

#8

Post by humanrebar » Sun, Sep 03, 2017, 3:42 PM UTC

Interesting project!

The C++ version uses many memory allocations. Using allocators some in the C++ program would certainly cut down on the number of allocations. It would also be interesting to see if doing so also improved performance.

Similarly, it would be interesting to see if using the C++17 string_view (or the gsl version if C++17 isn't available to you) instead of `const string &` parameters affected performance.

Finally. I see that in most (all?) cases, objects are returned by value, not returned through reference parameters or pointers. It's interesting to see that that choice didn't compare poorly to a C implementation.

Re: Comparing C and C++ usage and performance with a real world project

#9

Post by rjzzleep » Sun, Sep 03, 2017, 3:44 PM UTC

according to dan saks, who apparently to some people is famous c++ is faster than c (well in the test setup he describes below)

https://accu.org/content/conf2015/DanSaks-Embedded%20Program...

    Language   Design Implementation  Relative Performance
    either any inline 1 (fastest)
    C++ polystate non-inline 1.56 x fastest
    C++ bundled non-inline 1.65 x fastest
    C polystate non-inline 1.70 x fastest
    C bundled non-inline 1.79 x fastest
    C++ unbundled   non-inline 1.82 x fastest
    C unbundled   non-inline 1.95 x fastest

He furthermore argued that the biggest mistakes C++ developers did to kill the adoption of C++ for C programmers was to diverge from the previous line of "C++ is a better C" to "if you're using C++ as a better C you're doing it wrong"

https://www.youtube.com/watch?v=D7Sd8A6_fYUI

(I have no skin in the game, I was just curious to see if it's worth looking at rust for embedded when I came across that talk)

Re: Comparing C and C++ usage and performance with a real world project

#10

Post by bch » Sun, Sep 03, 2017, 3:46 PM UTC

userbinator wrote: post #5

I'm going to be the first to point out the one major flaw in this comparison: "plain C using GLib" is not comparable to "C++ standard library only" --- what should be compared is "C++ standard library only" and "C standard library only". Reimplementing pkg-config in pure C without GLib would be necessary for that. As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-…

> As for the "memory leaks" --- I haven't looked at the source, but something whose runtime is very short-lived, like pkg-config, may be very well justified in allocating and never freeing, letting the process exit itself be the "ultimate free". I've seen and done this many times myself.

This makes sense, and then somebody has a vision for a use case beyond the original imagination, goes to turn the code into a library and spends countless hours smartening up lazy resource management. Whether the original author should be "more responsible" is open for debate, but I've personally run into the above situation, and only mention for another perspective on The Life of Code.

Edit: s/coffee/code/