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

51–60 of 140 posts

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

#51

Post by tjalfi »

jgh wrote: post #7
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...

I submitted this post to HN a few months ago.

The discussion is at https://news.ycombinator.com/item?id=14233542

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

#52

Post by pandaman »

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.

In this case it's likely headers size. In native C++ programs you usually have more complex syntax (e.g. namespace is not global any more and each id has to be properly located in a hierarchy of namespaces) and, sometimes, compile-time evaluation via templates.

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

#53

Post by andrepd »

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…

That is absolutely false. C++ member functions are zero-cost abstractions, i.e. they have the same cost as any other function call. Member functions are _not_ function pointers that reside inside the struct. They don't take up space, they don't need dereferencing to call. They are just "syntatic sugar" to group functions more logically.

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

#54

Post by cperciva »

nly wrote: post #45
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 mechanism…

Calling an ordinary class member function in C++ has exactly the same overhead as calling a function in C.

Modern compilers make the same optimization for function pointers which are only ever set to one value, too.

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

#55

Post by humanrebar »

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?

I didn't mean to imply that C++ was safer somehow. I just meant that those languages are also competing in that feature space in a way that C doesn't.

And, on a pedantic level, C++ competitors can't provide exactly the same benefits of C++ because they took different approaches.

What's a key design difference among these languages? Well, C++ can mostly just #include a C header file and go with it. The other languages provide FFI mechanisms, but they each require declarations of the FFI to match the compiled C code. So theoretically there's a little more room for errors in that translation, though I doubt that's a big concern on the whole. Each of those languages have more mature module systems, which should more than make up for keeping FFI interfaces in sync with C headers.

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

#56

Post by humanrebar »

khitchdee wrote: post #25
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!)…

Agreed. It's the size and type of the project that determines the choice of language more than the newness of the language. C++ was designed to meet the requirements of certain types of projects that were coming into vogue at the time it was designed. It was not a replacement for C. Some of the structural advantages of C++ over C can be achieved in C by using generative programming for example and building in automat…

It's true that generative programming can make up for shortcomings of C. But you're pretty much writing in two languages at that point, C and whatever spec generated the rest of the C code. It's not an apples-to-apples comparison to C++.

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

#57

Post by humanrebar »

andreasgonewild wrote: post #6
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.

C++ actually supports this approach in the standard library and doing this is a really standard technique in some domains. That's what the allocator template parameter in vector and other containers is for.

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

#58

Post by aewnjfksd »

astrodust wrote: post #44
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, p…

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

I'm skeptical. Modules don't avoid the need for template instantiation.

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

#60

Post by userbinator »

andrepd wrote: post #50
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.

Unfortunately it seems that the majority of C++ code out there is like that. It could be said that C++ makes it far easier than C to introduce unnecessary abstraction and indirection, without realising the true costs.

I've noticed that using a lower-level language, where abstractions have to be built explicitly, tends to cause one to rethink the problem and often come up with an even simpler and more efficient solution, by approaching it from another direction which using a higher-level language may not even allow.

An example of this I encountered several years ago was with several coworkers who were trying with utmost effort to optimise a piece of code which the profiler had indicated was taking a substantial amount of time --- and a lot of it consisted of memory allocation and copying. They tried lots of "classic" tricks like unrolling, inlining, even reorganising the layout of several classes in an attempt to be more cache-friendly. I looked at the algorithm and realised rather quickly that the code in question was not necessary at all; some trivial modifications to code elsewhere which was using it and deleting that code completely resulted in 30x faster performance and 1/10 memory usage. Due to their background, my coworkers were stuck in the mindset that it was necessary to perform all that convoluted processing, and neglected to see the bigger picture.

Post reply on HN