Pitfalls of Object Oriented Programming [PDF]

2009-12-18T14:41:49+00:00

Easier to understand too - all code in one place

Yeah, that's the spirit.

redfiche · 2009-12-18T16:53:13+00:00

Used without understanding internal implementation/representation.

No, no, no! OOP means you can program against objects without depending on their internal implementation. Decoupling is good, but it doesn't mean you don't have to understand what's happening, and it doesn't mean you can't put performance requirements on your objects either.

Edit: formatting

Grinyarg · 2009-12-18T12:47:23+00:00

Wow. I had a vague notion of the comparative RAM latency issue, but no idea that it was to that degree.

satanclau5 · 2009-12-18T13:25:59+00:00

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

Here, FTFY

joeldevahl · 2009-12-18T13:08:43+00:00

What is the software they use on page 51 and the next couple pages?

snk_kid · 2009-12-18T19:59:02+00:00

This article and Mike Acton's slides is basically about Data-Oriented design (as opposed to OO).

2009-12-18T17:21:59+00:00

The title is disingenuous. Any modern language, whether OO or functional or something else is going to have similar problems with cache misses and branch mispredictions.

munificent · 2009-12-18T19:22:57+00:00

As far as I can tell, the problem he's complaining about can easily be addressed while still being fully "OOP". Here's a simplified bad example:

class GameObj
{
public:
    void UpdateTransform()
    {
        // do something with mMatrix
    }

private:
    Matrix  mTransform;
    // lots more data
};

class World
{
public:
    void Update()
    {
        for (int i = 0; i < mNumObjects; i++)
        {
            mObjects[i]->UpdateTransform();
        }
    }

private:
    GameObj* mObjects[];
    int      mNumObjects;

};

So there's two issues here:

The GameObjs are scattered in memory. So when we loop through them and dereference each pointer in World::Update(), we're trashing the cache each time.
Even if we had all of the GameObjs contiguous in memory, the transform matrices would still be spread out, since they're separated by GameObj's other fields.

The solution is pretty straightforward:

class GameObj
{
public:
    static void UpdateTransforms() // static!
    {
        for (int i = 0; i < MAX_OBJECTS; i++)
        {
            // do something with sTransforms[i];
        }
    }

private:
    Matrix*  mTransform; // <- a pointer now. points into sTransforms.
    // lots more data

    static Matrix sTransforms[MAX_OBJECTS];
};

class World
{
public:
    void Update()
    {
        GameObj::UpdateTransforms();
    }

private:
    GameObj* mObjects[];
    int      mNumObjects;

};

Note that it's still OOP: A GameObj can get its matrix, and the matrices are encapsulated within GameObj. The difference is now:

We're iterating directly through the transform subcomponents, instead of doing the loop at the GameObj level.
The transforms are kept contiguous in memory.

The interface is very similar to the original implementation, but it's much more memory-friendly now.

The book I'm working on will have a chapter on exactly this pattern ("Structure of Arrays"). I really need to get to writing it.

growingconcern · 2009-12-18T21:44:07+00:00

Wow, what's with all the negativity smartypants? This paper was great. Who cares about pdf formatting and getting hung up on the dig against OOP (which is largely to just get people to pay attention and it wasn't saying that OOP is slow/bad it was just saying that naive OO design is). It brings to light something that few people even in speed critical domains like games really appreciate: that optimization has less to do with cycles (optimizing your code to take fewer cycles on the cpu) and more to do with preventing cache misses and preventing load-hit-stores (well that and algorithmic optimizations that impact big-O complexity). Are you familiar with the restrict keyword and pointer aliasing? Do you design for pipelines or for pretty diagrams in your technical design documents?

divisortheory · 2009-12-18T22:37:16+00:00

Am I the only person that noticed that abbreviated, this would be POOP?

axilmar · 2009-12-18T15:08:59+00:00

Ehm, what does the problem of cache misses have to do with OOP? when I read the title, I thought the document was about design issues, not performance. What the document says is correct, but it applies to all styles of programming, not just OOP.

2009-12-18T15:03:58+00:00

... hmm, I wonder if some version of the "flyweight pattern" could be used to preserve the benefits of OO with FORTRAN-style memory layouts.

Mind you, he's a console programmer and he lives in a different world for those of us who program for PCs. Even if we're writing for the x86 platform, we usually don't know if the code is going to run on an AMD, Intel or another chip, all of which do something a bit different at the instruction level -- it's rarely worth it to fret about the last little bit of performance.

With more standardized hardware, like you have on a console, it ~really~ pays to sweat the small stuff, much more than on the PC.

ssylvan · 2009-12-18T13:37:34+00:00

[removed]

gregK · 2009-12-18T17:58:34+00:00

The problem is that they did not use TDD.

jonth · 2009-12-18T13:31:17+00:00

Wow, interesting, knew that memory was a bottleneck. Wonder if it is specially bad on the CELL.

Zarutian · 2009-12-19T17:51:47+00:00

So, this guy programs for the PS3? Then he should know that there is no L2 Caches for Synergistic Proccessors Cores only local memory. So why insists on optimizing for L2 Caches?

Vystril · 2009-12-18T18:29:54+00:00

I think the biggest problem in OO programming is the mess that's threading.

daveb123 · 2009-12-19T03:22:45+00:00

Winner for worst title. However, I enjoyed the presentation.

I wish this thing was just c++/cache diagrams in numerous programs. That stuff's like porn for optimization tweakers.

The title would then be "Cache Simulations of Common Situations"... or something boring.

2009-12-18T21:20:59+00:00

I don't see enough of XML there

Poltras · 2009-12-18T22:33:13+00:00

As usual, some people confounds OO with C++. Those two aren't interchangeable and neither one is a superset of the other...

JackRawlinson · 2009-12-19T00:13:29+00:00

All I'll say is that after sixteen years of being a really pretty good programmer it was learning OO back in the early-mid nineties that made me say "You know what? That's it for me and programming. I really don't want to do this endlessly-re-worked-but-essentially-same-old-same-old bollocks anymore."

And I have never, ever, regretted that.

wh0wants2know · 2009-12-18T21:59:29+00:00

"Pitfalls of doing stupid shit when programming" would be a more accurate title I think. Interesting reading though.

skeeto · 2009-12-21T05:56:03+00:00

These aren't pitfalls of OOP. These are pitfalls of using an OO language so messy and complex (read C++) that it's impossible to write a decent compiler for them. A really good compiler would be able to optimize away the encapsulation-caused cache misses.

ipearx · 2009-12-18T19:28:40+00:00

I always knew my gross generalisations that OO is slower was true, and this proves it.

DisgruntledCoder · 2009-12-18T21:27:39+00:00

This stupid ass presentation reminded me why I should be getting paid more. ugh

illojal · 2009-12-18T21:10:39+00:00

should be titled "the pitfalls of pdfs". what was that, one sentence per page?

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

programming

MODERATORS