blocks|key|1420449|text|面向数据的设计是这样一种设计，在这种设计中，应用程序的逻辑是由数据集而不是过程化算法构建的。例如|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1420450|程序化方法。|1420451|int+animation;+//+this+value+is+the+animation+index

if(animation+==+0)
+++PerformMoveForward();
else+if(animation+==+1)
++PerformMoveBack();
....+//+etc|code-block|syntax|javascript|1420452|数据设计方法|1420453|typedef+struct
{
+++int+Index;
+++void+(*Perform)();
}AnimationIndice;

//+build+my+animation+dictionary
AnimationIndice+AnimationIndices[]+=+
++{
++++++{+0,PerformMoveForward+}
++++++{+1,PerformMoveBack+}
++}

//+when+its+time+to+run,+i+use+my+dictionary+to+find+my+logic
int+animation;+//+this+value+is+the+animation+index
AnimationIndices[animation].Perform();|1420454|像这样的数据设计促进了使用数据来构建应用程序的逻辑。它更容易管理，特别是在视频游戏中，它可能有数千条基于动画或其他因素的逻辑路径。|1420455|entityMap^0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|Q|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|R|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|S|8|@]|9|@]|A|$G|H]]|$1|I|3|J|5|6|7|T|8|@]|9|@]|A|$]]|$1|K|3|L|5|F|7|U|8|@]|9|@]|A|$G|H]]|$1|M|3|N|5|6|7|V|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|P|$]]

A data oriented design is a design in which the logic of the application is built up of data sets, instead of procedural algorithms. For example

procedural approach.

<pre><code>int animation; // this value is the animation index

if(animation == 0)
 PerformMoveForward();
else if(animation == 1)
 PerformMoveBack();
.... // etc
</code></pre>

data design approach

<pre><code>typedef struct
{
 int Index;
 void (*Perform)();
}AnimationIndice;

// build my animation dictionary
AnimationIndice AnimationIndices[] = 
 {
 { 0,PerformMoveForward }
 { 1,PerformMoveBack }
 }

// when its time to run, i use my dictionary to find my logic
int animation; // this value is the animation index
AnimationIndices[animation].Perform();
</code></pre>

Data designs like this promote the usage of data to build the logic of the application. Its easier to manage especially in video games which might have thousands of logic paths based on animation or some other factor.

blocks|key|1420545|text|首先，不要将这与数据驱动设计混淆。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1420546|我对面向数据的设计的理解是，它是关于组织数据以进行有效处理的。特别是在缓存未命中等方面。另一方面，数据驱动设计是关于让数据控制程序的许多行为(Andrew+Keith's+answer对此进行了很好的描述)。|offset|length|1420547|假设您的应用程序中有一些球对象，这些对象具有诸如颜色、半径、弹力度、位置等属性。|1420548|面向对象的方法|1420549|在OOP中，你可以这样描述球：|1420550|class+Ball+{
++++Point++position;
++++Color++color;
++++double+radius;

++++void+draw();
};|code-block|syntax|javascript|1420551|然后创建一个球的集合，如下所示：|1420552|vector<Ball>+balls;|1420553|面向数据的方法|1420554|然而，在面向数据的设计中，您更有可能像这样编写代码：|1420555|class+Balls+{
++++vector<Point>++position;
++++vector<Color>++color;
++++vector<double>+radius;

++++void+draw();
};|1420556|正如你所看到的，不再有单个单位代表一个球了。球对象只隐式存在。|1420557|这在性能方面有很多优势。通常，我们希望同时对多个球进行操作。硬件通常需要大量连续的内存块才能有效地运行。|1420558|其次，您可以执行仅影响球的部分属性的操作。例如，如果你以各种方式组合所有球的颜色，那么你希望你的缓存只包含颜色信息。但是，当所有球的属性都存储在一个单元中时，您将同时引入球的所有其他属性。即使你不需要它们。|1420559|缓存使用示例|1420560|假设每个球占用64个字节，一个点占用4个字节。比方说，一个缓存槽也占用64字节。如果我想更新10个球的位置，我必须将10x64=+640字节的内存放入缓存中，并获得10个缓存未命中。但是，如果我可以将球的位置作为单独的单元来计算，那么只需要4x10=+40个字节。这适用于一次高速缓存获取。因此，我们只有一次缓存未命中来更新所有10个球。这些数字是任意的-我假设缓存块更大。|1420561|但它说明了内存布局如何对缓存命中产生严重影响，从而影响性能。这只会随着CPU和RAM速度之间的差异扩大而变得更加重要。|1420562|如何布局内存|1420563|在我的ball示例中，我大大简化了问题，因为通常对于任何普通的应用程序，您可能会一起访问多个变量。例如，位置和半径可能会经常一起使用。那么你的结构应该是：|1420564|class+Body+{
++++Point++position;
++++double+radius;
};

