Data-oriented design

As a design paradigm, data-oriented-design focuses on optimal transformations of data and focuses on modelling programs as transforms. Transforms are abstractions of code that solely focus on the mapping of inputs to outputs. They do not distinguish between accessing inputs by parameter, pointer, reference, upvalue, and vice versa with writing outputs. This eliminates the concept of a Side-effect and focuses solely on how inputs transform into outputs, logically identical to functions in mathematics.

Not to be confused with Data-driven programming.
Programming paradigms

Strategies and patterns emerging from the notion of modelling via transforms often base themselves upon allowing assumptions about a program or subprogram's state. Examples such as Existential Processing[1] and Hierarchical Level of Detail[2] are all integral proponents of the core design principles.

As a programming paradigm, data-oriented programming (also commonly referred to as data-oriented design), is about implementing transforms into the native language, often with Procedural, Functional, and Array programming, though not limited from Object-oriented programming. To most optimally transform data between different states, the approach is to first focus on what transforms exist and discovering what they need to operate. Second is to optimize data layouts for these transforms, separating and sorting fields according to when they are needed, and to think about how data flows through the transform chains.

In the context of computing, data-oriented programming heavily benefits from program optimizations motivated by efficient usage of the CPU cache, often used in video game development.[3] Proponents include Mike Acton,[4] Scott Meyers,[5] Jonathan Blow, and Andrew Kelley. The parallel array (or structure of arrays) is a commonly referenced example of one such cache-motivated data structure. It is contrasted with the array of structures typical of object-oriented designs, and eventually balanced to a structure of arrays of structures.

Computing 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) results in poor data locality, more so if runtime polymorphism (dynamic dispatch) is used (which is especially problematic on some processors).[6][3] Although OOP appears to "organize code around data", it actually organizes source code around the interaction of data types and their relationships, rather than physically grouping individual fields and arrays in an efficient format for access by specific procedures. Moreover, it often hides layout details under abstraction layers, while data orientation wants to consider this first and foremost.

See also

References
  1. "Existential Processing". www.dataorienteddesign.com. Retrieved 2023-06-01.
  2. "Hierarchical Level of Detail". www.dataorienteddesign.com. Retrieved 2023-06-01.
  3. Llopis, Noel (December 4, 2009). "Data-oriented design". Data-Oriented Design (Or Why You Might Be Shooting Yourself in The Foot With OOP). Archived from the original on Apr 23, 2019. Retrieved April 17, 2020.
  4. "CppCon 2014: Mike Acton "Data-Oriented Design and C++"". YouTube.
  5. "code::dive conference 2014 - Scott Meyers: Cpu Caches and Why You Care". YouTube.
  6. "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
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.