CppCon 2014: Mike Acton "Data-Oriented Design and C++"

  Рет қаралды 632,517

CppCon

CppCon

9 жыл бұрын

www.cppcon.org
--
Presentation Slides, PDFs, Source Code and other presenter materials are available at: github.com/CppCon/CppCon2014
--
The transformation of data is the only purpose of any program. Common approaches in C++ which are antithetical to this goal will be presented in the context of a performance-critical domain (console game development). Additionally, limitations inherent in any C++ compiler and how that affects the practical use of the language when transforming that data will be demonstrated.
--
Mike Acton: Engine Director, Insomniac Games
--
Videos Filmed & Edited by Bash Films: www.BashFilms.com
*-----*
Register Now For CppCon 2022: cppcon.org/registration/
*-----*

Пікірлер: 697
@origamibulldoser1618
@origamibulldoser1618 10 ай бұрын
Don't mind me. I'm just dropping by to refresh my sanity, once again.
@nicbarkeragain
@nicbarkeragain 2 жыл бұрын
The thing that makes this talk so special is that once you start your journey down the "data-oriented rabbit hole", you inevitably end up coming back to watch it multiple times over the years and getting more out of it each time - basically every sentence is packed with insight.
@askeladden450
@askeladden450 2 жыл бұрын
that is literally me lol. currently watching this for like the 20th time.
@dandymcgee
@dandymcgee 2 жыл бұрын
This is at least my third time watching it.
@amit-mishra
@amit-mishra 2 жыл бұрын
@@askeladden450 same i am sad it doesn't have subtitles for some reason after few minutes else i would have taken out them as text and would like to read through it. Navigation throughout speech would have been much easier in that case.
@paulcosta8297
@paulcosta8297 Жыл бұрын
We want MORE of this from Mike Acton. Bring him back to do a 2022 version of this talk with new examples and assembly inspection.
@sheanmassey
@sheanmassey Жыл бұрын
My 3rd trip in 3 years. Hello my fellow DDD crew.
@jearsh
@jearsh 2 жыл бұрын
dude literally took pictures of a whiteboard with writing on it to make his slides...my hero
@goranmilovano
@goranmilovano 9 жыл бұрын
@1:18:00 - "Ok, great. You don't care how long it takes ... Great. But people who don't care how long it takes is also the reason why I have to wait 30 seconds for Word to boot." Mike Acton really knows how to put things in perspective :)
@Domarius64
@Domarius64 4 жыл бұрын
I did like this comeback, but have to say, there's a difference in priorities there and both are valid. Some people have been saying in other comments. Software like Word, may not be the fastest it could be, but it solves the problem best and might take a performance hit from being multi-platform, but it makes it more useful for more people. There's always a tradeoff somewhere. If you want to go for performance you may have to skip out on libraries that save huge amounts of dev time, which may be better spent on adding features that save people more work hours. It just happens for games that performance is one of the highest priorities.
@darkengine5931
@darkengine5931 3 жыл бұрын
​@@Domarius64 I tend to think it's a massive legacy and hiring way too many programmers and ignoring Fred Brooks' "The Mythical Man-Month" that makes such software so bloated. That's one thing I think game devs tend to not deal with is millions of lines of legacy code spanning decades that have to be maintained for backward compatibility, since the hardware changes dating from bleeps and bloops with monochromatic graphics just some decades ago towards real-time ray-tracing and surround sound and massive parallelism today, and customers that always want more, require them to constantly toss out or significantly update aging code rather than just keep it around for decades (the exception might be Bethesda but they generate a whole of customer complaints as a result). Still, I think it's necessary for people like this to be very outspoken since the general programming culture these days is hardly welcoming of their ideas and techniques.
@DylanMcNamee
@DylanMcNamee 2 жыл бұрын
I have spent a lot of time looking at "Loading..." screens on console games. Once they've loaded, zoom, but still. This was the part of the hour I enjoyed the least.
@adude5136
@adude5136 2 жыл бұрын
@@Domarius64 I gotta disagree. I don’t think Word solves the problem best. Especially when you consider that it’s one of Microsoft’s flagship products, I think it’s a pretty poor solution. When I was doing my MA, I routinely had to open Word docs that were 30+ pages long with tracked changes, and every single time I had to sit and wait (on an i5/SSD) for those pages and comments to load in. If I left off one night at page 20, I knew I was going to have to wait twenty seconds before I could do any editing on page 21 the next time I opened it. God forbid it was a book chapter and the thing had 50+ pages and end notes. What Word is good at is being Word, as opposed to another similar software suite. It’s what everyone is using so the social and professional convenience of using it outweighs its objective quality. But nonetheless, it’s a damn shame. And I don’t think it has anything to do with being multi-platform. First because the versions display visible differences, suggesting that there is quite a bit of platform-dependent code in the picture, and second because multi-platform code in this day and age doesn’t have to suffer in the performance category. If something like SDL2, which runs on Windows/Mac/Linux utilizing native system calls on each, can be performant and incredibly simple to use, I’m not sure what excuse Microsoft has. Now, will a data-oriented approach necessarily solve all of Word’s problems? Maybe not. There are any number of reasons that DOD could be deemed unacceptable from Microsoft’s point of view, but if I were a betting man I would guess those reasons are largely business-driven (e.g. cost of labor) rather than software-driven.
@kerr1221
@kerr1221 2 жыл бұрын
@@adude5136 THIS. Personally I find rich text editors (like word) to be INFURIATING because they scale so poorly! Somehow they are slower today than when I first started using them on windows 95 machines! Fortunately I found reprieve with LaTeX, and now use it wherever possible. I spent some time learning it, but now use it any time I can for documentation.
@paulcosta8297
@paulcosta8297 Жыл бұрын
Still not over how I C O N I C this monumental Acton masterpiece keynote is.
@Sychonut
@Sychonut 6 жыл бұрын
I am a recovering object oriented programmer and have written a significant amount of data oriented C++ code during the past few years and while the "mental switch" is difficult at first thanks to all the Java "a car is-a vehicle, and 'has' four wheels" BS the universities have pumped into our brains, once you go data-oriented, there is no going back. The code is faster, easier to understand, more modular, and surprisingly much much easier to vectorize. Granted that I write low level code so performance is critical, but as Mike said at one point in the talk, I doubt that my mindset would change much if I was to write other types of software. As Mike likes to say a program does not run on ether. It runs on actual physical hardware, and it is important for software to cater to hardware and its fast paths, otherwise you end up with the kind of shit software (say your browser) that does not feel any faster than it used to 15 years ago. Programmers always grow in carelessness, and no more, until all system resources are consumed, and that's why an order of magnitude more processing power has not made our experience an order of magnitude better.
@jumbo_mumbo1441
@jumbo_mumbo1441 5 жыл бұрын
How do you get better at that kind of programming?
@BlackJar72
@BlackJar72 5 жыл бұрын
Well, this page has lots of resources, including a pro book as free pdf: www.dataorienteddesign.com/site.php I'm no expert, just starting to look into moving in this direction, but I'm sure practice (writing code and reasoning through problems) is keys as always.
@32gigs96
@32gigs96 4 жыл бұрын
Sam Claus I watched a talk where some guy showed a data oriented approach to the rendering engine (or at least a part of it) of chromium that had 6000 less cache misses. So while developing web browsers is very hard indeed I’m sure they can be much better than they are now.
@32gigs96
@32gigs96 4 жыл бұрын
Sam Claus web browsers kinda always end up being bad tho. They’re huge pieces of software developed by many people over LONG periods of time. So they’re kinda always gonna be “shitty”. I don’t think he was insulting browser devs when he said that.
@atilafernandes217
@atilafernandes217 4 жыл бұрын
I guess it's possible to conciliate both. And C++ can make awesome wrappers to hide the low level code. It's only when you have to make a choice, between data and object, that data must be oriented.
@bruterasta
@bruterasta 6 жыл бұрын
Well, Mike is now prinicpal engineer of Unity engine.
@atilafernandes217
@atilafernandes217 4 жыл бұрын
So, he is the one to blame for the change from C++ to C#?
@Billy1Famous
@Billy1Famous 4 жыл бұрын
Átila Fernandes unity used c# and js at first but they are using only* c# now. But I’d say he is one of the person pushing DOTS at unity.
@clodgozon3968
@clodgozon3968 4 жыл бұрын
The engine is built with C++
@Domarius64
@Domarius64 4 жыл бұрын
@@Billy1Famous This makes so much sense. A lot of the benefits of DOTS is reflected in this talk.
@DanielKierkegaardAndersen
@DanielKierkegaardAndersen 3 жыл бұрын
Also.. it's a technically not C#, it's High performance C#.. So it's a subset they made for C# called high performance C# which actually compiles down to native code.. In other words, no garbage collector! ;)
@lalirose
@lalirose 5 жыл бұрын
I think the key point hes trying to get across is batch your transforms. Identify where the bulk of the calculations are being applied and organise your data so that only the data that is necessary as input is congruent in a data structure to minimise cache misses to generate the output data as efficiently as it can
@DaveHoskinsCG
@DaveHoskinsCG 6 жыл бұрын
This guy makes a lot of sense. Basically programming is just a tool to achieve your goal. It's NOT about the journey, it's about getting results. It's not a life model.
@llothar68
@llothar68 9 ай бұрын
If you have to support this code for the rest of your life, then perspectives change drastically.
@alang.2054
@alang.2054 8 ай бұрын
@@llothar68 Yes, you make very good point. In codebase I work there is a lot of "data oriented" code, which is just fancy word for procedural code and it's very hard to debug.
@dekutree64
@dekutree64 8 ай бұрын
@@llothar68 Yeah, game code is sort of a special case because most of it gets thrown out after the project is done
@CyberDork34
@CyberDork34 7 ай бұрын
​@@llothar68 I think the talk is very interesting. But it's also true that console programmers, who work with limited resources, prioritize performance over everything else, and get to stop thinking about their code almost entirely after the game ships, will probably have different priorities than enterprise programmers that need software to run on "anything with a web browser" and will be adding new and random features to the system for years, maybe even decades.
@Ehal256
@Ehal256 6 ай бұрын
@@alang.2054 That's not good code. Code that is designed with the hardware in mind does not necessitate being hard to debug.
@PeterAndLeelien
@PeterAndLeelien 9 жыл бұрын
Mike Acton and Mr. 1:16 are BOTH correct. For many, dev time is worth more than CPU time. Many current software tools (i.e. anything "Java") caters for their needs. For others, outright performance or performance per watt is worth way more than their own time. E.g. game engines, or anything in a datacenter. If you save 10% on something that's run on thousands of servers, that's a win in terms of power costs. The problem is accepting that the other guy's situation is just as valid.
@TheBuzzSaw
@TheBuzzSaw 6 жыл бұрын
I saw this video the day it went up, and it seriously changed everything for me. I would not be the programmer I am today without Mike Acton.
@Mike-gs7eo
@Mike-gs7eo 5 жыл бұрын
I frickin love this talk. Keep coming back to watch it. There is some cold hard truths here that if you have been doing software dev for some time can be hard to swallow.
@andrewherrera7735
@andrewherrera7735 2 жыл бұрын
How would anyone know this. He makes us all look like jackassess cause we and most of our programs use OOP. Who the hell was expected to come up with a clever pattern that was built around the
@drygordspellweaver8761
@drygordspellweaver8761 2 жыл бұрын
Not all of us, Andrew.
@Muskar2
@Muskar2 9 ай бұрын
@@andrewherrera7735 We're not jackasses for not knowing. Only if we're actively denying it when we understand it. To be fair, I agree that Acton isn't doing the best educational presentation to someone unfamiliar with these concepts, and isn't even remotely doing its advantages justice but I also think that'd be a very high responsibility to bear. Keep in mind, he's probably grumpy because he's used to meeting so much resistance from people outside his company - because OOP has been the dominant sales pitch for decades. And I think that's because it sounds very appealing that we can just model our programs after our mental model and rely on experts to do the rest of the work for us. OOP is built upon the dream that you can build generic reusable modules to make all your applications exponentially more powerful as you build out its functionality. The problem is that its rarely true, and that it's so wasteful that it's only become barely possible to realize entirely because of hardware improvements. This results in many hours being spent trying to figure out how to get around the performance problems by implementing your own versions of various modules, without ever getting all the way down to the OOP assumptions (which is usually thought to be too extreme to even consider). Sunk cost fallacy and other cognitive biases is probably the main reasons that the dogma was created, but I don't think any ignorant individual bears responsibility for not questioning everything down to the very fundamentals. If we were, then we should perhaps also question the hardware implementation or the physics behind it. I think it's more important for the average person to not be afraid to question your assumptions every now and again, being open to other perspectives and learn to differentiate what's marketing and what's fundamentally sound advice.
@FreeLancerdu29
@FreeLancerdu29 2 жыл бұрын
I remember when this talk was release in 2014. I was impressed and show it to few mates. Then almost 7 years later, I realize I often came to pick few parts. Now this video is almost 0.5 million views. That's crazy for a such "niche" topic. Something has really been said during this talk.
@carloslemos6919
@carloslemos6919 Жыл бұрын
Also watched it in 2014, it is now the most viewed cppcon talk.
@gothikia
@gothikia 5 жыл бұрын
I'm so glad that someone finally stood up and told that audience in particular exactly what needed to be said.
@BobRaygen
@BobRaygen 10 ай бұрын
What gets me is the little comment that what this is what Mike defines as what a professional is, or should do. Diving into cache miss or wasted space cache space, cycle times, assembly assessment is just what is considered as a part of the job. The remark about how companies push for feature quantity over quality really is a insight into what many companies consider a professionally done job and where the focus is. It really is unfortunate that there is not wide spread focus on performant and efficient in addition to just working.
@phisyka
@phisyka 5 жыл бұрын
Wow, this really opened. my eyes to how important reading from memory is. I took a computer architecture course, but this lecture really hit it home for me.
@vsabadazh
@vsabadazh 7 жыл бұрын
I've been programming in C++ for a few years, but actually have never faced such problems. Now I find this topic very interesting. Thank you!
@Pixeldev999
@Pixeldev999 9 жыл бұрын
One of the best C++ talk I've ever watched. Kudos to Mike!
@odraencoded
@odraencoded 8 жыл бұрын
A good portion of this talk applies to general programming and not just ot low/mid-level C++.
@aliancemd
@aliancemd 8 жыл бұрын
+Leonardo Pereira Not really. Especially for strictly object-oriented languages this doesn't apply at all. He talks about using the cache efficiently and you say this can be used in other languages(Pointer to an array of pointers to objects - that's your Java/C#... cache misses). May be restructuring the data can help, but it won't cut on cache misses which is the main point... To call contiguous blocks of memory in order to be cache + prefetcher friendly(again, pointers to pointers, aka most other programming languages - defeats the purpose).
@nameguy101
@nameguy101 8 жыл бұрын
+Lilian That's because strictly object-oriented languages are shit.
@tomgillen4982
@tomgillen4982 8 жыл бұрын
+Lilian You can implement all of this in C# (but then, C# is not strictly only an object oriented language). It's Java that makes it unworkable.
@MyAce8
@MyAce8 8 жыл бұрын
I'd say it applies to all multi-paradigm languages. I don't think it applies to pure OO languages like java which are all about abstraction (although I think this talk implies that we shouldn't use java/.NET for anything which is weird because he uses C# for some of his code base)
@MyAce8
@MyAce8 8 жыл бұрын
although you can do some of this in C# it's awkward. Imo you should use c/c++ instead of C# if you're not going to make things super abstract. all of the cool things you can do with .NET breaks the "Data -Oriented Design" rules he lays out in this talk. Don't use C# like c++. use c++ like c++
@Domarius64
@Domarius64 4 жыл бұрын
Mad respect for this guy. Not just for his no bullcrap high level approach but his ability to give a programming talk without getting bogged down in the details. Just minimal code examples. Also I like how he cuts through the bullcrap of some of the questions and gets to the answer quicker :)
@danieldahlkvist1920
@danieldahlkvist1920 9 жыл бұрын
If what you saw interests you I can recommend reading up on "structures of arrays vs arrays of structures"
@notmynormalusername1
@notmynormalusername1 6 жыл бұрын
"but we aren't performance constrained, we're engineering time constrained!" This is why we can't have nice things.
@manawa3832
@manawa3832 4 жыл бұрын
The fucking reason you have nice things is because engineers are pumping out more software today than ever in history BECAUSE productivity is valued over irrelevant software performance gains.
@pavelsmejkal7187
@pavelsmejkal7187 4 жыл бұрын
I thought a similar thing. And Mike replied nicely - that's why my Word takes 30 sec to boot...
@jackmordaunt5410
@jackmordaunt5410 4 жыл бұрын
Dingo Egret why so agro? Sometimes performance is more valued and sometimes features per line of code is more valued. Depends on the context. In general you tend to see the max productivity as long as performance is “good enough”. In hard real-time systems “good enough” is hugely different to a distributed business application. Other than that you have corollary factors like developer IQ. Some languages give less control but require less IQ to use. This opens it up to a much larger market of coders - which might be exactly what your business needs: manpower, not necessarily raw technical prowess.
@notmynormalusername1
@notmynormalusername1 4 жыл бұрын
​@@manawa3832 Remember when Mike Acton suggested shipping games a year or two later to optimize their core game systems for no reason? neither do I. There are different industries and projects with different constraints, I get it. I really do. However please consider the fact that a lot of lazy-ass engineers make bad decisions because they can't be bothered to think about the implications if it "just works". Today I saw someone use a try catch around a single vector::at to see if their index was in range. My friends company outsourced the maintenance of their app in market to another company, and that kind of shit happened. This isn't a "this or that" argument, you can care about performance and user experience.
@isodoubIet
@isodoubIet 3 жыл бұрын
@@notmynormalusername1 "Today I saw someone use a try catch around a single vector::at to see if their index was in range." If Acton's point were "don't hire idiots" I'd wholeheartedly agree, but that wasn't really the point.
@Nyocurio
@Nyocurio 8 жыл бұрын
This response is really ironic considering the speaker basically said "the only reason we're using C++ instead of C is that everyone's just used to it, and Microsoft's C++ support is better". The speaker didn't name a single C++ feature that's useful to him, and I suspect if he could, he would go C only.
@DmitryKozlovtsev
@DmitryKozlovtsev 6 жыл бұрын
I'm sure he uses templates
@aliancemd
@aliancemd 6 жыл бұрын
The talk is about how you arrange and handle your data and you get out of it: "He didn't mention C++ features and would go with C only"...
@asdfghyter
@asdfghyter 5 жыл бұрын
No, he explicitly said that there was a soft-ban on templates. However, he does use other code generation tools.
@Bakuta1103
@Bakuta1103 5 жыл бұрын
easily my favorite cppcon talk ever
@JordanHolcombe
@JordanHolcombe 7 жыл бұрын
lol... multiple inheritance "that's just dumb". enjoying this video :)
@colinferguson647
@colinferguson647 8 жыл бұрын
I was never that interested in game programming, but I love this bare metal stuff. I like this guy, I'd work for him in a second.
@BalanNarcis
@BalanNarcis 6 жыл бұрын
Everything is bare metal stuff, people just don't want to think about it, lazy people, shitty software.
@stevesan
@stevesan 5 жыл бұрын
@@BalanNarcis i like DOD, but the truth is...who the fuck cares if word takes 30s to load? most users launch it once per day. if you don't like it don't use word (who the fuck uses word outside of lawyers these days anyway?). i suppose there's an environmentalist argument to be made here, but hey i still eat meat and drive cars so i guess we're all bastards. anyway, if perf is important for your domain, you must know this stuff. not arguing. but there are industries that don't need to worry about it.
@jamesmcmanus
@jamesmcmanus 5 жыл бұрын
​@@stevesan Hundreds of millions of people use Word. And people do care if their software is slow, whether it's Word or anything else (Word in particular didn't seem terribly slow last time I used it...), but they're taught to believe "that's just how it is." Those who realize what a cop-out that is usually don't have any influence to change the product's priorities on their own.
@darkengine5931
@darkengine5931 3 жыл бұрын
​@@stevesan The sad thing to me is that it is a relatively small effort in my experience to make those types of applications load instantaneously provided people put the bare minimum effort into maintaining the barebones quality standard instead of letting inefficiencies pile up left and right over years and years. It doesn't require someone that is constantly profiling an application's startup times. If I use an environmentalist analogy, I'm not talking about making the world live on a sustainable diet. I'm talking about people ceasing to throw cigarette butts on the floor when they have an ashtray 5 feet from where they're standing. You know, it's like I've worked in companies before where their codebase had over 200,000 warnings in a full rebuild (in GCC, in MSVC, in ICC, in CodeWarrior -- over 200,000 on every single compiler and close to half a million on GCC). Yeah it's hard to fix now but it wouldn't have been that hard if they weren't ignored for so long. A team needs that same kind of analogical level of wastefulness and neglect to make a word processor take half a min to load on a modern machine.
@morpheus7422
@morpheus7422 2 жыл бұрын
@@darkengine5931 200k? Holy moly, who's going to fix that?.
@meltygear5955
@meltygear5955 Жыл бұрын
You know a talk is a banger when the youtube "most played" analysis resembles that of a mountain range.
@quickfiredan
@quickfiredan 9 жыл бұрын
My point was that the C style of coding and data-design is very well suited to cache-friendly algorithms, while the C++ style can very easily do things you are not expecting that result in poor cache coherency. I will personally switch styles depending on the type of code I am writing. For instance, a manager hierarchy running on Cell PPU can use constructs and style that would be counter-effective in a DSP algorithm for Cell SPUs.
@wearecomingback5707
@wearecomingback5707 8 жыл бұрын
The best talk ever, It simply puts up together two ideas, 1- a language is simply here to express an idea, it is not the idea in itself. 2- all the ways lead to Rome , which means to speak your idea don't be afraid to talk ASSEMBLY!!
@tathtath
@tathtath 8 жыл бұрын
+We are coming back c is closest to assembly and for me - my favorite programming language :)
@MyAce8
@MyAce8 8 жыл бұрын
I prefer c++ even though most of my code looks like c because it gives me freedom to use c++ stuff whenever I want to.
@JackMott
@JackMott 7 жыл бұрын
Recently in one of my weekly reddit rants about performance someone sarcastically replied "Oh well then why not just write everything in ASSEMBLY if performance is all that matters" and I thought, well obviously the developer time / perf tradeoff is not always worth that, but YES I want some rough approximation of the assembly to be in your HEAD as you write your C# or whatever. I want everyone to at least be able to *check* the assembly in hot loops and critical paths. sigh.
@EnduranceT
@EnduranceT 7 жыл бұрын
I agree with you, but as both a C# and C programmer, it's so much easier for me to visualize the assembly level stuff when I'm programming C. The culture behind C#, especially for back-end web, is just importing, newing, and forgetting... And I hate that. I hate the lousy bullshit that is plaguing the industry right now, which is why I'm trying to stay away from web dev with a 10 foot pole.
@wearecomingback5707
@wearecomingback5707 7 жыл бұрын
EnduranceT haha.. 10 foot pole.... hilarious
@versatran01
@versatran01 Жыл бұрын
Come back rewatching this every year
@charlesd4572
@charlesd4572 7 жыл бұрын
I take his point. We profile our code and view the disassembly and it definitely helps at even a coarser grain then what's being discussed here. Sometimes the compiler won't use the best instructions. In those instances intrinsics or even hand written assembly is worth it.
@cgikoray
@cgikoray 9 жыл бұрын
Hilarious and informative. Thanks for being awesome Mike Acton :) I learned something today.
@godDIEmanLIVE
@godDIEmanLIVE 4 жыл бұрын
This is incredibly interesting and important.
@gibgezr
@gibgezr 8 жыл бұрын
With a lot of C++ code, doing very basic data-driven design gives you a 5-10x speedup; on some stuff it is 50x. Upgrading your processor rarely gets anything near that. Upgrading your RAM never gets you anywhere near the low end of that, unless you were running without enough RAM to begin with and paging everything out to the hard drive.
@arunabraham9382
@arunabraham9382 5 жыл бұрын
gibgezr Have you checked D language? Fast language like C but efficient in productivity.
@Qizot
@Qizot 5 жыл бұрын
and probably will never be used with large projects
@drygordspellweaver8761
@drygordspellweaver8761 2 жыл бұрын
I page out to an SSD thank you very much!
@MordachaiWolf
@MordachaiWolf 9 жыл бұрын
OO just doesn't scale to multiple cores, but I can see how designing around your data can facilitate modern hardware. In fact, is key to doing so. He's talking about a "heretical" mind set, not just "critical areas" or some such malarkey. This is a rethink of much of what the C++ community has swallowed as divine wisdom.
@Youda00008
@Youda00008 4 жыл бұрын
C++ community? Majority of the problems he talks about were invented by Java programmers, C# programmers and JavaScript programmers. C++ authors and comitee members at CppCon regularly argue against abusing any kind paradigm to the extreme, and for keeping things simple.
@RobBCactive
@RobBCactive 2 жыл бұрын
Yet the most parallelisable and fault tolerant systems can use OO techniques like message passing.
@MichaelPohoreski
@MichaelPohoreski 9 жыл бұрын
Indeed. One doesn't fully appreciate just how complicated reality is until they try to simulate it!
@danieldahlkvist1920
@danieldahlkvist1920 9 жыл бұрын
And that's probably why he spent the first part of his talk mentioning similarities toward embedded systems. The consoles mentioned in the talk has specific hardware. You can't upgrade that hardware, you can't plug in more memory you can only use that hardware more efficiently.
@johnappleseed8839
@johnappleseed8839 6 жыл бұрын
Mike Acton. He walked into the lions' den and dominated them all. Legend.
@billmerrill9479
@billmerrill9479 9 жыл бұрын
Curious what optimization settings you were using with VS. I tested myself in VS2012/Win32 and it completely inlined Baz and Bar into the caller as 9 instructions, not unlike the clang result. Disabling optimizations yielded a result more consistent with what you showed in your slide.
@tsonez
@tsonez Жыл бұрын
Every C++ programmer should see this. Maybe also the best general programming talk I've seen.
@fortunaaudacesiuvat
@fortunaaudacesiuvat 9 жыл бұрын
Please put this talk into context. He works in the game industry, which means everything has to be processed and drawn on the screen within at most 33ms (some 16ms). Performance is everything.
@marioc3182
@marioc3182 9 жыл бұрын
THERE'S NO REASON TO BE ANGRY He's the man!!! no one can squeeze the juice out of a processor like he does, he's a mentor to all of us and a cool guy i have the honor to meet btw.
@isodoubIet
@isodoubIet 3 жыл бұрын
I haven't seen anyone who was "angry", but if they were it was because Acton showed up and told everyone a mixture of obvious facts and opinionated nonsense while berating anyone who questions his approach. Ironically, this talk's useful information density was incredibly small: you could easily compress all of the useful bits into a 5/10 minute segment, but we still had to sit through the rest of the talk where the speaker was basically complaining about how stupid everyone is blah blah blah. I mean look, everyone that cares about performance in their software knows that optimizing memory accesses is important. It's not some new revelation. We can get there without the ideological nonsense, thanks.
@gtmacdonald1
@gtmacdonald1 6 жыл бұрын
The similarity with the data-focused list processing you'd find in a functional language is blowing my mind. I wonder if it means that lambda calculus counts as a reality if they both ended up in the same computational model.
@SeelkadoomPL
@SeelkadoomPL 4 жыл бұрын
Can you elaborate? I'm only getting into functional programming now so I don't understand what you wrote, but I do feel like FP would fit with what he says..
@darkfuji196
@darkfuji196 3 жыл бұрын
@sellis "Structures of arrays" is basically storing your data in big functors that you transform instead of small chunks of discontinuous data
@TheLavaBlock
@TheLavaBlock 5 жыл бұрын
Mike (in) Act(i)on! Great Talk. Thanks
@danielhilburn
@danielhilburn 9 жыл бұрын
Keep in mind that he is talking about performance-critical AREAS of code. I guarantee that Insomniac uses plenty of object-oriented or event-based code design where cache consideration isn't a priority. But in any code which transforms LOTS of data at once, these considerations are paramount. Also, these considerations are not optimizations any more than using the right data structure to get O(log(n)) instead of O(n^2) is not optimization. They are simply careful code design.
@quickfiredan
@quickfiredan 9 жыл бұрын
It wouldn't just be a win in power costs, it would allow more general purpose usage of the same physical hardware in the same time slice - that means higher dollar yield per server in a server farm that leases time (e.g. AWS), the ability to process more requests per second with less hardware in the case of transaction processing (i.e. lower ongoing operating costs), etc.
@veromoh
@veromoh 6 жыл бұрын
I'd read a book from this guy.
@StarContract
@StarContract 3 жыл бұрын
@@okaravan objectively the best comment on KZbin
@SE45CX
@SE45CX 6 жыл бұрын
I appreciate you sharing your industry proven wisdom. Great talk.
@Alalilaful
@Alalilaful 6 жыл бұрын
Really interesting talk, much needed when you look at some of the horrors we have invented in "enterprise" software the past 30 years. However, I think the last thing we need is another programming cult replacing the old (OO) one. Yes, everything is data, we know that, but the thing is that the human brain is NOT a CPU. We think in abstractions all the time, that's how we communicate. Any code is just an attempt to abstract away from the true nature of every data : bits. Starting with assembly. We built abstractions because it's impossible for 200 programmers to reason as a team about a modern useful software with just bits. The key takeaway from this talk is that we should think more about the level of abstraction we're in, and the requirements we have. At the end of the day you need to ship it. I have seen a LOT of premature optimization that ended really badly. I also have seen a LOT of insanely bad written code resulting in really slow software. The key is to know where you want to go on the spectrum.
@elliott8175
@elliott8175 3 жыл бұрын
'Completely agree. The talk was really interesting, and makes me want to consider some of my old designs to see if they were causing cache misses. But his emphasis on data-oriented design over abstraction is so obviously impractical for most programs that just need to be built on time /maintained easily rather than have near-perfect performance.
@darkengine5931
@darkengine5931 3 жыл бұрын
Agreed for the most part but have you noticed how a lot of the most performant software (most interactive, most real-time, fastest to load, least bloated, etc) in the industry also tends to be the least buggy and also tends to ship updates in the most timely fashion? It is not always true but it tends to be true in the domains I work in and also the type of software I enjoy using most. Take 3D animation and modeling software for just one example. What's the most efficient? Probably ZBrush. What's the least? Maybe Modo or LW. What is the buggiest? Probably Modo or LW. What's the slowest to ship features that even users who have been screaming for years to have? Same. Meanwhile, the ZB guys, on top of having the most efficient beast engine around, is shipping in a very timely way with minimal bugs. Similar case with like Linux vs. Windows, Unreal Engine vs. Bethesda's Creation Engine... I find similar trends with DAWs, video processors, compositors, image painting applications, IDEs, etc. The most cutting-edge efficient stuff tends to be the least buggy with the smoothest development cycles, while the most bloated and inefficient stuff tends to be the most buggy with trainwreck stories about nightmare development. Of course, I've dealt with those penny-wise and pound-foolish types... so concerned with shaving pennies over the analogical million-dollar transaction that they hardly get anything done. But those types aren't actually the types to produce efficient code. The majority of them are too egotistical or naive to even use a profiler. Yet with the devs who are really skilled at efficiency, and understand how to prioritize properly, like Mike Acton here, or a John Carmack, or a Linus Torvalds... I've never found them the types to be counter-productive at all. They churn out very efficient code in a very timely fashion and tend to ship things very smoothly and quickly.
@RobBCactive
@RobBCactive 2 жыл бұрын
Systems which aren't short lived throw away projects, have to be flexible.
@HELLOWORLD-ix9eg
@HELLOWORLD-ix9eg 2 жыл бұрын
If you are not part of a programming cult, then you are just a heretic like me. Doing weird stuff like OOP in C with composition instead of inheritance. Avoiding callbacks because they make the code hard to read. Avoiding forward declarations because they make it so functions can be ordered arbitrarily rather than by dependency. Lining up all your code so that you can visually see bugs without even understanding the code. (Saving Mental CPU Cycles) Having a strict column limit of 64 characters because your code is designed for vertical monitors because you find it more efficient to seek up and down through code and eliminate 1 axis all together. Adding "Monkey Wrench Macros" where you explicitly disallow certain variable names or explicitly definite a help message when you typed a common mis-spelling. Having prologue and epilogue macros for types so you can work with your c code as if it is namespaced, but not affect other code by using such terse names that might collide with other code. Naming functions based on the data that goes in and the data that goes out , and commenting the function with a user friendly name above the function call. Inventing a problem domain instead of "lego naming" everything. Even though inventing your own problem domain looks really unprofessional because no one knows what a "TAUMAST" is unless they read the documentation and see that it means "TextureAsUniformMasterGpuCpuSyncController" but I have a 64 column limit and terser variables are easier to mentally juggle. Holy fuck I am crazy. But hopefully my #1 rule is something everyone can agree with: The code needs to work. Even if it is horribly written , super hackish, really slow, and really buggy, the 1 one priority is that it needs to work. If you can't get the damn thing to compile, you are still working with a "hypothetical program". If you want to improve your program, you need an actual "real program" that compiles.
@drygordspellweaver8761
@drygordspellweaver8761 2 жыл бұрын
Funny because great programmers have been blowing the trumpet in this one for many decades- over abstractionism
@quickfiredan
@quickfiredan 9 жыл бұрын
Data centers and highly optimised data transformation code for sure, but it is a mode of thinking that certainly has a place in the every day as well. Take the 30 second start-up time - given an estimated 500 million users of MS Word (probably highly conservative), that adds up to about 475 man years for every launch of the app. I imagine it could probably be optimised to ~15 seconds quite easily, saving 235 man years per launch.
@traywor1615
@traywor1615 4 жыл бұрын
48:33 but now ther is no need to store the value anymore, just inline it, right? Or am i wrong?
@learnedseeker1547
@learnedseeker1547 8 жыл бұрын
A great "philosphy" lesson for newer programmers, (me being one), and I suspect, for even some veteran programmers as well. Man coding is some deep stuff. And I couldn't love it more. Great presentation from a game industry professional. Highly recommended.
@MyAce8
@MyAce8 8 жыл бұрын
the only thing I don't like about this stuff is he doesn't make it clear that some of these design philosophies don't apply to their areas of development. I don't think web devs are ever going to have to whip out the dissasembler, abstraction has its place, that place just isn't in game development or platform-specific development.
@MyAce8
@MyAce8 7 жыл бұрын
yeah and there is also asm.js and many other tools for making web apps run faster, but that being said the majority of web developers don't care about resources that much, you are only really talking about a small minority
@qwertyuiop-ke7fs
@qwertyuiop-ke7fs 7 жыл бұрын
this is cppcon, not webdevshit con
@p39483
@p39483 Жыл бұрын
Primary rays cache and secondary rays thrash. This is from ray-tracing but applies to normalized data too. If one array is accessed in memory order, pointers dereferenced out of that array will not be. So... are pointers and foreign keys not allowed? Should sparse data just contain empty space? Wouldn't that be bad for cache too?
@TheBuzzSaw
@TheBuzzSaw 9 жыл бұрын
Fantastic talk. I found myself gravitating toward this design approach over the past couple years. I had no idea it had a name and a wealth of benefits that come from applying it! I still support OOP. I think DOD and OOP can work together wonderfully. The "problem" with OOP isn't OOP; it's the world-modeling aspect. As long as the classes are used to model computer concepts instead of storytelling concepts, everything works out fine.
@EduSodap
@EduSodap Жыл бұрын
What he said is basically the same thing ikea bases their logistics on. Just make your packages flatter so you can fit more into that truck, because unloading the truck is an order of magnitude less time than driving the truck from factory to warehouse.
@ilillillliiilillili
@ilillillliiilillili 9 жыл бұрын
Cache-oriented design
@ulidtko
@ulidtko 9 жыл бұрын
That's the right arguments I was failing to produce. Thumbs up man.
@truecult666
@truecult666 3 жыл бұрын
"Most problems are easy to see." Me eating a sandwich having no idea how he knows the amount cycles a quaternion / vector transform costs: "i see"
@darkengine5931
@darkengine5931 3 жыл бұрын
Typically you don't need that level of fine-grained knowledge to at least get some ability to predict compulsory and non-compulsory cache misses (which are the most expensive part of the equation). It does get nuanced when we get into cache alignment and SIMD vectorization, but it doesn't take so much work to know that loading some ID field in physics loops that are only accessed once every 10,000 frames or so by the GUI is wasting a whole lot of small and precious fast memory.
@bakedbeings
@bakedbeings 2 жыл бұрын
There are some pretty advanced profilers made by intel and nvidia that help you monitor performance of their deeper, more specific instructions and implementations: I wonder if they're using those tools or just writing tests and timing.
@paulc2448
@paulc2448 2 жыл бұрын
Depends how you packed your memory...
@msmeraglia
@msmeraglia 5 жыл бұрын
Man after my own heart. Great talk.
@jmx808
@jmx808 5 жыл бұрын
My awakening to this vectorization of data was in game development when I built an Entity Component System from the ground up. While they too have their flaws, one of the great strengths is the co-locality of like information. You start to think about things in terms of "streams of vector3s" or "streams of structX" as opposed to a more typical "process list of game objects" which then requires opening each of object, performing last minute logic, or worse, process additional hierarchies. This by itself (colocation and process of data) led to a nearly 50% improvement in raw engine performance. Fortunately, it was done early. It's not an easy refactoring project...
@sent4444
@sent4444 Жыл бұрын
Can I read your ECS source code? Thank
@alexc4924
@alexc4924 5 ай бұрын
I don't like ECS any more because it obscures what's important. What's important for performance is S; what's important for flexibility is C. Lumping them together doesn't make a lot of sense. Unity has components but not systems; the stuff Mike's talking about is systems, but not necessarily components. And every game has entities so why even mention them?
@reoire843
@reoire843 6 жыл бұрын
1:17:00 This guy thumbing his nose at the whole point of the talk. Love the speaker's reaction. "People like you are why I have to wait 30 seconds for Word to boot."
@kered13
@kered13 5 жыл бұрын
The guy was right though. Akton's whole speech was from a perspective where memory speed is the primary constraint. For game development that's absolutely correct, but for many other scenarios it's completely wrong. At many companies engineers ARE the primary bottleneck, so code should be written to minimize engineering time (this includes maintenance, not just the initial write). In other areas the primary constraints may be network IO, in which case all the cache optimizations in the world won't do you any good, and instead you need to be looking at minimizing RPCs. I think Akton's speech was very good, but it is delivered from a perspective that all engineers face the same challenges that he does in game development, which is incorrect. It would be better if it were not presented as a one size fits all solution.
@27182818284590452354
@27182818284590452354 5 жыл бұрын
@@kered13 To be fair we have more software companies than we need. If you can't make quality products, don't make them at all. Providing jobs is not a goal of programming, it's quite the opposite actually. Data-oriented design applies to networking just as much. Cache friendliness is just the most common instance, not the only possible concern. You still think about which bits go together most of the time, just in packets and not cache lines.
@RoyBrush
@RoyBrush 5 жыл бұрын
First of all, I like this talk, and it is great in the domain of games, but it isn't universally applicable. As Mike Acton would say, the opinion that we have more software companies than we need lives outside of reality. Businesses exist to make money. If your software is good enough to be less painful for someone than the actual problem they're having, you can sell it to them, and have achieved your goal of making money. The assumption that businesses exist to provide jobs is flawed, because they exist only to make money, and if they stop making money, they stop existing at all. Having high performance is critical to games being enjoyable and sellable (nobody wants to play non-responsive games), but if I'm using a piece of software that saves me a week of manual work, if the software takes any less than a week to run, and there was no better alternative, I'd probably want to use it, even if that solution wasn't optimal. That is, it'd be good enough to get me to pay money for it, because it was good enough to reduce the pain that I was feeling in whatever I was doing. Now, you could argue, well they should have optimized it anyway! But the problem is, that'd cost the company more money, which reduces their profit, and if it doesn't increase sales, it's wasted money and not an optimal solution. Games cost millions of dollars to produce, and often years of time. If you're a business, and you can make the same amount of money faster with no other costs, you're going to do that, or else you're not an optimal business and will most likely eventually fail. To say otherwise is to be just as unreasonable and unrealistic as the "CS Ph.Ds" that Mike complains about in the beginning of the talk. Engineers deal with reality, and financial costs are still costs that you have to consider when designing a solution of any kind, not just performance. As Mike said, if you don't understand the costs of a solution, you also don't understand the whole problem, and can't deliver a good solution that's going to allow you to achieve your goals (which, if you're employed, is to make your business money).
@RoyBrush
@RoyBrush 5 жыл бұрын
​@ I think the point is, if you arrive in the market five years later than your competition, it doesn't matter how good your product is, because your competition will be able to squash you with their massive resources. In fact, the company that started with the minimum viable may even have a more optimal product than you anyway, because they failed fast, they got user feedback, and refined the product into something that more or less fits the domain, and they had more resources at their disposal as they were doing it. And if in the off chance that you spend all that extra time and come out with a truly superior product, the company that got there first can just buy it from you (or worse, try to litigate you into the ground, it's a cruel business practice, but companies do it), and probably still make a much higher return. If you want to call yourself an engineer you have to be pragmatic about the work you're doing. Money isn't the only factor, I absolutely agree with you in that, obviously maintainability of the code, giving yourself room to optimize, trying to follow best practices, is important, otherwise you'll fail later or it'll become exponentially more expensive as time goes on. But right now, pretty much all engineering has a financial component, and factoring costs (be it performance, financial, or otherwise) into your designs is necessary if you want to be a good engineer in my opinion. After all, any first year civil engineering student in the world can design a bridge that will not fall down, but that's not actually the problem. The problem is designing a bridge that your client will actually want to build (i.e one that they can afford), that still will not fall down. The same is true in programming, if you deliver a product that is good, but doesn't work in the market (because it either took too long, is too expensive, or has other prohibitive factors), then you haven't actually solved the problem. And with that said, I enjoy looking at beautiful code, and the goal of designing a system that is as easy to maintain, and has as much room for optimization as possible, is a worthy goal, you just have to balance it with the real world considerations for your particular project or else you're not really doing anything productive. And likewise, you're right, doing the shittiest possible thing with absolutely no thought at all, is also a path to failure. Engineering is full of hard problems and finding the best compromises, which is why we should try to consider all of the factors to try to predict which design will most likely lead to a successful product. Thanks for your comment Michael! I really enjoyed hearing your perspective on this, and it really made me think, so I really appreciate that. :)
@KruK666PL
@KruK666PL 5 жыл бұрын
@@kered13 Programer is not businessman. Programer is craftsman. There is border where programing is ending.
@dascandy
@dascandy 8 жыл бұрын
@JoeNeighbor C99/C11 also allow those, so unless you're programming on a standard that's more than 16 years old you can use it. C++ features only do anything when you use them, and then only if your compiler does not optimize them away. The first one is a design criterium for C++ features to be added - if it adds overhead for non-users it's pretty much no-go - and the second is a major emphasis of compiler optimizations in the past 10 years. Not using it because it may result in overhead is like walking everywhere, because cars may end up in traffic jams and you can't risk the uncertainty.
@PauloConstantino167
@PauloConstantino167 3 жыл бұрын
the fact his slides are hand written is genius and his point is to show the "reality" of things.
@BLOOMS
@BLOOMS 9 жыл бұрын
Avoiding the STL for cache misses, I see. I've never written custom allocators for the STL, but I assume that doing so, won't entirely help with avoiding cache misses? I suppose even if it did, there is enough templates and confusing generics that it wouldn't be worth it for their particular problem.
@User-cv4ee
@User-cv4ee 8 ай бұрын
Does this preclude the flexibility ontained from some design patterns like Visitor, Command, Factory etc.?
@briannoel7398
@briannoel7398 7 ай бұрын
It's easier to add abstractions after you write the code that does the job. If you start with an abstraction, you limit yourself to abstraction.
@timothykerchmar502
@timothykerchmar502 Жыл бұрын
The super genius of taking the time to organize your data around cache lines, is that there really is no premature optimization. With well utilized cache lines, one can use brute force instead of clever algorithms or hand coded assembly. The compiler knows that you have SSE2 on any x64 target, and will be enabled to do all of its SIMD auto-vectorization like a beast on your behalf. SIMD loves packed arrays of a single attribute.
@darkengine5931
@darkengine5931 Жыл бұрын
Even when cleverer algorithms are needed, the most effective algorithms generally need a carefully-designed and efficient memory layout. Multithreading as well. Trying to just haphazardly throw more threads at data whose memory layout is just haphazardly put together will often result in shoddy performance with a lot of false sharing, needless locks, and excessive contention. Even memory alignment is important for effective multithreading (cache line alignment to reduce false sharing) and SIMD (wide register alignment to avoid unaligned loading to registers). Every kind of effective optimization possible, even the most algorithmic, begins with effective organization of the data and careful conception of the access patterns. Ineffective memory representations will make all possible optimization attempts suffer.
@DanielLiljeberg
@DanielLiljeberg 4 жыл бұрын
This kind of thinking is great. The amount of performance you can gain by minimizing cache misses is really big. But as development communities tend to do and flock around some"new cool thing" I think it should be put into perspective. Not all code should/have to be written with this mindset. I would use this approach for a game engine to keep as much performance as possible free for the people then using that engine to code their game logic in. I would use it when writing a database engine, storage engine etc. All of this to not "steal" performance from the developers who then use that database engine etc in their development. But if you for instance write a system that for instance shows a list of electricity meters, can issue commands to remote read them etc your program most of the time does very little and other times mostly wait for data to be sent over IP/M-Bus or some other communication protocol. If someone came to me with a "need" to rewrite this from an object oriented design since they watched a video about data driven design I would scratch my head. But that the values read are stored in a database and you want that operation to be as fast as possible since it could easily become one of the most time consuming parts of the system I totally agree with. Then that is ofc not the same as "ignoring performance" if there is an actual performance problem somewhere.
@neqkk
@neqkk 9 жыл бұрын
those optimisations aren't crazy
@austinmccartney1922
@austinmccartney1922 6 жыл бұрын
"I'm gonna take door b, Bob" I lol'd
@MrM12LRV
@MrM12LRV 5 жыл бұрын
This should be called cache-oriented design (I've seen others with the same idea). One can have classes/structs/objects yet be mindful of their cache. Cache-oriented and object-oriented programming can go hand-in-hand if one is willing to (a) potentially make interface changes and to (b) be clear of data cost (w.r.t. caches) with their abstractions.
@paulward8087
@paulward8087 9 жыл бұрын
Interesting point ... part ofthe reason I also love microsofts take on using the c++ compiler for c# native compilation as of c#6 ... tools that are built for the lazy developer can now help that developer write more efficient code.
@Feral_Pug_Codes
@Feral_Pug_Codes 2 жыл бұрын
Wow, he is just brutally honest about this. Yeah, that's why word takes 30 secs to boot up, I love it!
@oracleoftroy
@oracleoftroy 2 жыл бұрын
Except it didn't when he said it and it still doesn't. In fact, most games take longer to start than Word.
@paulcosta8297
@paulcosta8297 Жыл бұрын
@@oracleoftroy Found the triggered overabstractard. Repent, obey Mike Acton, and read/optimize your compiled assembly daily.
@oracleoftroy
@oracleoftroy 10 ай бұрын
@@paulcosta8297 Huh? So because my programs start nearly instantly and I use OO, I should instead change my style to DOD and have my program require a launcher that connects to the internet, two to six splash screens, and at least a minute wait while it connects to the internet to advertise other games, load gigs of data for the title screen, and a bunch of other junk I don't need before even displaying a usable main menu? No thanks. If that's what game programmers mean by fast start times, I'll take whatever Word is doing, as I can launch it and start writing way faster than it takes to get to the main menu of most games. OO doesn't mean slow if you know what you are doing. A good OO program will follow the long standing mantras like "prefer composition over inheritance" and only use inheritance when there is a real benefit. OO allows one to provide a nice interface over data stored and accessed in a AoS way. Personally, I hold up std::vector as a model OO class, it has exactly as much inheritance it needs to get the job done (zero) while still providing polymorphic abstraction over lists of data, and without needing to introduce undue overhead to do so. Meanwhile, what the hell kind of crap are games doing at startup that it takes minutes to even get to a menu? DoD or simd or any advanced optimization technique shouldn't even be needed to launch a program in nanoseconds.
@Muskar2
@Muskar2 9 ай бұрын
@@oracleoftroy Try booting a more performant game like Factorio and see how it compares to Word. Also, you have it completely backwards. DOD doesn't require tons of 3rd party stuff, that's what OO usually invites. Lots of games don't use DOD, and that's a big part of why they're slow. It's not rocket science, L2 cache misses means you're at least an order of magnitude slower than you could be - and with garbage collection, virtual functions (i.e. vtables) and overgeneralized abstractions you're setting yourself up for tons of L2 cache misses, worse performance and harder maintenance. If that's not obvious, then you're either not getting it, or in very strong denial. You can get away with the bare minimum OO if "you know what you're doing", like you said, but you'll still not be able to compete with an application that is optimized - and maintenance is going to be a lot harder for you, for reasons that are most likely legacy. Regardless, it almost sounds like you're doing DOD, but just a less performance-aware version, so I don't understand why you seem so contrarian about it.
@indianakernick3788
@indianakernick3788 5 жыл бұрын
28:32 "What else can the C++ committee add to the fucking language to make it solve our problems for us". I love this guy! I wish I was there to see the talk live.
@lilmurfer
@lilmurfer 6 жыл бұрын
I see at&t syntax in slides, i see a good man.
@hman2875
@hman2875 5 жыл бұрын
I'm glad I watched this
@LogicEu
@LogicEu 2 жыл бұрын
This talk is absolutely enlightening
@goldLizzzard
@goldLizzzard 2 жыл бұрын
The subtitles seem to stop around the 4 minute mark.
@tomkirbygreen
@tomkirbygreen 2 ай бұрын
Mike rocks!
@FahamNegini
@FahamNegini 7 жыл бұрын
this is gold!!!
@chbrules
@chbrules 4 ай бұрын
Hmmm, looks like C was the best choice all along ;)
@KHouli
@KHouli 8 жыл бұрын
"What else can the C++ community add to fucking language?" 28:40. Just you wait! Calling it now, C++21 has a 2000+ page standard and books are published on effective "postmodern" C++ . ;)
@-taz-
@-taz- 6 жыл бұрын
Mainly because C++03 was called "modern" and they need a new word for 11 beyond, which is practically a new language.
@donrumata5299
@donrumata5299 4 жыл бұрын
It seems to me, that C++21 takes 0 (zero) pages... There is C++20 and C++23...
@jacobschmidt
@jacobschmidt 3 жыл бұрын
1804 lines
@vesk4000
@vesk4000 10 ай бұрын
Does anyone understand the example in 1:07:50? How is looping through the parents and then loopin through their children and dereferencing them faster than just looping through all nodes and checking if the node is a parent? Maybe I didn't quite understand the example. Does it improve cache efficiency or something like that? I thought with branch prediction, stuff like the if statement in a for loop that is rarely evaluated to true isn't really a performance hit.
@DeaThiHD
@DeaThiHD 10 ай бұрын
If the array is sorted depending on the parent presence the yeah the branch prediction will do its work, if it isn't and that the branch predictor keep missing it because the chosen branche keep alternating it'll be even slower
@jjsullivan5196
@jjsullivan5196 6 жыл бұрын
I say this without Mr. Acton's industry experience, but it does seem like there are a lot of helpful language features that add to and don't take away from data oriented design. For example, allocators and concepts can directly avoid the issue of wasted cache space and bad data alignment at compile time, before more time is wasted compiling bad code. However, I do agree with Acton's point where programmers should be aware of these problems, so you can also use these metaprogramming techniques to simply point out to programmers where they need to fix their structs or allocations. I do understand we've come a long way with concepts/allocators/templates in C++ since this talk, but I feel that static analysis is such a useful tool in this context that it shouldn't just be ignored.
@darkengine5931
@darkengine5931 3 жыл бұрын
I could see it aiding, but in practice, and perhaps due to the culture, very often I find a lot of devs using template metaprogramming to avoid committing their designs to any particular data representation (and especially when they reach for policy-based class templates). That unwillingness to commit to any particular data representation, or data structure, or allocation strategy, or algorithm, often yields code that is incredibly inefficient to process for the human programmer, the compiler, the hardware for the resulting binary at runtime, or all of the above. I think concepts should aid a lot in terms of boilerplate, confusing errors, and so forth, but a greater awareness of the importance of data being represented and transformed will probably narrow the usage of generics overall towards more tailored designs that more directly tackle the business requirements of the software and its customers.
@jasonl7651
@jasonl7651 Жыл бұрын
Sure, but data values inside a class are still going to be contiguous. You can pack them and improve data alignment in the class, but if you're still reading each whole object into memory to get one value, that's like "rearranging the deck chairs on the titanic". Just avoid needing to read past the irrelevant data. You have to have packing at a higher level than individual objects to make that happen, no amount of clever struct packing or alignment helps with that.
@sent4444
@sent4444 Жыл бұрын
@@jasonl7651 In chair example, I change a bit. It is like there are set of chair tablecloth candle and spoon, when you arrange it, you grab 1 set of those thing, put the chair down at it position and grab the rest and put pack to storage again just because the table is not there yet and grab the next set. Instant of grab 5 chairs at a time, and once the tables are set, grab 20 tablecloths next.
@josephfatur1747
@josephfatur1747 5 жыл бұрын
Wow. This Acton guy's got it down. Love it.
@MrAbrazildo
@MrAbrazildo 6 жыл бұрын
- If some variable doesn't fit the 1st cache line, will it be split, between 1st and 2nd lines, or will it be pushed down to the 2nd one? - And what about images? You are worryed about bools, when someone can has an entire image in an array, bigger than L3 cache! If the bottleneck is at images handling, how can bools managment help?
@minRef
@minRef 6 жыл бұрын
This followup talk(by a great instructor who was inspired by Mike Acton's talk) can explain most of those questions. 46:01 - 47:40 elaborates on one of the few ways to use a bool in a struct well. The rest of Scott's talk explains your image and bottleneck question, and why the bool issue isn't mainly about information density. kzbin.info/www/bejne/jXWsnKSGaa-Voac
@brothir
@brothir 6 жыл бұрын
1) I think you're a bit confused. You're probably thinking about L1 and L2 cache, not cache lines within L1 or L2. Any variable you can make will ultimately be composed of things that can fit in the register, and it's the job of the cpu to make those be in some line in the L1 as often as possible. If your total data set is too big to be in L1, then most of it will be in L2 and parts of it will be fit into L1, and so on for L3 and L2 and L3 and main memory. 2) Good thinking. bools were just one example, namely that when all you need of a variable is for it to be 0 or 1, it's potentially wasteful to use an entire byte to do what a single bit could do. It's true that when you're operating on a ridiculously huge image, that however you use bools are probably not the bottleneck: it's getting the image from disk to ram to cache to register and all the way back as fast as possible that is the concern. If you know nothing about the image beforehand, there's not much you can do: if you need to process each pixel, then that's just what you have to do. The only real guideline is to not store the pixels in a linked list or binary tree or unordered map or any such nonsense: only a flat array will do.
@darkengine5931
@darkengine5931 3 жыл бұрын
If we're talking image processing, if an image's pixels are accessed in a sequential pattern (usually the common case), and a monochromatic image uses 8-bit bools for that and 8 times more memory per pixel, it can often be about proportionally slower for processing. There are some cases though where a sequence of bools can be faster than a bitset for random access patterns, but very often there's a whole lot of memory waste and multiplied cache misses using bools for things that could be repped as a bitset.
@Denis-db4yp
@Denis-db4yp 3 жыл бұрын
Great presentation.
@MsSomeonenew
@MsSomeonenew 8 жыл бұрын
Well he isn't the friendliest chap but he is completely right, this shit is the reason why a brand new computer with brand new software barely runs anything faster once it all comes together. Easy to write really wasteful code and leave your crap everywhere, the tough part is getting things done with nothing but bare necessities. I will say however that his expectation of everything getting worked out by hand isn't going to improve much, humans just aren't good at juggling large quantities of data nor abstracts. An automated tool that would look over your shoulder and figure out the major waste spots would work out far better.
@patrickproctor3546
@patrickproctor3546 8 жыл бұрын
+MsSomeonenew Take a high performance computing course. It's really not that hard at the levels he discussed in this talk.
@MsSomeonenew
@MsSomeonenew 8 жыл бұрын
+Patrick Proctor But I'm not in charge or working on any major developments, I'm just stuck with major consumer software that runs like ass, doesn't help if I get these courses and very obviously major companies don't care about them either. If there isn't a real push toward performance or a tool to help out this shit will probably not change.
@patrickproctor3546
@patrickproctor3546 8 жыл бұрын
+MsSomeonenew But a lot of it can be done up front, easily. It really doesn't take more time to program it from the beginning, even if it's only on your side. That said, attitudes will change since SISD instructions are already optimized about as far as they can be and since clock speed isn't going to make big jumps anymore. The philosophy of the industry will change.
@manawa3832
@manawa3832 5 жыл бұрын
this shit is the reason you have a brand new computer with a million different applications. the fact programmers have found ways to use abstractions to write more software is whats allowed us to have the highly connected world we take advantage of. oop is the reason this dunce has a word program installed and not notepad 3 or some shit. sorry bud, physical time constraints will always be the obscure practice of game and embedded ship programmers and no one is going to make a popular language for you data driven blah blah blah LOL
@ctm-9191
@ctm-9191 5 жыл бұрын
that's also why a new computer in 2015 got win10 and not dos 4 (because software was able to use abstractions - slower, yes... but so much more productive than 'data')
@tompp2100
@tompp2100 9 жыл бұрын
It will inline into every compilation unit, and then its up to the compiler to remove multiple definitions. Ergo, compile times. However, this not always work in practice. We just had a massive problem where it failed to do so - 50meg binary. Each allocator variant causes another variant to be generated. More bloat. For such a simple thing like a static block of data. EASTL does it better. Its even source compatible.
@tompp2100
@tompp2100 9 жыл бұрын
I would use the char* stream when i want instruction cache coherency, as templated code will be duplicated for every type its used, and will be actually be different code. STL is generally replaced (check EASTL's for explanation why is not preferred for games) - allocators a big reason for this. As he said : ignoring a problem is dogma, not engineering. He said : unnecessary abstractions.
@cyberjunk2002
@cyberjunk2002 Жыл бұрын
After listening to this talk I'm wondering if another good name for this might be "data processing oriented design". When I first heard of data-oriented design I almost skipped it because I thought that's basically what object-oriented programming can already do. But it seems to really be about pivoting your data to make it processed as efficiently as possible for your actual use cases.
@drygordspellweaver8761
@drygordspellweaver8761 Жыл бұрын
No it’s about throwing OOP garbage out the window and just programming in an intelligent manner
@ChaosAndAnarchy
@ChaosAndAnarchy Жыл бұрын
fair
@darkengine5931
@darkengine5931 Жыл бұрын
OOP is fundamentally about treating data not as a part of the fundamental design process, but an implementation detail to abstract and hide away from users of an interface. In data-oriented design, the data is the interface (ex: the components of an entity component system) and the data is the very first thing you think about when designing a new architecture (ex: the data structures involved, the memory layouts, the memory access patterns, etc). That's wholly antithetical to OOP. OOP might have its use cases, but not in performance-critical areas like game engines, path tracers, or operating system kernels because those systems want direct access to data, and OOP's aim is to hide it away via encapsulation and information hiding on top of abstractions and polymorphism. It's not just about computational efficiency though. Acton and others focus on that a lot since they're working with the most demanding real-time needs, but data-oriented design can also be far more productive in some cases resulting in far more decoupled and highly flexible designs suited to adapt to ever-changing design requirements. OOP isn't very flexible at the design level; it works best when your design requirements are fully anticipated upfront but the implementation details aren't and something prone to change or be swapped out on the fly since it generally results in more coupling at the interface level. It provides flexibility at the implementation detail since it decouples implementation details, but not flexibility at the design level. Certain approaches to data-oriented design, like ECS, offer flexibility both ways. Functional programming also tends to be more data-oriented while being extremely flexible against design changes. Linus Torvalds is an example of a data-oriented designer at heart. When he created git, he didn't think about user interfaces, or abstractions, or things like that. He thought about the data structures the program needed to offer the most efficient and distributed version control system. You ask Linus to program anything and that's how he first thinks and tackles the problem is by starting with data structures. Object-oriented programmers start by trying to conceive what objects and abstractions they need before they usually even start thinking about things like data structures and memory layouts, since for them those are implementation details to be solved later, not design details to be worked out upfront.
@oracleoftroy
@oracleoftroy Жыл бұрын
Yeah, totally agree. It doesn't help that most DOD advocates just strawman the way OOP programmers think and cherry pick the worst possible examples of OOP to support their arguments instead of showing the superiority of their approach by competing with the very best of the competition. It's like they can't fathom OO code that doesn't need virtual functions, deep hierarchies, and 20 different base classes. They confuse hiding data from systems that don't care about the details with hiding data from systems that do care. And it's sad how often they confuse "written in C" with "not object oriented" when their goto examples are very object oriented in their approach.
@celinejost2745
@celinejost2745 2 жыл бұрын
Awesome talk!
@CppCon
@CppCon 2 жыл бұрын
Glad you think so!
@andrew.r.lukasik
@andrew.r.lukasik Жыл бұрын
This talk is the best medicine for everyone recovering for OOP overdose. Programming finally makes sense. I watch this at least once a year, therapeutically, just to remind myself that I'm not alone in thinking that this confusion everyone praises as some kind of law, OOP, is a game for fools and confused.
@drygordspellweaver8761
@drygordspellweaver8761 2 жыл бұрын
Love how he just shuts down all the overabstractards like a Bouse
@aameen951
@aameen951 9 жыл бұрын
he mentioned "sandboxing exceptions" for libraries that uses them. Any idea where I can find more about that?
@Spiderboydk
@Spiderboydk Жыл бұрын
It just means wrapping library calls in try catch and convert to error codes.
@austecon6818
@austecon6818 3 ай бұрын
I am totally on board with DOD for anything CPU intensive but for things that are mostly IO bound, I think nice OOP abstractions can be the way to go where the runtime performance cost of even 3 or 4 layers of pointer indirection are neglegible compared to the time spent waiting on IO. I don't see this debate as totally black and white in all cases.
@aliancemd
@aliancemd 8 жыл бұрын
28:30 - That's for me, for later, so I don't have to search for it next time.
@qidex
@qidex 9 ай бұрын
I think there is a disconnect about what to worry about with "the problem" being the hardware. He talks about knowing your specs, but I think his argument suggests it's more about acknowledging that there are specs, and you can optimize to hardware (even generically) as opposed to pretending it's all in the code (as he talks about the code not being the platform).
@shrin210
@shrin210 3 ай бұрын
He is just talking about removing inefficiencies that OOP ideology have given to Programming Languages. Bcoz OOP and Java tried to be one solution for all problems.
@dandymcgee
@dandymcgee 8 жыл бұрын
I love it, especially his answers. Haha, to each their own.
@JCStelu
@JCStelu 5 жыл бұрын
1:23:50 The ultimate question. : )))
@andrewherrera7735
@andrewherrera7735 2 жыл бұрын
I with people like him were involved in making the language. Instead, with c++ people can't use any of the stl or OOP features because they are cripplingly slow.
@BLOOMS
@BLOOMS 9 жыл бұрын
Haha, right. I figured that writing custom allocators would be enough to handle their use cases and constraints. I suppose custom allocators are still not enough to avoid cache misses.
@darkengine5931
@darkengine5931 3 жыл бұрын
They can reduce them by pooling from contiguous blocks if a lot of teeny objects are allocated individually, but that won't help if the user-defined types being allocated still bundle cold data together with hot data. The type system will still interleave that data in memory, even if it's made contiguous, in AoS fashion. Typically the reason games tend to use lots of custom allocators though is for reasons that go beyond cache misses. For just one example, many can't afford page faults with virtual memory and swap disk creeping in the middle of a game (can cause a framerate hiccup that causes players to lose control and die). Some target operating systems that don't even have virtual memory.
@simonfarre4907
@simonfarre4907 2 жыл бұрын
@@darkengine5931 Which is why the polymorphic allocators in C++20 are an amazing step in the right direction, especially for cases like these.
Escape From Spike With Herobrine and Entity
00:27
Garri Creative
Рет қаралды 22 МЛН
Nonomen funny video😂😂😂 #magic
00:29
Nonomen ノノメン
Рет қаралды 45 МЛН
NO NO NO YES! (Fight SANTA CLAUS) #shorts
00:41
PANDA BOI
Рет қаралды 51 МЛН
real magnetic face mask
00:34
승비니 Seungbini
Рет қаралды 49 МЛН
Object Oriented Programming is Good | Prime Reacts
31:30
ThePrimeTime
Рет қаралды 273 М.
Data Oriented Design: Introduction
18:46
GetIntoGameDev
Рет қаралды 8 М.
Premature Optimization
12:39
CodeAesthetic
Рет қаралды 736 М.
Object Oriented Programming is not what you think it is. This is why.
13:36
Escape From Spike With Herobrine and Entity
00:27
Garri Creative
Рет қаралды 22 МЛН