The Hidden Cost of C++ • Hacker News Board

Re: The Hidden Cost of C++

#61

Post by kmavm » Wed, Oct 21, 2009, 4:03 AM UTC

blub wrote: post #39

groby_b wrote: post #31

Earlier quoted context omitted.

I propose a lower level than C++ for the kernel, and a higher level for the rest. C++ is simply at the wrong abstraction level. Oh, and I don't want to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of. You did notice I was talking about game development, right? ;)

My reply was not targeted at you and I don't do game programming. Anyway: * smart pointers don't need an OS. * for me, C++ is at the exactly right abstraction level to allow me to use only C++ instead of "C++ + other language" or "other language and C for speed". Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages.

As somebody who's given you a hard time up thread, and who has advocated the C + HLL approach, let me say: you're right, I now think that approach is naive. It's really difficult to share data across the C/HLL boundary, and in normal applications the data representation is the most likely place to need performance tweaking, and thus you often want to represent it in "LLL" data structures.

The mappings of C/C++'s type system into an HLL is almost intractable. What if there's a union somewhere? You could have distinct HLL and LLL representations, sync'ed either lazily or eagerly, but that's really, really complicated.

Unfortunately, you can only apply "C* + HLL" when there's a nice, clear, never-shifting boundary between the HLL and LLL parts. So, language selection is not a false dichotomy; you really do have to choose "mostly one."

(edit: typo, non-sense sentence. Sorry folks, running a fever.)

Re: The Hidden Cost of C++

#62

Post by ecaradec » Wed, Oct 21, 2009, 7:16 AM UTC

JoeAltmaier wrote: post #2

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Founded and fixed in exactly 5 seconds with a profiler. So what ?

Re: The Hidden Cost of C++

#63

Post by groby_b » Wed, Oct 21, 2009, 1:08 PM UTC

dkarl wrote: post #55

groby_b wrote: post #45

Earlier quoted context omitted.

The difference is that the API can change without visible API changes. If you add a virtual destructor to your class, I won't notice that by looking at the call site. I've just been burdened with additional overhead, without knowing about it. And yes, large projects have large project issues. It is kind of telling that C++ needs an entire tome on large project issues, though... (Lakos, Large Scale C++ Software Design…

The difference is that the API can change without visible API changes. I don't understand this at all. The performance of a C function can change without any change to the function signature. Even the destructor scenario can happen invisibly in C code for any type that already has a cleanup function. No matter whether the cleanup function is defined as "int myproj_FooCleanup(struct Foo* foo) {...}" or "myproj::Foo::~…

I'm not talking about the performance of the function itself, I'm talking about the overhead incurred. That can't change in C.

Also, just adding a virtual destructor (without any functionality) adds cost. And unfortunately, you need to if your class happens to become a base class.

Re: The Hidden Cost of C++

#64

Post by JoeAltmaier » Wed, Oct 21, 2009, 3:37 PM UTC

hazzen wrote: post #36

JoeAltmaier wrote: post #2

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Do you know how to fix almost every one of these cases for good? Just don't allow implicit copying of your classes. Problem solved. If someone tries to write that horrible code, they can't. This is more a question of knowing what you are doing and less of C++ sucking. C doesn't solve this - you still have to know what you are doing there or you end up shooting yourself in the foot. I much prefer having an interface w…

Of course! However the original author of the offending code didn't know to define private X(X&), so had the problem. C++ is a power saw; you can cut off your hand.

Re: The Hidden Cost of C++

#65

Post by JoeAltmaier » Wed, Oct 21, 2009, 3:38 PM UTC

psyklic wrote: post #56

JoeAltmaier wrote: post #2

I fixed a single line of code that drove our embedded processor to 50% cpu - it called 5 ctor/dtors. Changing it to a ref arg with a ref return, and dropped to under 10%. And yes, class defs had to be redeclared, the line of code was unchanged. Very indirect, utterly beyond the original authors comprehension.

Why do you use C++ for an embedded processor?

No reason not to. Control your runtime and it's fine even for OS work.

Re: The Hidden Cost of C++

#66

Post by [deleted] » Fri, Oct 23, 2009, 6:29 PM UTC

groby_b wrote: post #23

aceofspades19 wrote: post #18

Earlier quoted context omitted.

And you can make your code slower by changing it! Oh the horror. C++ is, imo, a good language for a lot of domains. What goes wrong is when people try to use all of the features that C++ offers instead of just using the ones applicable to their domain, eg. I don't think you would really want to use exceptions in embedded programming. If you are on a platform where performance is the key, then you should be careful of…

The point is not that I can make the code slower by changing it. The point is that it can get slower by changes to the API, without any changes to functionality.Made by somebody else, unintentionally impacting me. Let me ask you this: Have you ever worked on a large scale C++ project that didn't have performance issues? Or memory issues?

[deleted]