Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

nibblestew.blogspot.com

Post reply on HN
Print view View original

41–50 of 140 posts

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

#41

Post by coldtea »

bch wrote: post #10
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 libra…

>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.

That's THEIR problem then.

Why should the original author care for that?

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

#42

Post by TickleSteve »

blub wrote: post #32
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-…

Never freeing is sloppy, it means resource handling was likely not thought through. I would be concerned about non-memory resource handling in particular. If one must use this "trick", it's better to think things through, add the appropriate release calls and then somehow replace the release function with a no-op. Anyway, you're welcome to take a C++ project and translate it to a fast C project with fewer dependencie…

Never freeing is common practice in embedded systems where you should be pre-allocating all data (after worst-case analysis). This removes any possibility of fragmentation issues, etc. Many coding standards forbid dynamic allocation for embedded & real-time systems also for safety & reliability reasons.

It is not unusual to have allocate-only heaps for exactly these reasons.

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

#43

Post by astrodust »

ausjke wrote: post #34

In general there is no way a C program(apple to apple, comparing to its similar c++ version) will be larger than C++, be it static, shared libraries included, or whatever.

Today, sure, but there's no assurance that this will be true in the future. If more compiler-friendly extensions are added to C++ to help it generate tighter, more nimble machine code because it's given more leeway in optimizations, then the C++ code could be substantially smaller. C doesn't seem as interested in adopting some of the C++ paradigms that could make optimization better, tools like formalized iterators and such.

There's been various attempts at pre-compiling the headers over the years, but the results have always been, for various reasons, less than perfect.

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

#44

Post by astrodust »

dingo_bat wrote: post #33

I knew C++ compilation was slow but 30x slower? I'm sure the compile-time memory usage will also show a similar trend. It would be interesting if somebody could explain the reason for this disparity.

The problem, by and large, is that C++ is heavily dependent on header files to implement the Standard Library. It's largely templated, which means there's no way to make a pre-compiled version, the code generated varies wildly depending on the types involved.

C has relatively simple header files, they usually contain structs, function signatures, and a bunch of macros. They're easy to parse and apply by comparison, plus don't tend to be as deeply nested.

If C++ ever adopts the Pascal-style "module" extensions that have been kicking around in various proposals compile times could shrink by several orders of magnitude.

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

#45

Post by nly »

khitchdee wrote: post #15

If you ignore the protection mechanisms and the class heirarchy built into C++, then a C++ class is like a C struct that can contain function pointers. For many programs this is all that's needed, and the amount of overhead involved in using such an approach to creating objects is obviously lower. So there's no question C will always be faster. It's only when you need protection and class heirarchies that C++ benefit…

> a C++ class is like a C struct that can contain function pointers.

No, it's not. Calling an ordinary class member function in C++ has exactly the same overhead as calling a function in C. Even virtual functions in C++ are not the same as putting function pointers in a C struct (they live in a separate data structure called the vtable).

> the protection mechanisms and the class heirarchy

All C++ protection mechanisms occur at compile time and have no runtime overhead. Non-virtual inheritance hierarchies have the same overhead as C struct composition (because under the covers the memory layout is the same).

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

#46

Post by Matthias247 »

dingo_bat wrote: post #33

I knew C++ compilation was slow but 30x slower? I'm sure the compile-time memory usage will also show a similar trend. It would be interesting if somebody could explain the reason for this disparity.

Based on your dependencies and programming style it might be less or more, but it sounds not unreasonable.

I wrote the same program in two environments once: C++ with stdlib and boost, and C++ purely using QT abstractions. The second one already compiled in 1/5th of the time. I guess that's because with QT the headers are small because most implementations are hidden behind pointers (PIMPL), while with boost you often pull in lots of code through headers and compile dozens of specializations of similar types to avoid indirection costs.

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

#47

Post by red75prime »

pcwalton wrote: post #39
humanrebar wrote: post #19

Earlier quoted context omitted.

> "if you're using C++ as a better C you're doing it wrong" As far as correctness and safety goes, this is still true. It's difficult to scale systems-level programming to large teams. C++ gives the opportunity for more explicit semantics and more aggressive compile-time checks. C can scale well and can be used safely, but you need to do a lot more through convention (always call xyz_Create and xyz_Destroy in pairs!)…

> D, Rust, OCaml, and a few other projects are interesting in this space since they provide some of the same benefits as C++ with respect to correctness and safety. Can you name a correctness and safety benefit that C++ has that these programming languages do not?

Probably there are no such benefits. But taking the less serious approach, LLVM's -fsanitize=undefined could be thought of as the one.

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

#48

Post by jcelerier »

khitchdee wrote: post #15

If you ignore the protection mechanisms and the class heirarchy built into C++, then a C++ class is like a C struct that can contain function pointers. For many programs this is all that's needed, and the amount of overhead involved in using such an approach to creating objects is obviously lower. So there's no question C will always be faster. It's only when you need protection and class heirarchies that C++ benefit…

> So there's no question C will always be faster

Except that the poster above you shown that the opposite was true. The exact same program was written multiple times with C structs and with C++ classes and,

"Except for the non-inline unbundled monostate in C++, every non-inline C++ implementation outperformed every non-inline C implementation."

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

#49

Post by humanrebar »

khitchdee wrote: post #31
humanrebar wrote: post #24

Earlier quoted context omitted.

> It's only when you need protection and class heirarchies that C++ benefits you. Well, need is a strong word. You might not need better correctness while still coming out way ahead by using C++.

Protection implies a much more complex structure to represent an object and class heirarchies and inheritance imply the need for a runtime. Both these overheads come at a cost. It's the nature of the program you are wriitng that determines whether you will come out ahead. If you were writing a codec, say, you would not use C++.

Not necessarily. A trivial scope guard initialized with a lambda has basically no overhead versus the equivalent be-really-careful approach in C.

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

#50

Post by andrepd »

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

"Using C++" does not mean "Using lots and lots of features of C++ just because". That some people do that is hardly a criticism of C++, more of the lousy programmers that write software like that.
Post reply on HN