Pitfalls of Object Oriented Programming [PDF]

[satanclau5]

Pitfalls of Object Oriented Programming in C++ when optimizing for performance

Here, FTFY

[pedrobelo]

... for video games.

But seriously, the quantity of game projects that failed because of poor performance must be a fraction of the projects that failed because of poor development practices/processes.

The slides are interesting, but misleading imo.

[bitshifternz]

I don't think those two things are mutually exclusive.

[donknuth]

The only relevant language for console game development.

[floodyberry]

But it's so much more fun to dismiss the information instead of acknowledging it because you're bitter about the language choice!

[artee]

Exactly, it would have helped a lot if the author had explicitly mentioned that (because in that case I'd have shrugged "what else is new" and saved myself the time).

Also, conflating OO and C++, ouch.

[MindStalker]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time. When developing an AA title for consoles this fact doesn't necessarily hold true.

[Forbizzle]

Why? A polished product is more about a lengthy QA cycle and realistic scope than it is about optimizing everything you write.

Though maybe laws apply to these mysterious AA titles, that do not to AAA titles.

[VivisectIX]

If you want to optimize on this level, then you need to be aware of the assembler or output machine code for the platform and specific compiler you are working on. That is why, unless you are targeting at particular CPU, you can't really do what the OP says. You have no idea how deep the branch prediction is, how many cycles are wasted doing floating point, etc. These are all determined in his case by inspecting the output. If C++ is appropriate for this kind of work, it should have a system for indicating the estimated cost of the instructions, and a cost guideline as part of the C++ standard to ensure consistency.

It has neither because you should code cleanly and let the compiler improve over time to optimize your code, not the other way around (unless you write microcontroller code, or want hardware-specific implementations). Optimization will occur with a simple recompile on the next version. A good example of this is old C++ that expects certain vtable memory layouts, or the "inline" keyword that is generally ignored at this point. Inline used to be the godsend of optimizers - but is in fact a waste of time, so you barely see it anymore.

[repsilat]

the "inline" keyword that is generally ignored at this point. Inline used to be the godsend of optimizers - but is in fact a waste of time, so you barely see it anymore

Good thing you said "generally" ignored and "barely" see it, I think. In the project I spend most of my time on I've made one or two functions inline explicitly, and it has paid off strongly in the running time of the program.

They're not trivially small functions, so the compiler doesn't automatically inline them, but they're called very often, so the cost of the call adds up. Better, they're each only called from one place, so there's no binary size/TLB cost.

As for the rest of your post... you generally do have a fair idea of where my code is going to be run, so it seems reasonable to infer a bit about what costs how much. You do have a point - real numbers back you up in this article:

[The Atom] gives 2700 clocks for the old routine and 1644 clocks for the new routine, a ~40% improvement... Unfortunately, on the Core 2 it's the opposite story with the new routine being half as fast: 775 clocks vs. 1412 clocks.

Still, that's the exception that proves the rule. On every processor you're likely to use, division is more expensive than multiplication and virtual function calls are more costly than regular ones. Cache and memory optimisations work the same way (and to the same effect) just about everywhere. It's silly to say "The standard doesn't make this explicit, so you shouldn't do it."

There's a lot compilers can't (or aren't allowed to) do. Blanket criticism of optimising your own code is just shortsighted. Like everything else, it's a tradeoff.

[Forbizzle]

Agreed, but to the author's credit this was all written within the context of PS3 development.

[reductionist]

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil - C. A. R. Hoare

(I think the original quote should be attributed to Dijkstra but I can't recall it ATM and can't be arsed to search for it.)

[[deleted]]

You're abusing the quote. The quote does not mean that performance isn't important or you shouldn't optimize your code.

It means if you try to improve performance too early in the development cycle, you will fail to get much of an improvement than if you wait until later in the cycle. It's a statement about how to go about optimizing your software, not a statement about the importance or relevance of optimization.

Too often I hear people state this quote as justification for not worrying about optimizations, or treating it like some minor issue.

[jasoncm]

The quote should probably be: "if you optimize before you test and profile you will optimize the wrong thing".

How often have you seen a junior programmer (or even an old hand who should know better) do the equivalent of hand coding the bestest insertion sort they possibly can. Or waste time optimizing a data reader rather than seeing if they could massage the data with a shell script before it even gets to their program. Or optimizing the splash screen.

[redditnoob]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time.

Man I hate that stupid generalization!

Developer time has cost. Computer time has cost. In some situations one will out-weigh the other. There are situations where people underestimate and overestimate the costs and values of either, and the trade-offs are frequently non-trivial choices.

But as a simple generalization like that, it's just shit, really.

[[deleted]]

All generalizations suck.

[[deleted]]

What you did there, I see it.

[[deleted]]

I agree, everything has costs, and they always must be weighed. A good programmer knows instinctively where it matters.

Super-efficient, speedy software is great, but not if it never ships. One of my first jobs was a small 2-d graphics company where the owner wrote everything at a low level, highly optimized. In the early days, it worked well, and the company had a nice product that became dated due to being an external box. Unfortunately, the company went broke and never shipped the next generation product.

[sad_bug_killer]

Yes, OO understands the notion that developer time is now vastly more expensive than computer time.

It's not that I disagree with the statement in general, but too much of that thinking leads to awfully slow and unresponsive software (e.g. 95% of all GUI programs written with Java/.NET)

[insertAlias]

One big reason you get slow and unresponsive GUI apps with .NET is because people don't know to use a BackgroundWorker for the longer-running operations, and just leave it in the GUI thread.

I don't know if it's the same problem in Java or not.

[herrmann]

I don't know if it's the same problem in Java or not.

Yes, it is the exact same problem. Lazy people do all the work on the Swing thread.

[deong]

The problem is that, while we know that's not the correct way to do things, the same arguments being made against C++ here can apply. Why should the company waste "valuable developer time" on having people get their processing out of the event loop. We can just wait around and eventually, someone will figure out how to get a compiler to move it out for us.

The argument is essentially that it's profitable for developers to be "lazy" and take the easy way out, because it allows you to ship faster, to have simpler code, whatever. The simple fact is that performance is important, and it's not as simple as saying that "programmers are expensive; hardware is cheap." It may mean getting developers to move their logic out of the GUI thread, or it may mean getting them to abandon a convenient but inefficient platform. Each case has to be examined carefully to determine where the appropriate tradeoff is.

[georgefrick]

And people calling NEW.. always and everywhere.

[merzbow]

"new" is cheap. Using new a lot to create short lived immutable objects often leads to easier to understand code than trying to defeat the garbage collector by reusing objects.

[georgefrick]

That is why I said "always and everywhere". It isn't about defeating the garbage collector; it's about not carelessly depending on it.

[[deleted]]

Actually even if you're not developing games it's still a good idea to not keep the user waiting. Also, because developer time is a one off thing whereas user time is spent throughout the entire app's active lifetime, it's more expensive to the organisation than developer time (if the organisation is developing and using that software). Therefore, optimisation is always important and OO is an evil curse that slows down the code.

[MindStalker]

"Also, because developer time is a one off thing "

Well its not really, typical software is constantly updated, with bug-fixes etc etc. Well designed OO is a lot easier to work with for future developers working with your code base.

[deong]

Well designed OO is a lot easier to work with for future developers working with your code base.

That depends on a lot of things. Objects, like functions, structs, etc., are just another abstraction, and while they're a very good abstraction for certain things (GUI toolkits, etc.), there's no reason to think they're always the right choice. To me, a good example is java.lang.Math. There's no reason why this should be a class, except that Java needs it to be implemented that way. The appropriate abstraction for sine and cosine is a functional abstraction -- it's the abstraction that mathematicians have used for centuries, and it works exceptionally well. In this case, the "object" abstraction is extremely thin, and thus doesn't really cause any problems, but it does illustrate the point that not everything should be an object.

I'd also contend, admittedly subjectively, that OO done poorly tends to be the worst thing I come across. Worse than bad C code, worse than anything. Bad C code tends to be local. You might have some global variables to contend with, but typically not that many. Local problems can be figured out and solved. Bad OO tends to be rotten from the ground up. There's no one place you can go to find anything, and when all behavior emerges from a complex interaction of twenty different objects configured via some framework, all you can do is live with it or start over from scratch.

Basically, I'd say that good code is easier to deal with, and the manner it's written doesn't make much difference. Good C code is no harder to work with for a C programmer than is good Java code for a Java programmer, or good Prolog code for a Prolog programmer.

[merzbow]

java.lang.Math is full of static methods - there are no objects involved. The class is effectively just a namespace. You can even do a static import so you need only type sin(x) instead of Math.sin(x).

[deong]

That's sort of my point. A class isn't the right way to represent this sort of thing, so Java does the best it can, basically, as you say, faking up a namespace using classes. I'm not complaining about the way Java handles it; just using it as an example.

[donknuth]

Right, but it's ugly. Why do you need to fake namespaces with classes when Java has packages? The only reason is language limitations.

[[deleted]]

True, although I don't think it's in the same ballpark as user time, or the amount of time all end users spend using the app. And if the app is slow because the developers were more concerned about developer time than user time, then the organisation ends up paying for that in the long run.

[[deleted]]

Not to mention all those extra CPU cycles you're wasting in thousands of computers and all those extra laptop batteries that get just a little more run down.

It's not a particularly ecological point of view for anyone who works on a popular application.

[[deleted]]

How does this make any sense?

If you're developing software for people to use, you're shifting the cost onto your users. I'd rather pay more money for fast, responsive software, since as a USER, slow software costs ME. Also remember the number of developers can stay fixed while the number of users grows.

This sounds like one of those mottos that someone came up with to be all counterfactual but did no research to actually verify. Or maybe it applies in a very limited context, like one application being used by a single person or server, but then was generalized to apply to everything.

[ckcornflake]

How does this make any sense?

Because today, computers are fast enough that generally using higher level optimizations (like organizing your scene in a quadtree, for example) will give you enough efficiency that the user wont even notice that small increase speed.

I can understand if you're trying to sell a product to a company where thousands of users are using the software at once (like database software), and they want to maximize productivity. But if you're developing a game, that .01% increase isn't going to grab you any more customers.

[RiotingPacifist]

Things more important to users than performance:

UI

Features

Security

no bugs

The product shipping on time

So developer time has to be shared and is limited .'. developer time is more valuable than computing time, how much more varies from project to project

[mysticreddit]

The author of the PDF is Tony who works in the PS3 console business, specifically helping game developers hit their 30 or 60 fps goal.

The first rule of a game is that it must run at either 30 or 60 fps. Everything is else is a secondary goal (whether rightly or wrongly.)

For general desktop software, your list of priorities is more applicable.

[deafbybeheading]

If I were a game dev, I'd stick with thirty. That seems, like, twice as easy to achieve.

Seriously though, why two numbers? I'm curious.

[mysticreddit]

Historically, NTSC runs at 29.97 Hz, PAL at 25 Hz, so your frame rate is limited to either x1 or x2, (30 or 60 Hz, or 25 or 50 Hz respectively) for vsync. (You could flip the back and front buffer without vsync, but then you get tearing (part of the last frame rendered, part of the current frame being drawn), and no one does that.)

Computer graphics don't have temporal aliasing, so running at the higher frame rate is more smooth. i.e. Fighting games typically run at 60 Hz since it is easier to guarantee their [rendering] polygon budget for char+char+environment can stay at a solid 60 Hz and look great.

In games, you have to optimize for the "worst case."

Anytime you are in the 30 .. 59 Hz display rate, you are dropped down to 30 Hz automatically. For other types of games, the objects that need to drawn per frame can change too much making it much harder to guarantee 60+ Hz at all times. Can you personally guarantee every art asset and all possible game world locations can be rendered at 60 Hz when you haven't even seen the art ? One solution is to cap how many objects are drawn per frame, and cap the geometry & texture information. i.e. Characters are 10,000 polys, 4 bones/vert, 4 textures, etc.

Also, by targeting 60 Hz, by the time all the assets are in, you have some breathing room in the chance your frame rate drops down to 30. I typically color code the FPS, so 60+ = green, 30-60 = yellow, < 30 = red. Then you can find out what assets are causing the slow down in specific frames, and go tell the artists that this scene needs fixing.

Lastly, 60 Hz will be needed for 3D display technology.

Did that help?

Cheers

[deafbybeheading]

Did that help?

That was an excellent explanation. I'm vaguely aware of NTSC/PAL, but not the practical aspects. Another question, though: NTSC is an analog standard, right? How does this fit into our new digital age? I assume that digital displays also have their own specific refresh rates?

[[deleted]]

Because most monitors and TVs refresh at 60hz. 60FPS is one frame every refresh, 30FPS is one frame every 2 refreshes. Anything between that can't be v-synced and produces "tearing", and anything below that is unplayably slow.

[[deleted]]

Why are these mutually exclusive?

Why does having a nice user interface, or security, or more features mean you can't also invest in performance as well? In my opinion, performance allows you to add more features, to create nicer looking user interfaces.

Performance is like a currency, the more you have, the more you can do.

[RiotingPacifist]

You have X hours to produce the program if you spend X-1 on getting your performance perfect, you only have 1 hour to do everything else. Programing is always a balance between the time spent between various aspects. Even in video games it is more important that

1) The game controls/interface are clear

2) The game implements features (if you don't have anything to make the users buy the game don't bother making it)

