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

11–20 of 140 posts

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

#11

Post by userbinator »

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…

That's the classic KISS/YAGNI vs. (not sure if there is an initialism for it) robust extensible modular best practices etc. debate, for which there has been much bikeshed from both sides.

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

#12

Post by striking »

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…

It's stop-the-world garbage collection, where collection only happens when the world ends.

Side note wrt deallocations being somewhat slow: could something like Boehm conservative GC speed that up, by grouping all the deallocations together, or by doing them on a separate thread?

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

#13

Post by jamiek88 »

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

The ultimate in garbage collection indeed!

Highly recommend reading that short tale! This lore is slowly being forgotten, thanks for that link.

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

#14

Post by WalterBright »

rjzzleep wrote: post #9

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

Over in D-land we've embraced the concept of using D as a "better C" :-)

https://dlang.org/blog/2017/08/23/d-as-a-better-c/

This is not in the sense of tossing away C coded programs wholesale and rewriting it in D, but incrementally using D here and there for parts of a C program. That way, you've always got a working, usable program.

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

#15

Post by khitchdee »

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++ benefits you. That benefit is mainly one of better code organisation.

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

#16

Post by sebcat »

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.

And, instead of using pointers into said memory, use indices so that the slab can be reallocated, or just mmap more pages following the slab if you own the process address space. Also, align properly. And having guard pages is always nice. Freeing on exit too, one single deallocation is pretty cheap.

I've seen programs building ASTs with hundreds of millions of nodes, where all the nodes were allocated by a separate malloc call, and ref-counted... More than one-third of the startup time (which was counted in minutes) was calls to malloc and free. Some optimizations were made, but in the end we ended up reducing the size of the AST instead of fixing the allocations.

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

#17

Post by [deleted] »

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

[deleted]

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

#18

Post by taneq »

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

> My experience has been the complete opposite.

Keyword: "can".

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

#19

Post by humanrebar »

rjzzleep wrote: post #9

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

> "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!) and through runtime checks (calls to assert, unit testing).

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. Some are plausibly better in theory, though I'm not aware of huge, say, Rust projects that approach the size of huge C++ ones.

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

#20

Post by agumonkey »

striking wrote: post #12
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…

It's stop-the-world garbage collection, where collection only happens when the world ends. Side note wrt deallocations being somewhat slow: could something like Boehm conservative GC speed that up, by grouping all the deallocations together, or by doing them on a separate thread?

OS delegated one pass GC.
Post reply on HN