It is still not easy to use, I can't find any examples of people using it (except for spawning a ton of random objects). As far as I know most people are still using OOP and that won't change unless they get rid of it and make the ECS much easier to use.
@@andrewherrera7735 Mainly any game company is using data oriented in some fashion. Data oriented is actually WAYYY easier to use, you just have to break the habit of OO. OO seems easier up front but you pay for its costs later and boy do they add up quick especially because its too easy for bad developers to get wrong and create a tangled mess of a code base.... I'm working in one of those right now...Its not a golden hammer, you have to know your codebase and intentions, and what is slowing down your system/game etc. Also remember not everything NEEDS to be data oriented. You can mix paradigms, people just like to fight for one vs the other.
The statement at 9:56 is misleading, in this context. Yes, ultimately all software takes some data and outputs some other data. But not all software (actually an overwhelming majority of software) is not data bound. Meaning, if your software isn't data bound, organizing it around data can become a major hurdle, for little to no (to even negative) effect. Games and simulation software however, has a lot of advantage when it comes to DOD, since those kinds of software often processes the *same kind of data, at the same time, in a repetitive fashion.*
Unity is international, unless you are targeting just a small market niche, you should consider to subtitle the videos. Autogenerated subtitles surely can help, but they are not good enough.
Does this mean that if u think about something and write a script, it will just work instead of having 27 reasons not to, that you have to work around, before u can stop screaming at your monitor?
Nobody talks about price you should pay for ECS. Every time they show very simple examples on this kind of presentations. But I can't imagine how much more code you will write, for example, for ingame level editor with undo/redo actions and tons of UI, where with OOP you could use simple as stone Command pattern. Or I overthinking this and this is as simple in ECS?
falls under "best tool for the job". you wouldnt use a hammer to drive a screw. you wouldnt use DoD (typically) for in-game systems that deal with a single instance (such as UI or editors). i know this is a simplification but let me know if i'm just totally missing your point. DoD is 100% applicable in many game systems and ECS is just one implementation of DoD
@@gcp-starchump Why not use DOD for single-instance stuff? I think you are confusing DOD with ECS a bit, because you can totally use DOD for UI or editors. It would most likely be even easier to maintain and run faster than with an OOP implementation. Probably not as noticable as when there are many instances like AI, but OOP usually quickly turns into a clusterfuck of a million classes and sub-classes.
@@Mike-uk2oq yeah i was using DoD interchangeably, my bad. from what i can tell, ecs would definitely be a bad choice for interfaces cuz it sounds like a pain. i'm all for DoD when it's the right choice
Very good video but I found the reason of using DOD to be bad. So at the end is not like OOP is bad because is more human related and readable because of that, it is bad only because memory does not work like human abstract thoughts. In short, devs should adapt their thoughts and systems to work for a machine instead of the other way around. Sad think honestly.
Man, this C++ code presented as OOP is not the way you would do it in Unity. You wouldn't have an Animal class and derive from it. You would have a Movement script, a Reproduce scripts and so on. Unity is already designed as a powerful ECS. You can pretty much avoid most of inheritance code here. As of memory layout issues, why not solve it internally in the engine if it poses any problem? Or using object pooling when needed? I think this ECS hype has only one purpose: Bringing big, 'professional' teams to Unity by claiming more 'advanced' features than Unreal Engine. At least the 'advanced' part must be marketable to clueless Managers and Investors. They should instead develop some real world games with their engine to experience the bugs, missing features, missing work flow improvements and all other drawbacks first hand. We tell them all day. E.g. still you cannot adjust camera speed in Editor, a feature UE has since 10 or so years ago.
You still have the issue of indirect dispatch and data managing themselves. If I have a C# dynamic array of classes that have virtual functions for Update I have 3 levels of indirection, meaning that it's potentially 3 separate memory lookups needed to do from RAM. At least two of these lookups will occur every time the component iterates, and will result in the procedure being completely uncacheable. Pooling won't solve this issue because it's not just an issue of data access but rather relativity to each other in a system operating on them. In the memory pool, the pointers to your classes may all be in one place, but those class's actual data and their virtual functions will be somewhere else regardless. Solving the problem internally would have definitely caused less headache for people using Unity having to learn a different pattern for composing entities, definitely, but it simply isn't feasible due to the design issues stretching into how the users of the engine are having to write mono behavior code.
Sorry, but I'm a bit disappointed by this talk. It starts with an unnecessary "OOP is the root of all evil" bit in the beginning (complete with the usual "just look at this mess OOP makes" nonsense), culminating in claiming that data-oriented design wasn't more difficult, just different. I'm sorry, but that's about as valid as claiming getting a hamburger in a fast food joint wasn't more difficult than cooking a decent meal. Of course it is... just as data-oriented design is harder than slapping together a few game objects with MonoBehaviors that do what you want. One can be done "on the fly", the other requires you to understand your problem fully, build an appropriate data abstraction for that problem and design a system to work on that data. After that, we get into the "why" of data-oriented design, which I do get, but have heard already dozens of times. We barely touch on "how" a design process in that system would actually work and I must have missed the "for entity component systems" bit completely. So... "understanding data-oriented design for entity component systems"? Not really.
And I'm still wondering on how much performance this actually increases in an actual use-case. Every single example they use are crazy absurdities that would never be done anyway. What about all the objects that you only have 2~3 uses in a Scene. Or that is activated every now and then and things like that. Is the increase in complexity really worth it? I'd say that for 99% of the cases, not really. What I'm actually thinking is that you should use OOP as usual and have a thing here and there to be the ECS way. Say a custom animator, AI, things like that.
@@HenriqueGdeC Yes, I also doubt the performance benefit for objects you don't have dozens, hundreds or thousands of instances of is all that great. For example, the first ECS demo I've seen was that space shooter thing: It would have been interesting to see how the performance compares in actually realistic scenarios for that. Not tens of thousands of ships, but perhaps around 10. I also agree that for most projects, it's probably best to mix & match.
Thank you for mentioning this! I also agree with the other replies, how much performance increase do you actually get? I did some minor testing, and I was only seeing improvements of 300 microseconds per frame...
@@HenriqueGdeC She very clearly alludes to the performance gap, at least. She did not provide numbers, but if you're curious, an x86_64 based cpu will burn 100-300 cycles on a main memory access, as opposed to 3-15 for a read from L1 or L2. Find the difference between 3-15 and 100-300 and you'll know how much slower your OOP code that ignores that basic reality you're living in is! The variance comes from a variety of factors, include the fact main memory reads are also often 2x slower when it is not word-aligned - 32 bits on x86 or 64 bits on x64 just due to the fact you will actually have to do two reads instead of one in that case. Of course, if your game only has two entity types, and there's never more than 10 of them, ECS is usually overkill. But this is a talk at Unity. They are trying to make good general purpose tools. Beyond that, the whole purpose of archetypes is to eliminate the over-generalization that sometimes happens with other ECS implementations, and it does a pretty good job, imo.
@@churchianity I know that DOD is faster in performance than doing the oop way and this video explains very well at least for me, but... The problem is like at the end devs are constrained to develop things for a machine instead the other way around. This counter intuitive way of abandon human thoughts like relating characteristics together to describe a thing, or do things like classification, etc, is just wrong honestly. Devs end up being like slaves to the machines. Adapting their thoughts and processes to match for a certain hardware, instead of using/designing hardware (a tool to an end) to express their thoughts. Very sad honestly.
Data Oriented Design seems to be just a new name for column based data stores. This is not a programming paradigm at all. Tools like Sql Server Analysis Services, etc. uses these and many other techniques for years, yet still written in OOP languages like c++. Another point of confusion created by marketers to confuse developers... nothing but a good optimization technique...
There's quite a bit more to it than that. Sometimes it's the opposite and favors the AoS (interleaved format, like xyzxyz as opposed to xxxyyyzzz) for random-access patterns (the SoA or column-based format is often less efficient in random-access cases involving multiple fields being accessed). Sometimes it's splitting hot fields away from cold fields, rarely-accessed. Sometimes it's realizing an n-ary tree might work better than the binary, 4-ary, and 8-ary trees that tend to be popular in CS, or realizing a hash table with linear probing might work better than separate chaining even at the cost of more iterations in collisions. Sometimes it's realizing that maybe we can't abstract away certain details like the pixel format of an image without significant degradation in performance which can also significantly cut into productivity at some point if the discovery that such abstractions are barriers to optimization too late in the game. Most of all, it's about putting the data at the forefront of critical designs and discussions among devs during design meetings. It's the antithesis of encapsulation which tends to want to hide data and turn it into an implementation detail, sometimes at great expense to the hardware or people maintaining the code or both. Sometimes it's reminding ourselves when we're tempted to build layers and layers of abstractions obscuring the data to simplify, and remember in many contexts that the data really matters and that our jobs as programmers are not to enforce our world views in a codebase of how things should work but to effectively transform data from one form to another. There are a gazillion image libraries, some more complex than others, but they all have one thing in common: they input and output pixels (arrays of numbers). Remembering that can prevent us from designing convoluted IImage, and IImageFactory, and IPixelFormat, and so forth. It can put us on the same page with respect to design in a world that resembles the Tower of Babel scenario where people get so inspired to reinvent wheels over and over primarily with the intent of hiding data that they can no longer communicate with each other. For example, the AutoDesk people ignored/forgot this style of design with FBX. Instead of designing a clear, concise data format and representation, they built a convoluted one that requires a monstrous SDK to import and export the format. And that's probably why FBX has such limited support, especially in game engines, since they put the data in the background (they made it an implementation detail) and made it so the only way to practically work with their data format is with their tools. A data-oriented mindset wouldn't design file formats in such a complex way as a sort of afterthought where the only practical way to work with the data is by using a specific set of proprietary tools and abstract interfaces. It would be at the forefront of the design and its discussion. If they did that, wide support would have been easier, among all sorts of developers and ones using completely different tools and possibly even completely different programming languages, because the data is the ultimate thing that puts us on the same page -- not SDKs, not programming languages, not tools -- it's the data. Remembering about DOD can serve as a friendly reminder not to forget about the importance of data in a world that wants to push it to the background and out of the spotlight. Unfortunately, it's not exactly the type of subject that's taught in most CS courses, and material related to it is scarce, and the people who attempt to teach it tend to have to market it as a result by showing off its performance. But far beyond performance, design is ultimately about communication. And the "design" aspect of DOD is remembering that data is the *universal* communicator among programmers. You might have your own way of doing things, and I might have mine, but if there's a chance for us, and our code, to work in harmony with each other rather than fighting each other and requiring all sorts of glue code and layers of translation, it's ultimately going to be about mutual understanding of the data. I might pass you a mesh and you give me back a deformed mesh. I might pass you an audio signal and you give me back one with reverb. I might pass you a sequence of numbers and you give me back a sorted sequence. You might pass me a scene and I give you back an image that rasterized it. We transfer data between each other at the end of the day, and both of our lives might be much easier in many scenarios if we don't try to obscure it and make it very difficult to access by imposing interface barriers between each other in the form of superfluous abstractions.
One of the stupidest design decisions Unity has ever made was pushing the completely-different ECS system. What they should've done is something like introduce a new ParallelGameObject parent class that requires all members to be serializable and a couple of other restrictions, and then behind the scenes it packs them into same-sized struct data and does effectively everything ECS does, just with the classic OO interface to the programmer on the front.
This still feels like premature optimization for me. Like if you are using OOP correctly, you will not run into memory issues most of the time. Most of the time you will end up being quite happy with how your code is turning out as well, and everything makes sense in how it reacts (again, if you are doing it properly, which requires a lot of practice but ends up working out quite well in my experience)
I still feel like OOP has a much more simple elegance to it it where as DOD feels like throwing away everything we've done over the last 30 years and writing code like cavemen. The ECS code is ugly, and a real pain to work with. Not just different. You are trading clean, easy to follow, elegant code for performance. Which is a fair trade to make *where it counts*. DOTS overall feels like massive premature optimization. The majority of a game's code isn't going to really benefit from this change. Especially in an indie game. Only a small bit of it really needs this drastic level of optimization, but I feel like Unity is nudging/pushing to have entire games built using this new method.
This is not the only way to DOD but honestly OOP code is rarely "easy to follow". Just dont assume any paradigm creates good or bad code its rarely the case. This talk just steals from every other DOD talk without giving any credit to who they are stealing from typical UNITY garbage.
Furthermore OOP is far older than 30 years and is really not that revolutionary. DOD programming is not really a paradigm but a different way to think about things. This talk was garbage.
Actually it's other way around.. cavemen would've thought in simple objects.. this stuff is thinking molecularly. Going above or deeper than worldly stuff. Like using or implementing God particles or building stuff with atoms. You should use both concepts.
I think they just made an opportunity to make make games, where you can have tons of objects/audio/textures etc. This is not for common cases, only if you need huge boost in performance. Theese are just tools, not guideline to make all Unity code.
In my own experience as a hobbyist game dev, I've already moved to using component design over oop because single inheritance is limited and multi inheritance gets confusing and error prone. It's proven to be easier to break things up into blocks that can be added or removed. So for example, my last project had hopping or straight movement behaviors that operated on the objects velocity reading the objects move speed. I personally find that a way more intuitive system. Makes prototyping and consistent, reliable code reuse much easier. And I'm looking forward to this actual architecture instead of my hacky way of doing it.
Memory comes at a wide range of different speeds. Apart from the speed of the hardware, physical proximity to the CPU also affects the latency. For this reason, computers compromise by having memory stacked in different tiers, where L1, L2, and sometimes L3 cache are increasingly larger but slower, and the largest and slowest of all is your main memory (RAM). Whenever you do some kind of operation on a piece of data, that data and a decent chunk of the data around it, is moved to the cache memory. The more often you use it, the higher up the cache tier it moves, and if you don't use it, it gets replaced by some more recent/important data. This is to make sure that memory access is always as fast as possible. The CPU always looks in the cache for the data first - if it doesn't find it there, you get a "cache miss" and the data gets loaded from the RAM.
L1 - L3 caches are on your processor. It's built into the chip itself for the fastest possible read times. Think of it like a staging area for your processor. RAM is your main memory. That is where active programs are held. Sometimes, your hard disk can be used to expand your RAM temporarily through the use of virtual memory. This is where the OS decides to write some data onto your hard disk. For the purpose of this though, we're really only concerned with the memory in the processor and the memory in your DRAM sticks.
I think you completely missed the point, she is talking about the very real-world effects of memory layout. You can be off in performance by a factor in the hundreds, if you don't consider memory when designing your system. Designing your code around a model of the world, or programming by creating taxonomies and/or abstract relationships is the wrong approach. It doesn't particularly matter what acronym she uses, what she's fighting for is engineering based on reality.
It may be the time constraint she had for talks, but most of the time she felt like blabbering. Although the content of the presentation is good, the presentation itself is like in a fast moving train.
It's confusing if you've only ever written OOP style and, therefore, only viewed your code from the perspective of abstract real-world concepts rather than what the computer actually sees: data.
@@needlessoptions I know I'm late but your answer is exactly my main problem with this. While I know that DOD is better for a machine than OOP, we are missing the point that hardware as any other tool created by humans should work for us based on our understanding of things, not the other way around. This is a philosophical problem. We should not think and design systems for the machines, machines should interpret and resolve problems based on our understanding of things. If machines can not operate efficiently on our processes, that's mean the whole design or architecture of computers is wrong.
@@anthonymarquez2542 "a /s"? English? If you watch ECS videos and thus care about performance with many entity instances but don't care about RAM, I think you should look in the mirror first.
This is the best break down I've seen on changing the thought process over to DOTS
Indeed.
God bless you, Mike Acton.
It is still not easy to use, I can't find any examples of people using it (except for spawning a ton of random objects). As far as I know most people are still using OOP and that won't change unless they get rid of it and make the ECS much easier to use.
@@andrewherrera7735 Mainly any game company is using data oriented in some fashion. Data oriented is actually WAYYY easier to use, you just have to break the habit of OO. OO seems easier up front but you pay for its costs later and boy do they add up quick especially because its too easy for bad developers to get wrong and create a tangled mess of a code base.... I'm working in one of those right now...Its not a golden hammer, you have to know your codebase and intentions, and what is slowing down your system/game etc. Also remember not everything NEEDS to be data oriented. You can mix paradigms, people just like to fight for one vs the other.
Nice to see the team at unity thinking about better solutions to this problem.
I recently did some searching to better understand ECS, and this is by far the best / fastest explanation.
So youre only gonna show an example of OOP code but not DOD?
they didnt come up with it yet :)
This is the kind of video I'd want to send someone to explain the whys and hows of ECS. Thanks!
no DOD code examples?
this is an underrated talk
4:10
"bEatsMeat"
yes
true
Perfection.
The statement at 9:56 is misleading, in this context. Yes, ultimately all software takes some data and outputs some other data. But not all software (actually an overwhelming majority of software) is not data bound. Meaning, if your software isn't data bound, organizing it around data can become a major hurdle, for little to no (to even negative) effect. Games and simulation software however, has a lot of advantage when it comes to DOD, since those kinds of software often processes the *same kind of data, at the same time, in a repetitive fashion.*
Thanks for the presentation! It's really helpful to me for understanding the value behind DOD.
man this was a reallllly good visual demonstration
Can see the Acton fingerprints all over this... that's a good thing! Nice talk.
This make me understand more clearly about ECS and DOD.
So happy to see that we are moving away from pure OOP towards DOD software architecture
Someone is playing Flappy Bird in the background lmao. (4:08)
Thank you for the video; good overview. Some mild criticism: capturing the noise of the crowd in the background wasn't the best of ideas.
note for my self . shortcut
11:10 ECS visualization - keys 🏍😀🗝
14:10 ECS visualization - cookies 😃🍕
But that's a pizza, this is a cookie 🍪
I believe that Unity will be also the next tools to create non Game Apps CrossPlatform
I always stuff iterable data in arrays, something you used to learn back in the MS-DOS days as a kid :D
That's what arrays are for, iterable data...
Thanks... Now I will crave cookies every time I hear Data-Oriented Design 😠
I came here for information on DOP, but I stayed for the memes.
Unity is international, unless you are targeting just a small market niche, you should consider to subtitle the videos. Autogenerated subtitles surely can help, but they are not good enough.
Does this mean that if u think about something and write a script, it will just work instead of having 27 reasons not to, that you have to work around, before u can stop screaming at your monitor?
Basically treating the system as a pipeline
4:20 good old flappy bird haha
great talk though all that background murmur was so distracting it hurt to try and focus.
Cache is king
I'm hungry now.
Great talk.
❤️
Good stuff.
Nobody talks about price you should pay for ECS. Every time they show very simple examples on this kind of presentations. But I can't imagine how much more code you will write, for example, for ingame level editor with undo/redo actions and tons of UI, where with OOP you could use simple as stone Command pattern. Or I overthinking this and this is as simple in ECS?
that's not the use case for ECS, in that case you are probably better using OOP. just use the tools that makes sense according to your problem.
You can still do that using DOD. It's all about how you're laying out your data.
falls under "best tool for the job". you wouldnt use a hammer to drive a screw. you wouldnt use DoD (typically) for in-game systems that deal with a single instance (such as UI or editors). i know this is a simplification but let me know if i'm just totally missing your point. DoD is 100% applicable in many game systems and ECS is just one implementation of DoD
@@gcp-starchump Why not use DOD for single-instance stuff? I think you are confusing DOD with ECS a bit, because you can totally use DOD for UI or editors. It would most likely be even easier to maintain and run faster than with an OOP implementation. Probably not as noticable as when there are many instances like AI, but OOP usually quickly turns into a clusterfuck of a million classes and sub-classes.
@@Mike-uk2oq yeah i was using DoD interchangeably, my bad. from what i can tell, ecs would definitely be a bad choice for interfaces cuz it sounds like a pain. i'm all for DoD when it's the right choice
I really want to eat cookie dough now 😢
Very good video but I found the reason of using DOD to be bad.
So at the end is not like OOP is bad because is more human related and readable because of that, it is bad only because memory does not work like human abstract thoughts.
In short, devs should adapt their thoughts and systems to work for a machine instead of the other way around. Sad think honestly.
time= 14:12 you really like cookies, don't you?
14:20 anyone else triggered by the eggs?
no
@@EJM07 lol
Good, but it lack of the disadvantages of DoD. (Debug ...)
Man, this C++ code presented as OOP is not the way you would do it in Unity. You wouldn't have an Animal class and derive from it. You would have a Movement script, a Reproduce scripts and so on. Unity is already designed as a powerful ECS. You can pretty much avoid most of inheritance code here.
As of memory layout issues, why not solve it internally in the engine if it poses any problem? Or using object pooling when needed?
I think this ECS hype has only one purpose: Bringing big, 'professional' teams to Unity by claiming more 'advanced' features than Unreal Engine. At least the 'advanced' part must be marketable to clueless Managers and Investors. They should instead develop some real world games with their engine to experience the bugs, missing features, missing work flow improvements and all other drawbacks first hand. We tell them all day. E.g. still you cannot adjust camera speed in Editor, a feature UE has since 10 or so years ago.
You still have the issue of indirect dispatch and data managing themselves.
If I have a C# dynamic array of classes that have virtual functions for Update I have 3 levels of indirection, meaning that it's potentially 3 separate memory lookups needed to do from RAM.
At least two of these lookups will occur every time the component iterates, and will result in the procedure being completely uncacheable.
Pooling won't solve this issue because it's not just an issue of data access but rather relativity to each other in a system operating on them. In the memory pool, the pointers to your classes may all be in one place, but those class's actual data and their virtual functions will be somewhere else regardless.
Solving the problem internally would have definitely caused less headache for people using Unity having to learn a different pattern for composing entities, definitely, but it simply isn't feasible due to the design issues stretching into how the users of the engine are having to write mono behavior code.
Sorry, but I'm a bit disappointed by this talk.
It starts with an unnecessary "OOP is the root of all evil" bit in the beginning (complete with the usual "just look at this mess OOP makes" nonsense), culminating in claiming that data-oriented design wasn't more difficult, just different. I'm sorry, but that's about as valid as claiming getting a hamburger in a fast food joint wasn't more difficult than cooking a decent meal. Of course it is... just as data-oriented design is harder than slapping together a few game objects with MonoBehaviors that do what you want. One can be done "on the fly", the other requires you to understand your problem fully, build an appropriate data abstraction for that problem and design a system to work on that data.
After that, we get into the "why" of data-oriented design, which I do get, but have heard already dozens of times. We barely touch on "how" a design process in that system would actually work and I must have missed the "for entity component systems" bit completely.
So... "understanding data-oriented design for entity component systems"? Not really.
And I'm still wondering on how much performance this actually increases in an actual use-case. Every single example they use are crazy absurdities that would never be done anyway.
What about all the objects that you only have 2~3 uses in a Scene. Or that is activated every now and then and things like that.
Is the increase in complexity really worth it? I'd say that for 99% of the cases, not really.
What I'm actually thinking is that you should use OOP as usual and have a thing here and there to be the ECS way. Say a custom animator, AI, things like that.
@@HenriqueGdeC Yes, I also doubt the performance benefit for objects you don't have dozens, hundreds or thousands of instances of is all that great. For example, the first ECS demo I've seen was that space shooter thing: It would have been interesting to see how the performance compares in actually realistic scenarios for that. Not tens of thousands of ships, but perhaps around 10.
I also agree that for most projects, it's probably best to mix & match.
Thank you for mentioning this! I also agree with the other replies, how much performance increase do you actually get? I did some minor testing, and I was only seeing improvements of 300 microseconds per frame...
@@HenriqueGdeC She very clearly alludes to the performance gap, at least.
She did not provide numbers, but if you're curious, an x86_64 based cpu will burn 100-300 cycles on a main memory access, as opposed to 3-15 for a read from L1 or L2. Find the difference between 3-15 and 100-300 and you'll know how much slower your OOP code that ignores that basic reality you're living in is!
The variance comes from a variety of factors, include the fact main memory reads are also often 2x slower when it is not word-aligned - 32 bits on x86 or 64 bits on x64 just due to the fact you will actually have to do two reads instead of one in that case.
Of course, if your game only has two entity types, and there's never more than 10 of them, ECS is usually overkill. But this is a talk at Unity.
They are trying to make good general purpose tools.
Beyond that, the whole purpose of archetypes is to eliminate the over-generalization that sometimes happens with other ECS implementations, and it does a pretty good job, imo.
@@churchianity I know that DOD is faster in performance than doing the oop way and this video explains very well at least for me, but... The problem is like at the end devs are constrained to develop things for a machine instead the other way around. This counter intuitive way of abandon human thoughts like relating characteristics together to describe a thing, or do things like classification, etc, is just wrong honestly.
Devs end up being like slaves to the machines. Adapting their thoughts and processes to match for a certain hardware, instead of using/designing hardware (a tool to an end) to express their thoughts. Very sad honestly.
Data Oriented Design seems to be just a new name for column based data stores. This is not a programming paradigm at all. Tools like Sql Server Analysis Services, etc. uses these and many other techniques for years, yet still written in OOP languages like c++. Another point of confusion created by marketers to confuse developers... nothing but a good optimization technique...
There's quite a bit more to it than that. Sometimes it's the opposite and favors the AoS (interleaved format, like xyzxyz as opposed to xxxyyyzzz) for random-access patterns (the SoA or column-based format is often less efficient in random-access cases involving multiple fields being accessed). Sometimes it's splitting hot fields away from cold fields, rarely-accessed. Sometimes it's realizing an n-ary tree might work better than the binary, 4-ary, and 8-ary trees that tend to be popular in CS, or realizing a hash table with linear probing might work better than separate chaining even at the cost of more iterations in collisions. Sometimes it's realizing that maybe we can't abstract away certain details like the pixel format of an image without significant degradation in performance which can also significantly cut into productivity at some point if the discovery that such abstractions are barriers to optimization too late in the game.
Most of all, it's about putting the data at the forefront of critical designs and discussions among devs during design meetings. It's the antithesis of encapsulation which tends to want to hide data and turn it into an implementation detail, sometimes at great expense to the hardware or people maintaining the code or both. Sometimes it's reminding ourselves when we're tempted to build layers and layers of abstractions obscuring the data to simplify, and remember in many contexts that the data really matters and that our jobs as programmers are not to enforce our world views in a codebase of how things should work but to effectively transform data from one form to another. There are a gazillion image libraries, some more complex than others, but they all have one thing in common: they input and output pixels (arrays of numbers). Remembering that can prevent us from designing convoluted IImage, and IImageFactory, and IPixelFormat, and so forth. It can put us on the same page with respect to design in a world that resembles the Tower of Babel scenario where people get so inspired to reinvent wheels over and over primarily with the intent of hiding data that they can no longer communicate with each other.
For example, the AutoDesk people ignored/forgot this style of design with FBX. Instead of designing a clear, concise data format and representation, they built a convoluted one that requires a monstrous SDK to import and export the format. And that's probably why FBX has such limited support, especially in game engines, since they put the data in the background (they made it an implementation detail) and made it so the only way to practically work with their data format is with their tools. A data-oriented mindset wouldn't design file formats in such a complex way as a sort of afterthought where the only practical way to work with the data is by using a specific set of proprietary tools and abstract interfaces. It would be at the forefront of the design and its discussion. If they did that, wide support would have been easier, among all sorts of developers and ones using completely different tools and possibly even completely different programming languages, because the data is the ultimate thing that puts us on the same page -- not SDKs, not programming languages, not tools -- it's the data. Remembering about DOD can serve as a friendly reminder not to forget about the importance of data in a world that wants to push it to the background and out of the spotlight.
Unfortunately, it's not exactly the type of subject that's taught in most CS courses, and material related to it is scarce, and the people who attempt to teach it tend to have to market it as a result by showing off its performance. But far beyond performance, design is ultimately about communication. And the "design" aspect of DOD is remembering that data is the *universal* communicator among programmers. You might have your own way of doing things, and I might have mine, but if there's a chance for us, and our code, to work in harmony with each other rather than fighting each other and requiring all sorts of glue code and layers of translation, it's ultimately going to be about mutual understanding of the data. I might pass you a mesh and you give me back a deformed mesh. I might pass you an audio signal and you give me back one with reverb. I might pass you a sequence of numbers and you give me back a sorted sequence. You might pass me a scene and I give you back an image that rasterized it. We transfer data between each other at the end of the day, and both of our lives might be much easier in many scenarios if we don't try to obscure it and make it very difficult to access by imposing interface barriers between each other in the form of superfluous abstractions.
One of the stupidest design decisions Unity has ever made was pushing the completely-different ECS system. What they should've done is something like introduce a new ParallelGameObject parent class that requires all members to be serializable and a couple of other restrictions, and then behind the scenes it packs them into same-sized struct data and does effectively everything ECS does, just with the classic OO interface to the programmer on the front.
This still feels like premature optimization for me. Like if you are using OOP correctly, you will not run into memory issues most of the time. Most of the time you will end up being quite happy with how your code is turning out as well, and everything makes sense in how it reacts (again, if you are doing it properly, which requires a lot of practice but ends up working out quite well in my experience)
I still feel like OOP has a much more simple elegance to it it where as DOD feels like throwing away everything we've done over the last 30 years and writing code like cavemen. The ECS code is ugly, and a real pain to work with. Not just different. You are trading clean, easy to follow, elegant code for performance. Which is a fair trade to make *where it counts*. DOTS overall feels like massive premature optimization. The majority of a game's code isn't going to really benefit from this change. Especially in an indie game. Only a small bit of it really needs this drastic level of optimization, but I feel like Unity is nudging/pushing to have entire games built using this new method.
This is not the only way to DOD but honestly OOP code is rarely "easy to follow". Just dont assume any paradigm creates good or bad code its rarely the case. This talk just steals from every other DOD talk without giving any credit to who they are stealing from typical UNITY garbage.
Furthermore OOP is far older than 30 years and is really not that revolutionary. DOD programming is not really a paradigm but a different way to think about things. This talk was garbage.
Actually it's other way around.. cavemen would've thought in simple objects.. this stuff is thinking molecularly. Going above or deeper than worldly stuff. Like using or implementing God particles or building stuff with atoms. You should use both concepts.
I think they just made an opportunity to make make games, where you can have tons of objects/audio/textures etc. This is not for common cases, only if you need huge boost in performance. Theese are just tools, not guideline to make all Unity code.
In my own experience as a hobbyist game dev, I've already moved to using component design over oop because single inheritance is limited and multi inheritance gets confusing and error prone. It's proven to be easier to break things up into blocks that can be added or removed. So for example, my last project had hopping or straight movement behaviors that operated on the objects velocity reading the objects move speed. I personally find that a way more intuitive system. Makes prototyping and consistent, reliable code reuse much easier.
And I'm looking forward to this actual architecture instead of my hacky way of doing it.
too much yapping. as linus said "Talk is cheap, show me the code"
I feel I couldn't learn almost nothing from this talk... she didn't show a real example OOP vs DOTS!
Can someone help me understand what's the difference between L1_Cache, L2_Cache vs RAM. I'm assuming "Main Memory" means "hard disk"?
Gregory Fenn l1 and l2 cache exist on the processor, so they are faster to access than RAM
Memory comes at a wide range of different speeds. Apart from the speed of the hardware, physical proximity to the CPU also affects the latency. For this reason, computers compromise by having memory stacked in different tiers, where L1, L2, and sometimes L3 cache are increasingly larger but slower, and the largest and slowest of all is your main memory (RAM). Whenever you do some kind of operation on a piece of data, that data and a decent chunk of the data around it, is moved to the cache memory. The more often you use it, the higher up the cache tier it moves, and if you don't use it, it gets replaced by some more recent/important data. This is to make sure that memory access is always as fast as possible. The CPU always looks in the cache for the data first - if it doesn't find it there, you get a "cache miss" and the data gets loaded from the RAM.
L1 - L3 caches are on your processor. It's built into the chip itself for the fastest possible read times. Think of it like a staging area for your processor. RAM is your main memory. That is where active programs are held. Sometimes, your hard disk can be used to expand your RAM temporarily through the use of virtual memory. This is where the OS decides to write some data onto your hard disk.
For the purpose of this though, we're really only concerned with the memory in the processor and the memory in your DRAM sticks.
@@DovahMorghulis Main memory = RAM , but it's very slow compared to the cache
Summary of the talk: Fuck apples; you want oranges. Oranges are much better apples than apples.
OOP and OOD are two different things though, so saying "OOP is faster to say than Object-Oriented Design" is just straight up wrong.
I think you completely missed the point, she is talking about the very real-world effects of memory layout. You can be off in performance by a factor in the hundreds, if you don't consider memory when designing your system.
Designing your code around a model of the world, or programming by creating taxonomies and/or abstract relationships is the wrong approach. It doesn't particularly matter what acronym she uses, what she's fighting for is engineering based on reality.
It may be the time constraint she had for talks, but most of the time she felt like blabbering.
Although the content of the presentation is good, the presentation itself is like in a fast moving train.
data oriented design is just straight up confusing... OOP is so much simpler.
It's confusing if you've only ever written OOP style and, therefore, only viewed your code from the perspective of abstract real-world concepts rather than what the computer actually sees: data.
@@needlessoptions u just compressed her talk in 1 sentence. maybe unity should hire u instead :)
@@antonstafeyev3606 I wish 🙏😭
Ignoring your problems because you find it confusing isn't engineering
@@needlessoptions I know I'm late but your answer is exactly my main problem with this. While I know that DOD is better for a machine than OOP, we are missing the point that hardware as any other tool created by humans should work for us based on our understanding of things, not the other way around.
This is a philosophical problem. We should not think and design systems for the machines, machines should interpret and resolve problems based on our understanding of things. If machines can not operate efficiently on our processes, that's mean the whole design or architecture of computers is wrong.
For a software engineer she talks a lot of poo :(
Most notably, empty structs DO "waste space" - being one Byte(13:03). Pff
needs a /s, unless you’re being “technically correct” if it’s the latter get some help.
@@anthonymarquez2542 "a /s"? English?
If you watch ECS videos and thus care about performance with many entity instances but don't care about RAM, I think you should look in the mirror first.