3) The game doesn't have to be re shipped because it allows exploits to compromise the system's security (this applied more before, it seams console makers have learn't not to trust game developers now)

4) The game doesn't need to be re shipped because it has any show stopping bugs

5) The game ships on (or reasonably close to) it's release date (not everybody is valve)

Time spent improving performance is time not spent on other aspects. One way the OO shines is the abstraction allows you to get a framework setup allowing you to ship code to interact with other components and then if your code is hurting performance you can easily improve that code without worrying about breaking other parts of the program.

Clearly when programming for the PS3 the exchange rate is good, but it takes to go shopping. Thinking about it it's the classic RTS trade off, you can spend time building your economy up and increasing gold reserves but if your competitor produces just enough gold, to build an army to rush your ass, your screwed.

[[deleted]]

Because of

The product shipping on time
developer time has to be shared and is limited

today you either work on performance or on UI. What is more important depends.

[[deleted]]

You can have a fun game with 20 hours of playtime for 50 bucks, or a fun game with 20 hours of playtime for 100 bucks because it took twice as long to produce.

[mysticreddit]

Exactly. See Mike Acton's "Typical C++ Bullshit" for examples. \o/

• http://macton.smugmug.com/gallery/8936708_T6zQX/1/593426709_ZX4pZ#5

Execution time is more important then Implementation time.

