Building a Data-Oriented Future - Mike Acton
Vložit
- čas přidán 5. 07. 2024
- Dive into what data-oriented engineering means, how it radically impacts software engineering efforts and will drive us toward a future where our users get more value from their computers.
Visit the largest developer playground in Europe!
www.wearedevelopers.com/
Facebook: / wearedevelopers
Twitter: / wearedevs
Instagram: / _wearedevelopers
#WeAreDevs - Věda a technologie
Please don't hire these people to record the talks ever again.
70% Mike Acton, 30% shots of developers looking super-uncomfortable.
If you don’t look uncomfortable watching a talk are you even a developer?
33:00 video editor/camera operator completely misses the most impactful slide of the talk.
czcams.com/video/rX0ItVEVjHc/video.html
Nihal Kenkre Thank you!!!
Excellent intro on Data Oriented Design, dutifully sabotaged by the TEDified idiots behind the camera. Thanks for the missing slides guys. Whoever was in charge of production is shockingly incompetent.
I enjoyed Mike Acton's talk, as always. The biggest issue was the lack of screen time for the slides. It makes it difficult to follow along.
Yeah. One moment that especially stood out was when he talked about L1, L2 cache misses and demonstrated how much time it takes for the CPU to fetch data from main memory. The audience saw the animation, we didn't.
And someone who never saw one of Mike's talks before will be confused about why he's so quiet suddenly.
Why is the camera zooming on strangers? Distracting cringe.
And always zooming in on the same chick. Methinks Cameraman has a crush.
@@Be_Captain :D exactly
@@Be_Captain Good taste tho.
The clowns that mike kicked out of the car.
Even Mike was looking at the slides at 33:24 but you guys don't show it to us? Who the heck cut this video? literally wtf
uh hi
developers: nice a cool and interesting talk to listen to with some cool slides
conference producers: let me show you our awkward looking audience all the time that just wants to listen to the topic at hand and ideally not be filmed, i'm sure you will find that very entertaining
"First you need to get those clown out" .. this guy really doesn't pull his punches.
I wish we could apply that to the camera manager...
really great talk.
video was cutted weirdly though.
no gained information in showing the audience (rather distracting) and also in not showing the slides when it would be beneficial to do so.
I want to see a video of him comparing the before and after of unity's codebase. I wish he could do it with ue4 as well. Anyone thinking that their game running poorly is because of hardware is wrong, because it is programmed in OOP.
See Mike Acton with the talk - instant like
I feel that for the sake of brevity and simplicity, it would have been better for Mike to show an Object Oriented Programming example that fails with rendering a large number of items on screen, then show a Data Oriented Design example that solves the problem. Then ask, "Why is this a problem in OOP, but not in DOD? Here's why..." In a mere 30 seconds, people would have been able to fully grasp the problem, understand the impact of DOD, and be primed for a more detailed explanation for the remainder of the talk. He could have very simply linked "bad OOP" to "cell phone battery dead" instead of explaining it like a drab college lecture on logic.
He gave a talk in 2017 at GDC where he did just this. He showed a Unity tech demo and how it ran before and after the DOD overhaul. It's on YT. Def check it out!
I feel like it's a bit misleading to refer to these two paradigms as if they're an algorithm that can be swapped out. At their core, they are a set of principles and are a mindset. What Mike Acton is doing here is trying to convey the mindset of DOD. It is a little contrived, but the message that you should look at a program as something that transforms data is a good one, and one that is difficult to see for many people.
Gotta say, most videos on CZcams I view in 1.5 - 2 speed but Mike… Mike I need .75 to make sure I absorb it. He’s real close to my college C teacher back when I hated coding but liked engineering.
So don't listen to John carmack
Pure awesome talk. Mike, please a book… :-)
thank you camera man for pointing at literally every women in the crowd. Like "ah yes, it's not all men here, see look: these two"
33:00 nice that the regisseur decided to film the speaker and the audience instead of the most important thing...
Camera was distracting. We came to watch *actual data* not storytelling of the conference. Such irony is beyond my capacity to handle!
I've snubbed Unity for using C#, but this really convinces me. Low-level rendering code in C++, Shader Languages, and GPU Rendering APIs, with HP C# being used for ultra-performant scripting. Very different than the XNA C# of old. I've been on a Rust, Zig, Jai kick for a while now, but I've always had a partial fondness for C# (when comparing to Java) and the fact that it's this well-opinionated subset is actually incredibly appealing. I wish I was more clued in about this earlier.
The "clowns in the car" always make me laugh.
Should have performance comparison at the start of the talk to show people how important this movement he is preaching actually is
I began my career in a very weird manner, easiest way to convince someone of the gains to be had is to have the programmer try to solve any form of exponential coupled data problem and then show them the data oriented method of solving it, because lets be real programmers are smart usually but still very human, demonstration is almost always infinitely better.
I am a Linux user (current Unity version is real crap there). This talk almost got me installing Windows to try these Unity features
At 17:27: Does this mean we get Floating-Point-Determinism across different architectures? And will this potentially make it possble to have deterministic network based physics across platforms? That's rocket science level. Would be awesome!
This is a tech talk not a Hollywood reception. Please record the slides and the speaker. No one cares about the attendees.
Tough crowd - the organizers for this talk should have instituted a "You must be this tall before entering" entry gate system, to ward off all the whiny javascript programmers that left early.
Why is the public included in the video at all. This is a programming talk, not the fucking X Factor.
Almost unwatchable because of the camera operator. Just listen to it as a podcast.
Literally wearing rose-tinted glasses
Like every other comment says here, the filming and editing sucked.
You probably overpaid. The purpose of the video is to educate, not show the room. A single guy just filming the presenter with a handycam and an overlay of the slides would have been infinitely better for the intended purpose of this video.
camera is aweful. instead of filming the audience, putting on the slides would have been much more valueable. This is not an entertaining video, but a learning video
It’s fine the slides are not useful anyway….
Looking at data is great until it's
Bit format like uint8 for file format. This is where objects shine. But he brings great points
Whoever was responsible for the cameras probably also made all those shitty music videos where half the time you only see hyped people in the audience jumping aroung instead of, you know, the fucking musicians.
Gotta be straight up, I hated the way this video was made. I don't care about the audience. I don't want to just stare at Mike's face (as beautiful as it is). I want the slide and mike in the corner, that's it.
mike drop, got it
TL;DR: Write your game in C.
I was hoping for something technical, but is this just a sales pitch for Unity?
To me the only "sales pitchy" thing was when he listed the numbers of Unity users etc. in the beginning.
What else do you mean?
This applies outside of Unity. He made virtually the same presentation in way more detail at CppCon 2014 before he ever started working for Unity.
czcams.com/video/rX0ItVEVjHc/video.html
Not the same talk at all
Not a sales pitch for Unity so much as a sales pitch for the "new way of using Unity". The audience is people already using Unity and he was advertising that a new feature is coming that will improve performance but requires some getting used to on the part of developers.
- "Unity runs on 25+ platforms."
- "Software is not a platform."
Can you explain what is contradictory about those statements?
3 billion devices run unity. 3 billion devices run java. is unity just a trojan horse for java or something? and whats up with the 3 billion? some hidden meaning maybe? nwo?
Every talk he has he seems to have horrible cameramen, geez.
What a talk ... full of opinions ... quite few arguments ... Mr. Acton should have talked about the evolution of architectural paradigms behind the UNITY-engine ... what is it that the UNITY-engine became so dominant in the market place ... is it technology alone? ... which? ... why made them the UNITY-engine the prefered one ...
His chosen title of this talk is more one for the future of the whole computer industry ... not just the world of gaming ...
I'm not sold on data oriented design. Yes it obviously gets you performance gains. But performance is not everything. Ease of use and clean, understandable code is also valuable. It's part of why Unity has been so successful. Beginners can easily learn to just throw a c# script on a game object and call high level functions like LookAt() or SetActive() and see it just work. That's abstraction. Being able to write code once and deploy it to 25 different platforms? That abstraction. I'm all for making performance gains, but let's acknowledge that there are tradeoffs.
This point is literally addressed in the talk around 12:00.
@
Boggled Eggnoggler You can still use such convenient functions like `LookAt()` in a data-oriented architecture with an open data mentality to its design. The difference is that if you need to do a fairly complex transformation that involves inputting a transformation matrix and outputting a new one, you don't have to try to figure out how to do it with complex interfaces and layers upon layers of abstractions that hide that vital data as in object-oriented designs. I've had colleagues before who worked with abstract `ITransformer` interfaces that would write the most convoluted code trying to just do simple things like align and snap one object to the surface of another, and mainly because the layers of abstractions made it so difficult for them to input the actual data.
Except those lookAt() and setActive() functions never "just work". They're built on top of something else, and when there are a problems (there are always problems), you will have to dig into what those functions actually do anyway. You don't solve problems by pretending they aren't there.
@@tedbendixson That's one thing I found as well -- we had such a complex interface for the analogical transformer, including functions involving pivots, and rotating pivots, and whatnot. In fairness, my team consisted mostly of academic R&D types heavy on computer graphics research -- maybe far more academically smart than smart about designing easy-to-use interfaces for things, and they were from various parts of the world -- English wasn't always their native language.
So I found myself and some colleagues often frustrated -- like just gimme the damned 4x4 matrix there. I know how to align two surfaces together with basic linear algebra -- the math is simpler than the complex interfaces they gave me and the manual-style verbose documentation they'd write (they'd literally write about 20+-page documents into source files and call them "usage manuals").
I find that a recurring problem in computer graphics -- like the domain knowledge required is already sorta steep, but once we break through it, the plainest representations of data are what we master.... not someone else's idea of how to abstract it. It's like I've been working long enough to understand all images are just 2-dimensional matrices of some vector or scalar type. pixel=y*img.w+x or, for power-of-two widths, pixel=y>>img.bitshift+x is burned into my brain from the DOS days. It's second nature to me now... but not like get_pixel(x, y), or set_pixel(x, y), or convert_pixel(x, y), or ImageFactory, or PIxelConverterFactory, or any of that OOP BS people wanna pile on top which, from my standpoint, provides not only some obstacles for the optimizer but for veterans as well in this industry.
What I like with suggesting lookat() functions and stuff if people wanna build that on top of a data-oriented engine is that they can do that... for their personal use -- in a sort of modular way. Just don't expect me to use it or debug it. I recommend that for sorta high-level developers who struggle with these things to build whatever convenience stuff they wanna put on top -- including object-oriented designs... But I think at the core engine type of level which tends to demand a high degree of domain expertise anyway and has a far larger portion of critical execution paths and performance-critical code than maybe even Knuth would ever have anticipated, it helps to just expose the data if in doubt.
@@tedbendixson Well, my sort of rude thought on this is that OOP is best for beginners.. along with languages like Python and whatnot.
So for people who don't know how the basic math to access a pixel at a certain row/column, or normalize vectors, or do transform with pivots, or anything of this sort, they can build layers of abstractions on top of our engine. And that's fine -- just like how some people who aren't very savvy at this stuff write their game mods for Unreal using Python or whatnot.
My thing is like just don't write the core engine in object-oriented Python let alone object-oriented C++. It will be horribly inefficient typically for both CPU and veterans used to transforming and accessing memory/data very efficiently.