6 Replies - 2091 Views - Last Post: 19 March 2011 - 06:23 PM

Poll: DOD vs OOP (8 member(s) have cast votes)

What do you use/prefer?

  1. DOD (0 votes [0.00%])

    Percentage of vote: 0.00%

  2. OOP (8 votes [100.00%] - View)

    Percentage of vote: 100.00%

Vote Guests cannot vote

#1 DivideByZero  Icon User is offline

  • D.I.C Addict
  • member icon

Reputation: 238
  • View blog
  • Posts: 551
  • Joined: 02-December 10

DOD vs OOP

Posted 19 March 2011 - 05:15 AM

So over the last few months on my twitter I noticed a lot of heated debate over Data oriented design vs Object oriented programming.
I originally ignored it, but then my curiousity kicked in and I did a little research on what DOD is.

This research led me to a thread on stack overflow where a poster describes DOD as.....

"My understanding of Data Oriented Design is that it is about organizing your data for efficient processing. Especially with respect to cache misses etc.

Say you have ball objects in your application with properties such as color, radius, bounciness, position etc. In OOP you would describe you balls like this:
class Ball {
Point pos;
Color color;
double radius;

void draw();
};

And then you would create a collection of balls like this:
vector<Ball> balls;

In Data Oriented Design however you are more likely to write the code like this:
class Balls {
vector<Point> pos;
vector<Color> color;
vector<double> radius;

void draw();
};

As you can see there is no single unit representing one Ball anymore. Ball objects only exist implicitly. Usually we want to do operations on many balls at the same time. Hardware usually want large continuous chunks of memory to operate efficiently. Secondly you might do operations that affects only part of a balls properties. E.g. if you combine the colors of all the balls in various ways, then you want your cache to only contain color information. However when all ball properties are stored in one unit you will pull in all the other properties of a ball as well. Even though you don't need them.

Say a ball each ball takes up 64 bytes and a Point takes 4 bytes. A cache slot takes say 64 bytes as well. If I want to update the position of 10 balls I have to pull in 10*64 = 640 bytes of memory into cache and get 10 cache misses. If however I can work the positions of the balls as separate units, that will only take 4*10 = 40 bytes. That fits in one cache fetch. Thus we only get 1 cache miss to update all the 10 balls. These numbers are arbitrary I assume a cache block is bigger.

But it illustrates how memory layout can have severe effect cache hits and thus performance. This will only increase in importance as the difference between CPU and RAM speed widens."



So my curiousity has now led me to wonder what people here think about the whole DOD vs OOP debate.
What are you thoughts on the subject?
Do you use DOD?
Which of the two do you prefer?
Can they really coexist properly in a program?

This post has been edited by DivideByZero: 19 March 2011 - 05:17 AM


Is This A Good Question/Topic? 1
  • +

Replies To: DOD vs OOP

#2 Martyr2  Icon User is offline

  • Programming Theoretician
  • member icon

Reputation: 4309
  • View blog
  • Posts: 12,088
  • Joined: 18-April 07

Re: DOD vs OOP

Posted 19 March 2011 - 01:39 PM

The DOD definitely has a lot of appealing advantages. But we have to step back and ask ourselves about the problems we have in a project and pick the appropriate design.

Most of us may be writing a website or a desktop app that is not resource intensive (like dealing with large image files etc) so most of the speed enhancements you see with DOD would not really be worth the extra time and effort to map out all your data in an efficient way.

If I was designing a high end game for a console or for some embedded system, then DOD may very well be something that would be interest. DOD is great for speed but the trade off is getting it to fit with other systems and also changing our way of thinking... likely to slow down any development time.

I personally have not used DOD and probably won't for a long time. I just don't need the enhancements it provides. It doesn't fit well with many of the applications I create.

As for coexisting, well, they might be able to, but most of the time it wouldn't. DOD is focused on data and its layout in memory while OOP is based on object structure with no focus on memory layout. With OOP we are worried about getting something, doing a tasks and throwing it back out to memory. Who cares how it is laid out? DOD is all about the layout for quick contiguous reads and writes.