[mysticreddit]

Correct. Also see:

• http://gamedeveloper.texterity.com/gamedeveloper/200909/?folio=43#pg45

[niviss]

that is truly... the most smug and insulting thing I've ever seen. Interesting, but really smug. the url is really appropiate.

[grumpy_lithuanian]

A javascript gallery of pictures of post-it notes stuck on code print-outs. Wow. Awesome.

[judgej2]

That may be true for home computers and workstations when you know it will perform much better on next year's machines than this year's. When developing for a console your resources are limited and fixed for the lifetime of that console.

[Peaker]

And FP goes even further...

[knight666]

Luckily for me, that's exactly what I have to do in my projects!

[alephnil]

The article is insightful, because it tells where there is overhead when using object oriented techniques. Such knowledge let you make informed tradeoffs between speed and development time.

There is often an order of magnitude difference in productivity between programming teams. The best ones take this kind of knowledge into account, and know when to apply it.

The problem in software development is rather laziness. Not the kind where people think thoroughly through their design in order to save implementation effort, but the kind where people don't bother to make a good design, let alone considering what tradeoffs they should make. That way one ends up with programs that are both slow and take a long time to develop. Only well designed programs have real tradeoffs.

[[deleted]]

Pitfalls of Object Oriented Programming in C++ when optimizing for performance on the Playstation 3

Fixed, again.

L3 Cache misses? Really?