5 ms·
And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywh
by icefox 17y ago
And the hidden cost of using Java is that there is a JVM! These are only hidden to developers who don't really know C++. If you have virtual functions everywhere and have api that encourages copy or anonymous constructors you get what you asked for. And any profiler worth its salt should be able to show you what is really happening so you can quickly fix it.
For a game shop who is worried about performance there are many little things you can have your developers do to prevent the compiler from doing many of these things and you should have it be part of your normal API reviews to make sure that developers follow them. A simple example
class Box {
public:
Box(int x);
};
class Foo {
public:
Foo(Box a)
};
...
Foo(1);
...
Pop Quiz: How would you change Foo (or the whole api) to cause Foo(1) to cause an error?
- bendotc 17y agoI'm pretty sure the author was comparing C++ to C, not to Java, but that's kinda beside the point, because as the article says, "The real hidden cost is that now, instead of looking at one piece of source -- the function itself -- I need to look at up to four different classes. Add possible ancestors to find out if a call is virtual." Put another way, the performance details we so often care about in projects for which we're using C++ are often non-local to the calling site. In order to know the performance characteristics of "a = foo(b, c)" I need to know a lot of things about the types of a, b, c, and foo, in addition to knowing what "foo" does inside its curly braces. In contrast, while it's hard to reason about the instructions being executed in Java in the same way we do in C or even to a large degree in C++, the types of a, b, c, and foo don't really matter, since passing in b and c is always a pass by reference or a primitive value copy, and foo is pretty much always going to be dispatched the same way (and constructors are preceded by a "new" operator at the call site, so we don't have to worry about that, either). Now, the only thing I care about is what's inside the foo method. I am of course not disputing that you need to know the language you're using. It's just that even when you know C++, if you can't trust everyone who ever touched the code, you need to check in a bunch of different places to reason about the performance characteristics of this one piece of code. Also, reasoning about the performance of C is all well and good right up until you realize that your compiler is better at translating C to assembler than you are and also, some jackass wrote a preprocessor macro called "foo" which does 18 different things. At some point, writing high-performance code is not about assuming you can guess what will happen but about seeing what's happening and trying to make something better happen. Disclaimer: it's been a good 4 years or so since I worked with Java, and on top of that, I've never cared too much about Java performance, so please take this with a grain of salt.
- groby_b 17y ago> Also, reasoning about the performance of C is all well and good right up until you realize that your compiler is better at translating C to assembler than you are The difference being that in this case, the code performs better than I assumed. Nobody minds that. In C++, the usual results are that it performs worse than assumed. Significantly worse. > some jackass wrote a preprocessor macro called "foo" which does 18 different things Yes. There is that. Thankfully, they are rare. (I'd rate the preprocessor as by far the worst part of C. Amongst other things, it costs us any number of tools that could help us reason about code)
- kmavm 17y agoPop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's code reviews? There are, after all, languages out there that do not force this insanity on us. The alternative for performance-critical applications is not Java, but C. C remains surprisingly tough competition after all these years for those rare pieces of software where programmer time is cheap compared to hardware resources. Having had non-trivial experience of both languages, reasoning about the performance of a C program is much, much easier than reasoning about non-trivial C++ programs' performance. Guesses based on local code inspection have an order of magnitude less uncertainty attached to them, which is basically what Rachel is saying here.
- dtf 17y agoUgh. Try attacking the vector math required for most games programming these days in C, using macros and magic instead of classes and templates and operator overloading. I'd rather blow my own leg off with a bit of C++ any day.
- deleted 17y ago[deleted]
- timr 17y ago"Guesses based on local code inspection have an order of magnitude less uncertainty attached to them" ...which is why we have profiling tools that make it easy to detect performance hotspots. For the other 95% of our code, the expressiveness of C++ makes it easier to do more work in fewer lines. This is a far more important metric to any working developer (and it's a big reason why languages like Python and Ruby are popular.) Also, you're exaggerating. I wrote C++ for well over a decade, and I wrote in C before that, and used it again in graduate school for my research. While I can count on one hand the number of times that I was affected by "hidden" C++ costs, I was routinely blindsided by bad C code, where pointer errors, type safety gotchas, and inefficiency due to aliasing are de rigeur. You'd be crazy to write a non-trivial application in C today that wasn't an operating system.
- bendotc 17y agoOh, and make Box's constructor explicit.
- groby_b 17y agoYes, there are many things I could do. Once I'm done with writing all that boilerplate, I'm more or less down to C code with nice namespaces.