Data-oriented design

In computing, data-oriented design is a program optimization approach motivated by efficient usage of the CPU cache, used in video game development.[1] The approach is to focus on the data layout, separating and sorting fields according to when they are needed, and to think about transformations of data. Proponents include Mike Acton[2] and Scott Meyers.[3]

Not to be confused with Data-driven programming.

Motives

These methods became especially popular in the mid to late 2000s during the seventh generation of video game consoles that included the IBM PowerPC based PlayStation 3 (PS3) and Xbox 360 consoles. Historically, game consoles often have relatively weak central processing units (CPUs) compared to the top-of-line desktop computer counterparts. This is a design choice to devote more power and transistor budget to the graphics processing units (GPUs). For example, the 7th generation CPUs were not manufactured with modern out-of-order execution processors, but instead use in-order processors with high clock speeds and deep pipelines. In addition, most types of computing systems have main memory located hundreds of clock cycles away from the processing elements. Furthermore, as CPUs have become faster alongside a large increase in main memory capacity, there is massive data consumption that increases the likelihood of cache misses in the shared bus, otherwise known as Von Neumann bottlenecking. Consequently, locality of reference methods have been used to control performance, requiring improvement of memory access patterns to fix bottlenecking. Some of the software issues were also similar to those encountered on the Itanium, requiring loop unrolling for upfront scheduling.

Contrast with object orientation

The claim is that traditional object-oriented programming (OOP) design principles result in poor data locality, more so if runtime polymorphism (dynamic dispatch) is used (which is especially problematic on some processors).[4][5] Although OOP does seem to "organise code around data", the practice is quite different. OOP is actually about organising source code around data types rather than physically grouping individual fields and arrays in an efficient format for access by specific functions. Moreover, it often hides layout details under abstraction layers, while a data-oriented programmer wants to consider this first and foremost.

gollark: > All code sent to the user's browser must be free software and labeled for LibreJS or other suitable free automatic license analyzer, regardless of whether the site functions when the user disables this code. (B0)Nope!> Does not report visitors to other organizations; in particular, no tracking tags in the pages. This means the site must avoid most advertising networks. (B1)Yes, it is entirely served locally.> Does not encourage bad licensing practices (no license, unclear licensing, GPL N only). (B2)Again, don't think gitea has this.> Does not recommend nonfree licenses for works of practical use. (B3)See above.
gollark: > All important site functionality that's enabled for use with that package works correctly (though it need not look as nice) in free browsers, including IceCat, without running any nonfree software sent by the site. (C0)I think so. Definitely works in free browsers, don't know if it contains nonfree software.> No other nonfree software is required to use the site (thus, no Flash). (C1)Yes.> Does not discriminate against classes of users, or against any country. (C2)Yes.> Permits access via Tor (we consider this an important site function). (C3)Yes.> The site's terms of service contain no odious conditions. (C4)Yes.> Recommends and encourages GPL 3-or-later licensing at least as much as any other kind of licensing. (C5)I don't think it has much on licensing, so suuuure.> Support HTTPS properly and securely, including the site's certificates. (C6)Definitely.
gollark: I'll run git.osmarks.net through the comparison tables.
gollark: Yes, my location is stored in their internal processors.
gollark: (GNU/)³Linux

See also

References
  1. Llopis, Noel (December 4, 2009). "Data-oriented design". Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP). Retrieved April 17, 2020.
  2. "CppCon 2014: Mike Acton "Data-Oriented Design and C++"".
  3. "code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care".
  4. "What's wrong with Object-Oriented Design? Where's the harm in it?".describes the problems with virtual function calls, e.g., i-cache misses
  5. "Data-oriented design - why you might be shooting yourself in the foot with OOP".
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.