class+Balls+{
++++vector<Body>++bodies;
++++vector<Color>++color;

++++void+draw();
};|1420565|您应该这样做的原因是，如果一起使用的数据放在不同的阵列中，则它们会竞争缓存中的相同插槽。因此，加载一个会抛出另一个。|1420566|因此，与面向对象编程相比，您最终创建的类与您的问题心理模型中的实体无关。由于数据是根据数据使用情况组合在一起的，因此在面向数据的设计中，您并不总是有合理的名称来命名您的类。|1420567|与关系数据库的关系|1420568|面向数据的设计背后的思想与您对关系数据库的思考非常相似。优化关系数据库还可以涉及更有效地使用缓存，尽管在这种情况下，缓存不是CPU缓存，而是内存中的页。一个好的数据库设计人员可能还会将不经常访问的数据拆分到一个单独的表中，而不是创建一个包含大量列的表，其中只使用其中的几列。他可能还会选择对一些表进行反规范化，这样就不必从磁盘上的多个位置访问数据。就像面向数据的设计一样，这些选择是通过查看数据访问模式是什么以及性能瓶颈在哪里来做出的。|1420569|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/1641580/what-is-data-oriented-design/1641615#1641615^0|0|1Z|L|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1Z|8|@]|9|@$D|20|E|21|1|22]]|A|$]]|$1|F|3|G|5|6|7|23|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|24|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|25|8|@]|9|@]|A|$]]|$1|L|3|M|5|N|7|26|8|@]|9|@]|A|$O|P]]|$1|Q|3|R|5|6|7|27|8|@]|9|@]|A|$]]|$1|S|3|T|5|N|7|28|8|@]|9|@]|A|$O|P]]|$1|U|3|V|5|6|7|29|8|@]|9|@]|A|$]]|$1|W|3|X|5|6|7|2A|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|N|7|2B|8|@]|9|@]|A|$O|P]]|$1|10|3|11|5|6|7|2C|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2D|8|@]|9|@]|A|$]]|$1|14|3|15|5|6|7|2E|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2F|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2G|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2H|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|N|7|2K|8|@]|9|@]|A|$O|P]]|$1|1I|3|1J|5|6|7|2L|8|@]|9|@]|A|$]]|$1|1K|3|1L|5|6|7|2M|8|@]|9|@]|A|$]]|$1|1M|3|1N|5|6|7|2N|8|@]|9|@]|A|$]]|$1|1O|3|1P|5|6|7|2O|8|@]|9|@]|A|$]]|$1|1Q|3|-4|5|6|7|2P|8|@]|9|@]|A|$]]]|1R|$1S|$5|1T|1U|1V|A|$1W|1X]]]]