But as far as I have seen, DOD has been limited to high speed applications (mostly console gaming etc) which really can utilize the speed of a contiguous read (to load a large resource file for instance or to manipulate a large block of memory efficiently).

:)
Was This Post Helpful? 2
  • +
  • -

#3 TMKCodes  Icon User is offline

  • D.I.C Regular
  • member icon

Reputation: 48
  • View blog
  • Posts: 440
  • Joined: 21-March 09

Re: DOD vs OOP

Posted 19 March 2011 - 02:20 PM

I actually find this quite interesting.

Few days ago I started to look oddly at my PHP class and how I had written it, but it seems I was using DOD even without realizing it. The class was loading a huge list of keywords from database so I was automatically thinking how to easily handle the data without passing possibly thousands of objects where ever I needed the keyword list. Now i just pass one object and the list is in the object and I can modify the list easily.

Never actually heard of DOD before this or about it's advantages, but thank you for telling me about it. :)
Was This Post Helpful? 1
  • +
  • -

#4 SpeedisaVirus  Icon User is offline

  • Baller
  • member icon

Reputation: 114
  • View blog
  • Posts: 855
  • Joined: 06-October 08

Re: DOD vs OOP

Posted 19 March 2011 - 02:31 PM

DOD is sound stuff but the only place where I see it faultering is that it almost encourages parallel datastructures which, as we all know, can be quite dangerous without proper considerations.
Was This Post Helpful? 0
  • +
  • -

#5 Sergio Tapia  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1252
  • View blog
  • Posts: 4,168
  • Joined: 27-January 10

Re: DOD vs OOP

Posted 19 March 2011 - 04:14 PM

I've never heard of DoD.

In your example:

class Balls {
vector<Point> pos;
vector<Color> color;
vector<double> radius;

void draw();
};



How would you know the pos, color and radius of a single ball?
Was This Post Helpful? 0
  • +
  • -

#6 raziel_  Icon User is offline

  • Like a lollipop
  • member icon

Reputation: 464
  • View blog
  • Posts: 4,255
  • Joined: 25-March 09

Re: DOD vs OOP

Posted 19 March 2011 - 05:02 PM

I thought that DOD is used only in non object oriented languages like embedded C programming.

This post has been edited by NoBrain: 19 March 2011 - 05:02 PM

Was This Post Helpful? 0
  • +
  • -

#7 baavgai  Icon User is offline

  • Dreaming Coder
  • member icon

Reputation: 5777
  • View blog
  • Posts: 12,590
  • Joined: 16-October 07

Re: DOD vs OOP

Posted 19 March 2011 - 06:23 PM

Interesting. I did a quick search: links of interest include

http://gamesfromwith...oriented-design
http://gamesfromwith...d-in-the-future
http://solid-angle.b...ted-design.html
More I quite liked the link on this page, "Data Oriented Luddites", but it's impossible to link to on DIC.

First, the only DOD folks seem to be game folks. The issue? At any given moment in a gaming environment, there are numerous elements that need to be tracked and processed. The contention is that the OO abstraction slows this down... well, duh!

I found myself thinking of the good old days when we'd just move crap around anywhere in memory we felt like. We updated the screen by directly writing to the display buffer! Organized data is for sissies; give me a big block of memory, some bit masks, maybe a few page addresses, and get out of the way! We really did make those little machines do amazing stuff... and the fastest code usually looked like crap.

The real question is to OOP or not. I don't believe OOP is the best solution for every problem, though it can certainly be applied to every problem. There are times I really enjoy plain old C. It's a simple little language and about as close to assembly as you can get without actually going there. You can do it all in C and as fast as possible. You can also create some of the most spectacular bugs.

DOD really sounds like a call to return to giant memory blocks of the good old days. For some applications, this makes sense. If I were to make a project with this in mind, I'd probably want an abstraction layer... :P

This post has been edited by baavgai: 19 March 2011 - 06:29 PM

Was This Post Helpful? 3
  • +
  • -

Page 1 of 1