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.
@askeladden4502 жыл бұрын
that is literally me lol. currently watching this for like the 20th time.
@dandymcgee2 жыл бұрын
This is at least my third time watching it.
@amit-mishra2 жыл бұрын
@@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.
@paulcosta82972 жыл бұрын
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.
@sheanmassey2 жыл бұрын
My 3rd trip in 3 years. Hello my fellow DDD crew.
@origamibulldoser1618 Жыл бұрын
Don't mind me. I'm just dropping by to refresh my sanity, once again.
@paulcosta8297Ай бұрын
Bro same
@jearsh3 жыл бұрын
dude literally took pictures of a whiteboard with writing on it to make his slides...my hero
@alcaz0r15 ай бұрын
It's a great way to make his point about our job being to transform data, not to write code. His job as a presenter is to present information, not to futz around with powerpoint. Pics of his hand-drawn diagram got that job done, and probably very efficiently too.
@goranmilovano10 жыл бұрын
@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 :)
@Domarius644 жыл бұрын
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.
@darkengine59314 жыл бұрын
@@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.
@DylanMcNamee3 жыл бұрын
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.
@adude51362 жыл бұрын
@@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.
@kerr12212 жыл бұрын
@@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.
@paulcosta82972 жыл бұрын
Still not over how I C O N I C this monumental Acton masterpiece keynote is.
@gothikia5 жыл бұрын
I'm so glad that someone finally stood up and told that audience in particular exactly what needed to be said.
@TheBuzzSaw6 жыл бұрын
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.
@lalirose6 жыл бұрын
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
@Mike-gs7eo6 жыл бұрын
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.
@andrewherrera77353 жыл бұрын
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
@drygordspellweaver87612 жыл бұрын
Not all of us, Andrew.
@Muskar2 Жыл бұрын
@@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.
@DaveHoskinsCG7 жыл бұрын
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 Жыл бұрын
If you have to support this code for the rest of your life, then perspectives change drastically.
@alang.2054 Жыл бұрын
@@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 Жыл бұрын
@@llothar68 Yeah, game code is sort of a special case because most of it gets thrown out after the project is done
@CyberDork34 Жыл бұрын
@@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 Жыл бұрын
@@alang.2054 That's not good code. Code that is designed with the hardware in mind does not necessitate being hard to debug.
@BobRaygen Жыл бұрын
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.
@yueyu976225 күн бұрын
I guess in the business world it’s more important to find ways to get more revenue instead of finding ways to reduce costs, unless the cost is too high or there’s a limitation of the hardware (game consoles)
@Domarius644 жыл бұрын
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 :)
@Sychonut6 жыл бұрын
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_mumbo14415 жыл бұрын
How do you get better at that kind of programming?
@BlackJar725 жыл бұрын
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.
@32gigs965 жыл бұрын
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.
@32gigs965 жыл бұрын
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.
@atilafernandes2175 жыл бұрын
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.
@bruterasta6 жыл бұрын
Well, Mike is now prinicpal engineer of Unity engine.
@atilafernandes2175 жыл бұрын
So, he is the one to blame for the change from C++ to C#?
@Billy1Famous5 жыл бұрын
Á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.
@clodgozon39684 жыл бұрын
The engine is built with C++
@Domarius644 жыл бұрын
@@Billy1Famous This makes so much sense. A lot of the benefits of DOTS is reflected in this talk.
@DanielKierkegaardAndersen3 жыл бұрын
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! ;)
@FreeLancerdu293 жыл бұрын
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 Жыл бұрын
Also watched it in 2014, it is now the most viewed cppcon talk.
@XeenimChoorch-nx8wx4 ай бұрын
Glad the masses are waking up from OOP nightmare
@todorsamardzhiev14421 күн бұрын
It deserves 0.5 billion views. At least. It should be a required reading for all practicing programmers.
@phisyka6 жыл бұрын
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.
@todorsamardzhiev14421 күн бұрын
Bruh, this talk is just keeps on giving. I watch it every year, and every time I find a new thing that I love about it. In 2024, with all the political madness going on, I just love how Mike manages to remain factual and respectful with people who completely disagree with him. We need more of that.
@vsabadazh7 жыл бұрын
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!
@Pixeldev99910 жыл бұрын
One of the best C++ talk I've ever watched. Kudos to Mike!
@tsonez2 жыл бұрын
Every C++ programmer should see this. Maybe also the best general programming talk I've seen.
@tokyospliff2 ай бұрын
Now it's very important to watch this once when you wake up and once again before you fall asleep
@wearecomingback57078 жыл бұрын
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!!
@tathtath8 жыл бұрын
+We are coming back c is closest to assembly and for me - my favorite programming language :)
@MyAce88 жыл бұрын
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.
@JackMott8 жыл бұрын
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.
@EnduranceT8 жыл бұрын
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.
@wearecomingback57078 жыл бұрын
EnduranceT haha.. 10 foot pole.... hilarious
@PeterAndLeelien10 жыл бұрын
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.
@eduantech6 ай бұрын
The argument is that the whole "dev time" argument is not quantified or real.
@wjrasmussen6666 ай бұрын
@@eduantech how many players playing that game, that many times, with that many iterations over some poorly performing code? Dev time for that one issue is small compared to that of player experience.
@XeenimChoorch-nx8wx4 ай бұрын
Dev time is saved by using data oriented design.
@KManAbout2 ай бұрын
@@wjrasmussen666 if the game never gets made no players will be playing it. So the expected value drops. Dev time is obviously a thing it's just harder to quantify. Don't be stupid.
@todorsamardzhiev14421 күн бұрын
Both you and the 1:16:20 dude are making a claim that using data-oriented design would decrease developer productivity. The problem is that you cannot prove that, and that Insomniac Games (Acton's company at the time) had consistently managed to ship multiple AAA games every year, without delays and without any major zero-day issues.
@colinferguson6478 жыл бұрын
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.
@BalanNarcis6 жыл бұрын
Everything is bare metal stuff, people just don't want to think about it, lazy people, shitty software.
@stevesan5 жыл бұрын
@@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.
@darkengine59314 жыл бұрын
@@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.
@morpheus74223 жыл бұрын
@@darkengine5931 200k? Holy moly, who's going to fix that?.
@NerologicalGamesOfficial4 ай бұрын
I really love the world of programming. Not many egos, willingness to share information and help, striving to improve. I think the best of humanity can be found in the world of programming.
@ambientswn3 ай бұрын
@@NerologicalGamesOfficial join any Rust programming language community to challenge your views
@InsidiousRat2 ай бұрын
@@NerologicalGamesOfficial never thought of programming community that way. But it's true
@versatran012 жыл бұрын
Come back rewatching this every year
@odraencoded9 жыл бұрын
A good portion of this talk applies to general programming and not just ot low/mid-level C++.
@aliancemd8 жыл бұрын
+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).
@nameguy1018 жыл бұрын
+Lilian That's because strictly object-oriented languages are shit.
@tomgillen49828 жыл бұрын
+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.
@MyAce88 жыл бұрын
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)
@MyAce88 жыл бұрын
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++
@marioc318210 жыл бұрын
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.
@isodoubIet4 жыл бұрын
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.
@meltygear5955 Жыл бұрын
You know a talk is a banger when the youtube "most played" analysis resembles that of a mountain range.
@quickfiredan10 жыл бұрын
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.
@Bakuta11035 жыл бұрын
easily my favorite cppcon talk ever
@charlesd45728 жыл бұрын
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.
@MordachaiWolf10 жыл бұрын
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.
@Youda000084 жыл бұрын
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.
@RobBCactive3 жыл бұрын
Yet the most parallelisable and fault tolerant systems can use OO techniques like message passing.
@danieldahlkvist192010 жыл бұрын
If what you saw interests you I can recommend reading up on "structures of arrays vs arrays of structures"
@andrew.r.lukasik2 жыл бұрын
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.
@XeenimChoorch-nx8wx4 ай бұрын
So far every 6 months myself :)
@quickfiredan10 жыл бұрын
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.
@JordanHolcombe8 жыл бұрын
lol... multiple inheritance "that's just dumb". enjoying this video :)
@johnappleseed88396 жыл бұрын
Mike Acton. He walked into the lions' den and dominated them all. Legend.
@timothykerchmar5022 жыл бұрын
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 Жыл бұрын
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.
@paulcosta82972 жыл бұрын
Perhaps the single greatest video ever on all KZbin. So unbelievably good. Mike Acton is so correct and all the people who extremely disagree with him are extremely wrong.
@danieldahlkvist192010 жыл бұрын
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.
@MichaelPohoreski10 жыл бұрын
Indeed. One doesn't fully appreciate just how complicated reality is until they try to simulate it!
@notmynormalusername17 жыл бұрын
"but we aren't performance constrained, we're engineering time constrained!" This is why we can't have nice things.
@manawa38325 жыл бұрын
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.
@pavelsmejkal71875 жыл бұрын
I thought a similar thing. And Mike replied nicely - that's why my Word takes 30 sec to boot...
@jack-d2e6i5 жыл бұрын
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.
@notmynormalusername14 жыл бұрын
@@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.
@isodoubIet4 жыл бұрын
@@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.
@jmx8086 жыл бұрын
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...
@sent44442 жыл бұрын
Can I read your ECS source code? Thank
@thewhitefalcon8539 Жыл бұрын
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?
@PauloConstantino1673 жыл бұрын
the fact his slides are hand written is genius and his point is to show the "reality" of things.
@Feral_Pug_Codes3 жыл бұрын
Wow, he is just brutally honest about this. Yeah, that's why word takes 30 secs to boot up, I love it!
@oracleoftroy2 жыл бұрын
Except it didn't when he said it and it still doesn't. In fact, most games take longer to start than Word.
@paulcosta82972 жыл бұрын
@@oracleoftroy Found the triggered overabstractard. Repent, obey Mike Acton, and read/optimize your compiled assembly daily.
@oracleoftroy Жыл бұрын
@@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 Жыл бұрын
@@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.
@JesperBylund3 ай бұрын
This talk has made me significantly smarter. Thank you Mike!
@pyajudeme92459 күн бұрын
One of the best videos about programming ever.
@pondlife99317 жыл бұрын
No bullshit. No affectation. Pure GOLD. I would love to work for this guy.
@needlessoptions7 жыл бұрын
I love him but I find him slightly intimidating he isn't particularly friendly lol
@danielhilburn10 жыл бұрын
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.
@gibgezr9 жыл бұрын
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.
@arunabraham93826 жыл бұрын
gibgezr Have you checked D language? Fast language like C but efficient in productivity.
@Qizot6 жыл бұрын
and probably will never be used with large projects
@drygordspellweaver87612 жыл бұрын
I page out to an SSD thank you very much!
@jylpahАй бұрын
His view is although very specific view of performance focused programming close to hardware. Most of software on earth is not software trying to squeeze maximum out of the hardware given. Very interesting presentation in any case!
@yueyu976225 күн бұрын
This. With different priorities, some problems viewed as different problems by him can perfectly be one single problem for others. Different tools for different jobs.
@yueyu976225 күн бұрын
Nevertheless It’s nice to have the principles and rules as the hammer when we have that particular type of nails.
@gtmacdonald16 жыл бұрын
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.
@darkfuji1964 жыл бұрын
@sellis "Structures of arrays" is basically storing your data in big functors that you transform instead of small chunks of discontinuous data
@Alalilaful6 жыл бұрын
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.
@elliott81754 жыл бұрын
'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.
@darkengine59314 жыл бұрын
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.
@RobBCactive3 жыл бұрын
Systems which aren't short lived throw away projects, have to be flexible.
@HELLOWORLD-ix9eg2 жыл бұрын
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.
@drygordspellweaver87612 жыл бұрын
Funny because great programmers have been blowing the trumpet in this one for many decades- over abstractionism
@Nyocurio9 жыл бұрын
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.
@Dkoooz6 жыл бұрын
I'm sure he uses templates
@aliancemd6 жыл бұрын
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"...
@asdfghyter6 жыл бұрын
No, he explicitly said that there was a soft-ban on templates. However, he does use other code generation tools.
@billmerrill947910 жыл бұрын
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.
@MsSomeonenew8 жыл бұрын
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.
@MsSomeonenew8 жыл бұрын
+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.
@manawa38326 жыл бұрын
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-91915 жыл бұрын
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')
@darkengine59314 жыл бұрын
@@MsSomeonenew We have profilers that do a wonderful job of pinpointing hotspots and the causes behind them although optimization tends to still be quite a manual process. One of the unfortunate things about a language like C or C++ (which inherited C's legacy), if we want to try to minimize the requirement for human expertise over the hardware, is that structure member alignment is not something the compiler is allowed to rearrange to maintain ABI. But even if we had some hypothetical language, and extremely aggressive optimizing compilers for it, that could rearrange not only instructions but entire data representations in memory for optimal memory access patterns, it still doesn't know how users are going to end up using the software. That's one of the huge knowledge gaps between compiler and human that still requires tremendous expertise on the part of the human, and it's not something even close to being solved with profile-guided optimization. Even the most hypothetically aggressive optimizer doesn't know what users are going to commonly do, so it can't tell the difference between common-case execution paths and rare cases so well when the branches taken depend on user inputs fed at runtime. It's not a mind reader as Mike pointed out in the lecture, and we actually need something close to a mind reader to fully automate away this human effort while still producing very optimal code for the hardware.
@DanielLiljeberg5 жыл бұрын
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.
@scalbylasusjim27802 ай бұрын
0:00 introducing the introducer feels very on brand for a cpp conference.
@madpuppet66610 жыл бұрын
Just as a test, I opened up word on a document after watching this. I haven't used it yet today. It opened and was ready to type in about 1/3rd of a second. I suspect the devs haven't just switched to a data oriented pipeline to achieve this - more like its a combination of SSD harddrive plus Word not loading features it doesn't need at boot, plus generally computers get faster and the need for hard-core optimisations to provide good user feedback lessen.
@henrikoldcorn2 ай бұрын
Ironically it’s the same idea that might have solved the issue - find what’s slow, make it not do that. If Word starting requires reading an exe plus seven different configuration files and maybe your document too, it’s gonna be slow on an HDD. A fix might be one big config file that all gets read into memory at once. Move to an SSD and suddenly that’s completely a non-issue. If it does a licence check while starting and connects to the Internet then hey, the old problems are back again!
@veromoh7 жыл бұрын
I'd read a book from this guy.
@StarContract4 жыл бұрын
@@okaravan objectively the best comment on KZbin
@EduSodap2 жыл бұрын
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.
@tomkirbygreen5 ай бұрын
Maximum respect Mike!
@SE45CX6 жыл бұрын
I appreciate you sharing your industry proven wisdom. Great talk.
@truecult6664 жыл бұрын
"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"
@darkengine59314 жыл бұрын
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.
@bakedbeings3 жыл бұрын
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.
@paulc24483 жыл бұрын
Depends how you packed your memory...
@MrM12LRV5 жыл бұрын
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.
@quickfiredan10 жыл бұрын
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.
@AC-cv5zz5 жыл бұрын
Skip to 1:01:30 if you don't need an hour (and one minute and thirty seconds) of explanation as to why DOD, but just want to start learning how... ... You're welcome.
@notapplicable72924 ай бұрын
I come back to this talk every now and then to remind myself how terrible I am in the scheme of all programmers
@thewiedzmin60625 жыл бұрын
Finally someone who doesn't talk painfully slow!
@fortunaaudacesiuvat10 жыл бұрын
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.
@XeenimChoorch-nx8wx4 ай бұрын
He literally says this. Not only that- he then goes in to say that performance matter across the spectrum and not just in games.
@alexkhazov72644 жыл бұрын
Would love to see this talk in 2020 with modern C++
@JanusTroelsenАй бұрын
Nothing changes for him, he doesn't use STL or anything fancy. From the talk it looks like he'd be happy with C with Classes.
@LogicEu3 жыл бұрын
This talk is absolutely enlightening
@TheLavaBlock6 жыл бұрын
Mike (in) Act(i)on! Great Talk. Thanks
@reoire8436 жыл бұрын
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."
@kered136 жыл бұрын
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.
@271828182845904523546 жыл бұрын
@@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.
@RoyBrush6 жыл бұрын
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).
@RoyBrush6 жыл бұрын
@ 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. :)
@mehowop6 жыл бұрын
@@kered13 Programer is not businessman. Programer is craftsman. There is border where programing is ending.
@tomkirbygreen9 ай бұрын
Mike rocks!
@indianakernick37885 жыл бұрын
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.
@dascandy9 жыл бұрын
@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.
@Optimus61288 жыл бұрын
This talks amuses me (even if a long time is spent in theoritical stances that gets boring) because I am also a low level programmer most of the times and I like to code graphics algorithms and focus on the algorithm and optimization ideas rather than OOP. I like thinking out of the box rather than "use this design pattern because it's always the best". And I do wonder why some apps and the web are so slow sometimes. But I do agree, a lot of his talk feels like "this is the right way" without much explaining, while I would guess most applications wouldn't need always that kind of solution. I don't know about web, web is a big mess in itself, so many ad-hoc solutions upon code upon code, and it has to run EVERYWHERE. But take for example even a game idea, if I made a game with 100 sprites maximum, would it matter if my gameObject class would have 20 member variables, bools and other stuff? It would be minimal and my game would still run well above 60fps even in older computers (other things like the rendering will matter more). But what if I want to make a game or graphics demo with one million moving particles, where I guess the math will play a role, but also a datastructure with too many member variables could affect a lot? So,. it's a matter of what you want to achieve. I am never crazy for inheritance and templates and all that personally, most of the times because I code graphics algorithms and I want to focus in algorithms rather than code design, also I believe in the KISS (keep it simple stupid) principle, I will not overengineer. In rare cases, maybe I'll need some C++ concepts. But the tight places in the code where a lot of things per frame are happening will be more like C, while some essential stuff outside will use C++ concepts only if necessary. And the other thing is his QA. I was surprised actually. In most answer he seems to be avoiding things like the very simple "But if you advocate avoiding all these concepts, then why use C++ in the first place?". Sometimes, it seemed like he was puzzled, couldn't answer about the good things of C++ from C, which is surprising since he is a lead. I do suspect this guy started as an assembly programmer, moved into C and other things, he likes coding and optimizing algorithms and not thinking about abstract programming, but because he has a job in gaming industry people use C++ so he has to adapt, but most of the time still write C. I was puzzled, because some of the questions are legit, and I was expecting better answers. And because as a lead in his field, even if you code more C oriented code, you'd have C++ programmers around you discussing the concepts.
@suruzuddin5 жыл бұрын
"this is the right way" attitude seems to me same prescription for every disease ;p
@mycollegeshirt5 жыл бұрын
I don't necessarily think it's "this is the right way", as much as using templates and blanket design patterns etc is the wrong way, or more charitably a bland way.. they make it significantly harder to optimize, its a response to some of the ideas that were engendered by the C++ community, that when we test, we just see the ideas in this code oriented whatever works well in isolation, and examples, but leads to a tendency to overgeneralize and fantastic waste of resources in the real world, think any Adobe product, Microsoft product. The entire takeaway is that there isn't a right way, which he actually even says. It's about realizing we program computers, and we need to understand what are the constraints of the machine, to organize and manage our data in the most efficient manner. In other words his examples if he were programming on a snes would be entirely different. But if he bought into the C++ stuff it would be exactly the same algorithms. But to him and me included feel that's absolutely insane because aligning for the cache is no longer your concern since memory reads were faster than CPU clock cycles, some other concern would take precedent. it's literally the same old thing whats faster insertion sort vs quicksort. the general answer is hardly ever the answer you want, it depends on the data and how you're using it.. it's really nothing new.
@Optimus61288 ай бұрын
Reading my answers years after, after watching the talk again, it feels weird. I don't disagree but wonder if I was a bit harsh at that guy. Hehe,.. now I liked the talk more, especially when he says "if you talk about premature optimization, please get out of the room"! I am kinda annoyed by that crap and all the "common wisdom" around programming culture today. It still makes sense though to take all these ideas as things to think about not as recipes you have to follow blindly. Maybe my example of 100 sprites wouldn't scale up today, there could be lot's of loss on places I don't know and haven't considered second time I watch this talk. I've optimized around software rendering algorithms where they are brute force algorithms for lot's of pixels, but didn't even reason much about my structs or some if statements. So, there are things to rethink, never take things in programming as mantra just as suggestions or reconsiderations.
@RigelOrionBetaАй бұрын
It seems C++ is not his preferred language, but just the one that game engines use nowadays. He is stuck with it because of the industry, not through choice. Seems to me he is basically a C++ coder who only codes with C features.
@cc.jsullivan6 жыл бұрын
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.
@darkengine59314 жыл бұрын
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.
@jasonl76512 жыл бұрын
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.
@sent44442 жыл бұрын
@@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.
@Davidicus0005 жыл бұрын
This was a paradigm shift for me, wow. I learned a lot about why OOP is over as the primary methodology, Data Driven is compelling.
@Tony-dp1rl Жыл бұрын
There is something almost ironic about recognizing that OOP is fundamentally a bad-performing pattern , and then trying to switch back to how we did things in C for decades ... in a CPP talk. :)
@thewhitefalcon8539 Жыл бұрын
CPP isn't an OOP language - it's a kitchen sink language. It just happens to include OOP as one of many tools. But not pure OOP, but the bastardized version that meshes well with C.
@cgikoray10 жыл бұрын
Hilarious and informative. Thanks for being awesome Mike Acton :) I learned something today.
@vertigo69826 жыл бұрын
The Q and A is exactly why C++ and even in general the programming community is crazy like it is. You got all these different people using the same tool in different ways.. improperly, but since it got the job done for them.. multiple times they think their way is the correct way.. and the best one at that. To top it off.. the kind of people that seem to make up many of our programmers are snotty, obnoxious, and ignorant human beings who need to learn how to be humble... only then will they truly learn their craft properly. I know this talk is old.. but it goes to show you how unorganized things were/are in the community, and that theres much more for them to all learn. Problem with Knowi-it-alls.. they think they know everything already and therefore dont think thers anything else new to learn even when its staring them right in the face. I imagine this is where the saying "you cant teach an old dog new tricks" came from. The other problem is the tricks arent new.. they've always been the right "way" and just were never taught to everyone.
@isodoubIet4 жыл бұрын
The problem with your comment is that it applies to the speaker just as well as it does the questioners.
@lilmurfer7 жыл бұрын
I see at&t syntax in slides, i see a good man.
@ulidtko10 жыл бұрын
That's the right arguments I was failing to produce. Thumbs up man.
@drygordspellweaver87612 жыл бұрын
Love how he just shuts down all the overabstractards like a Bouse
@KHouli9 жыл бұрын
"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-7 жыл бұрын
Mainly because C++03 was called "modern" and they need a new word for 11 beyond, which is practically a new language.
@donrumata52994 жыл бұрын
It seems to me, that C++21 takes 0 (zero) pages... There is C++20 and C++23...
@jacobschmidt3 жыл бұрын
1804 lines
@jessicahansen12883 ай бұрын
This is such a great talk.
@neqkk10 жыл бұрын
those optimisations aren't crazy
@EnduranceT8 жыл бұрын
Dude he pwns noobs during the Q&A. I feel like the "Q&A" is like the 10 guys who all feel the need to express how they got butthurt about what he said, lol.
@MrAbrazildo7 жыл бұрын
Not all that noob. 1 said that embedded systems don't care so much about performance - and I add: they worry about size. The other ask "why not stay with C(99)?", which is interesting in the context.
@manawa38326 жыл бұрын
not really he basically deflected all the criticisms and resorted to sloganeering "data is the problem!" lol data is most certainly not the problem. it is in fact, a representation. sorry. talk's over everyone can go home
@dvlduvall5 жыл бұрын
If everyone could pay attention to this - we could all fight global warming. I can imagine datacenters running with half capacity.
@detectivemarkseven3 жыл бұрын
Low-level performance Nuts are doing the same same thing he said. Its the higher-level lunkheads is what this talk is for.
@RigelOrionBetaАй бұрын
Even if data centers ran at half capacity, it would not be long before we found things to compute that would cause it to double again.
@ilillillliiilillili10 жыл бұрын
Cache-oriented design
@DxXNA10 ай бұрын
Its amazing how a video like this can exist.. yet we still require people to do garbage Object Oriented programming.
@toby99995 ай бұрын
There is s plsce for OOP, just as there is a place for screwdrivers and hammers. Different tools for different jobs. The mistake is in being a purist... all hammers or all screwdrivers.
@da-gi7ds2 ай бұрын
@@toby9999 There is no hammer or a screwdriver. I believe Mike bemoaned such silly analogies in this talk. The physical purpose of my computer or any computer I target is to transform data, whether it is Data-Orientated Design or Object-Orientated Programming; the physical purpose of hammers and screwdrivers are different, nails and screws. There is no relation between screws and nails, and electronic computer parts.
@austinmccartney19227 жыл бұрын
"I'm gonna take door b, Bob" I lol'd
@airbus5717 Жыл бұрын
this talk is so underrated
@traywor4 жыл бұрын
48:33 but now ther is no need to store the value anymore, just inline it, right? Or am i wrong?
@IndividualFreedomNet9 жыл бұрын
You have to take into account his specific job and what that unit does. Most likely they are a couple of guys who do this kind of programming style, day in day out for numerous years and you can assume that they know the code at heart. And they for sure find it very readable, since their mindset is around data paths, not code. Having said that, I fully agree with you that using some of the better C++ abstraction possibilities can yield far more readable code with no performance loss.
@paulcosta8297Ай бұрын
One more month until The Three Year Anniversary Of My Discovering Master Mike Acton's Legendary And Life Changing 2024 CppCon Talk 🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏🙏
@paulcosta8297Ай бұрын
"TTMAMRBIDT375.5kb": Thanks To Mike Acton My Release Binary Is Down To 375.5kb 🎉🙌 (from 18mb in May, 138kb with UPX level 9) Mike Acton happy face: 😊
@paulcosta8297Ай бұрын
Pascal developer here. Used Delphi's RTL all my life. Post-Acton? CRAP. 😱 Get that BLOATED CRAP away from me. It literally heap allocates an object every Fing HTTP request. "BuT it's CrOsS PlAtFoRm" 🤮🤮 TObject.Create? 🤮 Using VCL? 🤮 Life after ditching entire Delphi RTL for raw Pascal custom Win32 API wrapper libraries, zero use of exception, zero objects/polymorphism, MUTILATING and recompiling custom System.pas, and switching to GPU-rendered ImGui: *🎉🎉🎉🎉*
@paulcosta8297Ай бұрын
"bUt MuH MaInTaInAbIlItY and DeVeLoPeR pRoDuCtIvItY"🤡🤮🤡🤮
@theinsekt10 жыл бұрын
The person at 1:16:18 made a good point. In many areas you don't have to worry much about cache misses becuase the performance is good enough.