First of all, don't confuse this with data-driven design.
My understanding of Data-Oriented Design is that it is about organizing your data for efficient processing. Especially with respect to cache misses etc. Data-Driven Design on the other hand is about letting data control a lot of the behavior of your program (described very well by <a href="https://stackoverflow.com/questions/1641580/what-is-data-oriented-design/1641615#1641615">Andrew Keith's answer</a>).
Say you have ball objects in your application with properties such as color, radius, bounciness, position, etc.
<h3 id="object-oriented-approach-beay">Object Oriented Approach</h3>
In OOP you would describe balls like this:
<pre class="lang-cpp prettyprint-override"><code>class Ball {
 Point position;
 Color color;
 double radius;

 void draw();
};
</code></pre>
And then you would create a collection of balls like this:
<pre class="lang-cpp prettyprint-override"><code>vector&lt;Ball&gt; balls;
</code></pre>
<h3 id="data-oriented-approach-jbux">Data-Oriented Approach</h3>
In Data Oriented Design, however, you are more likely to write the code like this:
<pre class="lang-cpp prettyprint-override"><code>class Balls {
 vector&lt;Point&gt; position;
 vector&lt;Color&gt; color;
 vector&lt;double&gt; radius;

 void draw();
};
</code></pre>
As you can see there is no single unit representing one Ball anymore. Ball objects only exist implicitly.
This can have many advantages, performance-wise. Usually, we want to do operations on many balls at the same time. The hardware usually wants large contiguous chunks of memory to operate efficiently.
Secondly, you might do operations that affect only part of the properties of a ball. For 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.
<h3 id="cache-usage-example-k8ek">Cache Usage Example</h3>
Say 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 x 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 x 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 a severe effect on cache hits and thus performance. This will only increase in importance as the difference between CPU and RAM speed widens.
<h3 id="how-to-layout-the-memory-qg4l">How to layout the memory</h3>
In my ball example, I simplified the issue a lot, because usually for any normal app you will likely access multiple variables together. E.g. position and radius will probably be used together frequently. Then your structure should be:
<pre class="lang-cpp prettyprint-override"><code>class Body {
 Point position;
 double radius;
};

class Balls {
 vector&lt;Body&gt; bodies;
 vector&lt;Color&gt; color;

 void draw();
};
</code></pre>
The reason you should do this is that if data used together are placed in separate arrays, there is a risk that they will compete for the same slots in the cache. Thus loading one will throw out the other.
So compared to Object-Oriented programming, the classes you end up making are not related to the entities in your mental model of the problem. Since data is lumped together based on data usage, you won't always have sensible names to give your classes in Data-Oriented Design.
<h3 id="relation-to-relational-databases-bzcd">Relation to relational databases</h3>
The thinking behind Data-Oriented Design is very similar to how you think about relational databases. Optimizing a relational database can also involve using the cache more efficiently, although in this case, the cache is not CPU cache but pages in memory. A good database designer will also likely split out infrequently accessed data into a separate table rather than creating a table with a huge number of columns where only a few of the columns are ever used. He might also choose to denormalize some of the tables so that data don't have to be accessed from multiple locations on disk. Just like with Data-Oriented Design these choices are made by looking at what the data access patterns are and where the performance bottleneck is.

blocks|key|1205618|text|我只想指出，Noel专门谈到了我们在游戏开发中面临的一些具体需求。我认为正在进行实时软模拟的其他部门将从中受益，但它不太可能是一种对一般业务应用程序显示出显著改进的技术。这种设置是为了确保从底层硬件中挤出最后一点性能。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1205619|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I just want to point out that Noel is talking specifically about some of the specific needs we face in game development. I suppose other sectors that are doing real-time soft simulation would benefit from this, but it is unlikely to be a technique that will show noticeable improvement to general business applications. This set up is for ensuring that every last bit of performance is squeezed out of the underlying hardware.

blocks|key|1420736|text|如果你想利用现代处理器架构，你需要以某种方式在内存中布局你的数据。CPU非常擅长处理在内存中按顺序排列的简单类型。任何其他布局的处理成本都要高得多。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1420737|在面向对象的方法中，您总是考虑一个实例，然后通过将对象分组为集合来将其扩展到多个实例。但从硬件的角度来看，这会带来额外的成本。|1420738|在面向数据的方法中，您没有像在面向对象编程中那样的“实例”。您的实例可以有一个标识符，类似于关系数据库中的数据，但除此之外，与您的实例相关的数据可以拆分到几个表中(表以向量的形式实现)，以实现高效的处理。|1420739|例如:假设您有类Student+{+int+id；std::string+name；float+average；bool+graduated；}。在OOP的情况下，你会把你所有的学生放在一个单独的向量中。|1420740|在面向数据的设计中，您首先会问自己想要对这些数据进行什么样的处理。假设你想为所有还没有毕业的学生计算一个平均分。因此，您将创建一个表，其中只包含已毕业的学生和另一个未毕业的学生。您不会将学生姓名保留在该表中，因为它不用于处理。但您将在表中保留一个学生号和一个平均分。|1420741|现在计算未毕业学生的平均分数将意味着迭代未毕业学生表并执行计算。由于平均标记在内存中是相邻的，因此您的CPU将使用SIMD并以最有效的方式处理数据。由于我们不会查询布尔毕业生来测试该学生是否已毕业，因此没有数据缓存未命中。|1420742|理论上这听起来不错，但我从来没有在现实世界的项目中做过这样的开发。如果任何人有任何经验，请与我联系，我有很多问题。|1420743|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

If you want to take advantage of modern processor architecture, you need to lay out your data in memory in a certain way. CPUs are really good at processing simple types that are laid out sequentially in memory. Any other layout has a much higher processing cost.
In object-oriented approach, you always think about one instance, and then you are extending it to several instances by grouping objects into collections. But from the hardware point of view, this comes with the added cost.
In data-oriented approach, you don't have an &quot;instance&quot; in the same way you have in object-oriented programming. Your instance can have an identifier, similar to data in relational databases, but apart from that, data related to your instance can be split over several tables (tables are implemented as vectors), to allow efficient processing.
An example: imagine you have class Student { int id; std::string name; float average; bool graduated; }. In case of OOP, you would put all your students in a single vectors.
In data-oriented design, you will first ask yourself what kind of processing you want to do to this data. Say you want to calculate an average mark for all students that still haven't graduated. So you will create a table which contains only students that have graduated, and another that haven't. You won't keep the student name in that table since it is not used for processing. But you will keep a student ID and an average mark in the table.
Now calculating average mark for non-graduated students will mean iterating through the non-graduated table and performing the calculation. Since average marks are neighboring in memory, your CPU will use SIMD and process the data in the most efficient way possible. Since we are not querying the bool graduated to test if the student has graduated, there are no data cache misses.
This sounds nice in theory but I have never done this kind of development on a real-world project. If anybody have any experience, please contact me, I have many questions.

I was reading <a href="http://gamesfromwithin.com/data-oriented-design" rel="noreferrer">this article</a>, and this guy goes on talking about how everyone can greatly benefit from mixing in data oriented design with OOP. He doesn't show any code samples, however.

I googled this and couldn't find any real information as to what this is, let alone any code samples. Is anyone familiar with this term and can provide an example? Is this maybe a different word for something else?

What is data oriented design?

数据缓存

游戏开发

数据库

我正在阅读，这个人继续谈论如何每个人都可以从面向数据的设计和OOP的混合中获得巨大的好处。然而，他没有展示任何代码样本。我在谷歌上搜索了一下，找不到任何关于这是什么的真实信息，更不用说任何代码样本了。有没有人熟悉这个术语并能提供一个例子？这是不是其他东西的另一个词呢？

问什么是面向数据的设计？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是面向数据的设计？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问什么是面向数据的设计？
EN