Great talk! Always stoked to see a Mike Acton Talk. As an aside: whoever was controlling the camera needs to be fired. Stop rotating to the audience, I want to see the slides. 42:00
I agree, but thankfully the camera was able to stop just in time to pause the video and write down the slide. Value * Identify specific concrete measurable value * Make the business case * Its not about being a suit its about not being irrational with your own valuable resources (your time * There are more things that you can possibly do
Wrong... This guy knew and perfected what he learned in university to the point he can break the rules without break the truth.
Місяць тому+1
Remember that Acton is a very confrontational speaker 😅. Also he's talking about quite specific field. I'm not saying he's wrong and I have learned a lot from his talks when I was at the beginning of my career. I'm just saying that don't leave from this video thinking you should be an expert on all of this immediately. That being said, in my experience CS education is often quite lacking :(
notes: The skill is inferring purpose and constraints in code. Assume next people reading the codebase are smart, give them hints. They aren't idiots. Shared resources tend to be bottlenecked, like memory. Design around it, don't abstract it. Know your tools, like compilers. Like a painter knows his brushes very well. What does it output? Can I change its output? YOU'RE RESPONSIBLE FOR THE OUTPUT OF THE TOOL. If you can't predict it, it gets in your way. When performance is a problem it's too late to fix it. Performance as you go. Everything is a data problem. Programs just transform data. If you don't understand the data (limits, how many, range, how likely to x, grouped), you don't understand the problem, and your solution will be wrong. Sought skills: Understanding how OS works, read/write assembly fluently, experience with SIMD, how memory buses work. People lack practice, reasonable defaults and problem solving. Gather CONTEXT, VALUE, COST, PLATFORM, DATA of the problem
I believe, 'scratch' here means what is sometimes called an 'Arena'. The difference is that Arenas/scratch allocators can't free sub-sections of the memory they allocate, they have to release it all at once. Stack allocators can free sub-sections of the memory they allocate, they just have to do it in a restricted way
@@tedrivera8051 I think you're confusing 'the stack', with a stack allocator. Stack allocators can allocate/deallocate heap memory - that's actually the more common case. You're thinking of the allocations the compiler manages for you.
This vid should have more views. Yup sometimes you just gotta copy the class or whatever (not code and paste literally) and hack away. And revert if you mess up. It's easy to get lost in model land. There's a place for it though.
I don't get the piece about practice. Do does he mean that manager should leave some of developer's time for practice? Or that the developers shouldn't have any responsibilities outside of work? In most professions you practice as you work, you don't get the time to do "ephemeral" practice every day
The 'when' of practice is not something he addresses, so to your first question: maybe. The idea that you don't get the time to practice is essentially bs. You can fit it in 30 minutes, as he says, and you can find 30 minutes. If you think you can't, you probably just aren't valuing the practice (Obviously, there *are* things that you would make 30 minutes for if they were sufficiently valuable to you), which is part of the point - he thinks developers undervalue practice.
he answers that in another talk: "handmade con 2015", and to answer your question, what he means, is outside of your work hours. And he disagrees about the fact you "can not have 30 minutes a day to do something for your chosen career".
I think he is talking about what kind of people he wants to work with in general. Since he is the best he wants to work with the best. And who would most likely be a better engine developer: someone who practices and learns new things about engine development outside work because they love it, want to be the best, etc... or someone who does not? Check out this video: "Jonathan Blow on work-life balance and working hard"
World would be a much nicer place if "Write as if the next programmer working with your code was a violent psychopath who knew where you lived" was a generally agreed-upon rule.
Not necessarily. Making your software idiot-proof always introduces constraints that will haunt you further down the road. Case in point: OOP's impact on cache-coherency.
@@HonsHonIf you group them together in a container (AoS) on the stack, you can still think them separately, besides their memory will stand glued together. If they don't need to be sorted, it's fast to remove in the middle, by moving the last 1 to there. Sometimes this formation beats a hash table on L1 cache. And if needs to make a SoA out of it, for optimization, if a common syntax for communicating to the outside was kept, this reform can be made safely, without worrying about breaking the rest of the project. I don't think this is a mess at all.
1:30, does that mean $$ or once again another exploitation of our good will? 4:16, Single Responsibility principle stands for untangling things, to has things uncoupled. But if 2 things always should stay together, they can (and should) be interpreted as a single piece of software. People seem to not understand that, or taking it as a contradiction. And once those 2 things became separated, an unnecessary dangerous managing task arises! 1 now has to track both of them in a synchronized way, like a juggler! 8:00, true, reality is more important. But there are near zero-cost abstractions, and situations where they can exist. Nobody should miss those moments. 8:58, and the good news about memory (for higher-level programmers) is that it's not an intricated system, that he gonna has to reinvent complex solutions for each new project. Most programming machines have about the same kind of memory levels, so you gonna reuse what you had once build, several times. Of course, depending on the project, internet itself may be the bottleneck. So, this wall advice may be useful for some specific people. 9:56, I guess what it's trying to say is that novices should not worry about "compiler complaining too much against me". Later they will learn that compile error is a relief. Senior programmers make tools to force compile errors instead. I use to go even further: when I use some good practice, like const correctness, and I foresee that it'll fail to compile, even so I compile it, if I have a bit of doubt about its possibility of failure. This "looses time", but keep my mindset focused on a mechanic behaviour of "coding together with the compiler".
I think your point about single-responsibility is a tautology. Things that should be together should be together, and things that shouldn't be together shouldn't? This is not something worthy of chapters in software programming books, in my opinion.
@@churchianity If 2 or more things should only work together, they should not be separated, just to the sake of "decoupling". Separate them should only make sense if a) Part of them can work independently in other parts of the code; or b) Part of them make together another entire strong concept.
10:32, linked lists by default, interfaces are examples of data structures that put too many code. Part of that may be "glued" on communication with other stuff. So it's better not use them, at least not as default. I already wrote code in the past that, by turning the optimizing flag on, resulted on the same speed! 18:04, for games this means: write your game right away, not a generic engine to later make the game. The generic code arising from it you can separate from the rest, making a lib. On the same vibe, simple/cheated mathematics use to be better, faster and easier to code, than a complete equation for the task. For games and AI, imprecise or even truncated floating point values are often enough. 35:39, right, you can't get rid of the variables just by making an abstraction. But having them on a class can most of the time separate the low-level, complex or anti-intuitive actions from zero-cost nice interactions to other users that didn't make that class - _including the class creator, once he forgot those details_ . That's not equally achievable with f()s, because either the user will has to pass those variables explicitly or has them as global - and both are bad. 39:51, there's a tenuous line here. Abstraction can't stay on the way, can't be the goal, but rather the tool instead. I think the engineer should always verify if the story telling can go without damage. If it's possible, it's a big win. Even if it can appear in parts, told in a mechanic, truncated way, it's already a victory.
This applies to all software engineering, not just game engines.
Great talk! Always stoked to see a Mike Acton Talk.
As an aside: whoever was controlling the camera needs to be fired. Stop rotating to the audience, I want to see the slides. 42:00
I agree, but thankfully the camera was able to stop just in time to pause the video and write down the slide.
Value
* Identify specific concrete measurable value
* Make the business case
* Its not about being a suit its about not being irrational with your own valuable resources (your time
* There are more things that you can possibly do
he lost so much weight from ~2014. I'm happy for him!
This makes me think that my university CS education has it all wrong…
It does. And so did mine.
The good news is now you know and you can make changes to account for that
Wrong...
This guy knew and perfected what he learned in university to the point he can break the rules without break the truth.
Remember that Acton is a very confrontational speaker 😅. Also he's talking about quite specific field. I'm not saying he's wrong and I have learned a lot from his talks when I was at the beginning of my career. I'm just saying that don't leave from this video thinking you should be an expert on all of this immediately.
That being said, in my experience CS education is often quite lacking :(
@@dadisuperman3472Wrong. He ditched that shit like it's hot. Then did the polar opposite of what people are taught in college. That's facts.
Incredible talk, this guy has things cristal clear, excellent, so inspiring.
Finally, someone who's not being idealogical and is actually critically thinking about programming
notes:
The skill is inferring purpose and constraints in code.
Assume next people reading the codebase are smart, give them hints. They aren't idiots.
Shared resources tend to be bottlenecked, like memory. Design around it, don't abstract it.
Know your tools, like compilers. Like a painter knows his brushes very well. What does it output? Can I change its output? YOU'RE RESPONSIBLE FOR THE OUTPUT OF THE TOOL. If you can't predict it, it gets in your way.
When performance is a problem it's too late to fix it. Performance as you go.
Everything is a data problem. Programs just transform data. If you don't understand the data (limits, how many, range, how likely to x, grouped), you don't understand the problem, and your solution will be wrong.
Sought skills: Understanding how OS works, read/write assembly fluently, experience with SIMD, how memory buses work.
People lack practice, reasonable defaults and problem solving.
Gather CONTEXT, VALUE, COST, PLATFORM, DATA of the problem
Yeah! Mike Acton talk
Amazing talk
What the hell is the camera man doing
Making some kubrick moves
I was wondering the same.
Mike take me with you
Amazing
Mike Acton is the best!
Can someone explain what is the difference between "stack" and "scratch" allocators that Mike mentioned at 17:55? I thought it was the same thing
I believe, 'scratch' here means what is sometimes called an 'Arena'.
The difference is that Arenas/scratch allocators can't free sub-sections of the memory they allocate, they have to release it all at once.
Stack allocators can free sub-sections of the memory they allocate, they just have to do it in a restricted way
The biggest difference is location. Stack allocators allocate stack memory. Scratch allocators allocate from a designated area on the heap.
@@tedrivera8051 I think you're confusing 'the stack', with a stack allocator. Stack allocators can allocate/deallocate heap memory - that's actually the more common case. You're thinking of the allocations the compiler manages for you.
he is legend
This vid should have more views. Yup sometimes you just gotta copy the class or whatever (not code and paste literally) and hack away. And revert if you mess up. It's easy to get lost in model land. There's a place for it though.
Mike "Actually" Acton
Couldn't read the last slide because cameraman was lazy. Clowns still stuck in car.
the camera guy needs *practice*
And reasonable defaults.
I don't get the piece about practice. Do does he mean that manager should leave some of developer's time for practice? Or that the developers shouldn't have any responsibilities outside of work? In most professions you practice as you work, you don't get the time to do "ephemeral" practice every day
The 'when' of practice is not something he addresses, so to your first question: maybe.
The idea that you don't get the time to practice is essentially bs. You can fit it in 30 minutes, as he says, and you can find 30 minutes. If you think you can't, you probably just aren't valuing the practice (Obviously, there *are* things that you would make 30 minutes for if they were sufficiently valuable to you), which is part of the point - he thinks developers undervalue practice.
he answers that in another talk: "handmade con 2015", and to answer your question, what he means, is outside of your work hours. And he disagrees about the fact you "can not have 30 minutes a day to do something for your chosen career".
I think he is talking about what kind of people he wants to work with in general. Since he is the best he wants to work with the best. And who would most likely be a better engine developer: someone who practices and learns new things about engine development outside work because they love it, want to be the best, etc... or someone who does not?
Check out this video: "Jonathan Blow on work-life balance and working hard"
World would be a much nicer place if "Write as if the next programmer working with your code was a violent psychopath who knew where you lived" was a generally agreed-upon rule.
Not necessarily. Making your software idiot-proof always introduces constraints that will haunt you further down the road. Case in point: OOP's impact on cache-coherency.
@@todorsamardzhiev144 Data-oriented design master race
@@todorsamardzhiev144 Agree. But OO can be cache-friendly too.
@@MrAbrazildoMaybe, but it'd probably be a damned mess
@@HonsHonIf you group them together in a container (AoS) on the stack, you can still think them separately, besides their memory will stand glued together. If they don't need to be sorted, it's fast to remove in the middle, by moving the last 1 to there.
Sometimes this formation beats a hash table on L1 cache.
And if needs to make a SoA out of it, for optimization, if a common syntax for communicating to the outside was kept, this reform can be made safely, without worrying about breaking the rest of the project.
I don't think this is a mess at all.
вундертан запускай стрим с манго бей
That none of the audience had a question to ask shows they all lacked the basic competencies.
Ahaha!
You can understand everything and not have questions though.
1:30, does that mean $$ or once again another exploitation of our good will?
4:16, Single Responsibility principle stands for untangling things, to has things uncoupled. But if 2 things always should stay together, they can (and should) be interpreted as a single piece of software. People seem to not understand that, or taking it as a contradiction.
And once those 2 things became separated, an unnecessary dangerous managing task arises! 1 now has to track both of them in a synchronized way, like a juggler!
8:00, true, reality is more important. But there are near zero-cost abstractions, and situations where they can exist. Nobody should miss those moments.
8:58, and the good news about memory (for higher-level programmers) is that it's not an intricated system, that he gonna has to reinvent complex solutions for each new project. Most programming machines have about the same kind of memory levels, so you gonna reuse what you had once build, several times.
Of course, depending on the project, internet itself may be the bottleneck. So, this wall advice may be useful for some specific people.
9:56, I guess what it's trying to say is that novices should not worry about "compiler complaining too much against me". Later they will learn that compile error is a relief. Senior programmers make tools to force compile errors instead.
I use to go even further: when I use some good practice, like const correctness, and I foresee that it'll fail to compile, even so I compile it, if I have a bit of doubt about its possibility of failure. This "looses time", but keep my mindset focused on a mechanic behaviour of "coding together with the compiler".
I think your point about single-responsibility is a tautology. Things that should be together should be together, and things that shouldn't be together shouldn't? This is not something worthy of chapters in software programming books, in my opinion.
@@churchianity If 2 or more things should only work together, they should not be separated, just to the sake of "decoupling". Separate them should only make sense if a) Part of them can work independently in other parts of the code; or b) Part of them make together another entire strong concept.
10:32, linked lists by default, interfaces are examples of data structures that put too many code. Part of that may be "glued" on communication with other stuff. So it's better not use them, at least not as default. I already wrote code in the past that, by turning the optimizing flag on, resulted on the same speed!
18:04, for games this means: write your game right away, not a generic engine to later make the game. The generic code arising from it you can separate from the rest, making a lib.
On the same vibe, simple/cheated mathematics use to be better, faster and easier to code, than a complete equation for the task. For games and AI, imprecise or even truncated floating point values are often enough.
35:39, right, you can't get rid of the variables just by making an abstraction. But having them on a class can most of the time separate the low-level, complex or anti-intuitive actions from zero-cost nice interactions to other users that didn't make that class - _including the class creator, once he forgot those details_ . That's not equally achievable with f()s, because either the user will has to pass those variables explicitly or has them as global - and both are bad.
39:51, there's a tenuous line here. Abstraction can't stay on the way, can't be the goal, but rather the tool instead. I think the engineer should always verify if the story telling can go without damage. If it's possible, it's a big win. Even if it can appear in parts, told in a mechanic, truncated way, it's already a victory.
Thank you for commenting this! I wish you kept it with your other one though haha, but thank you nonetheless.
@@HonsHonI write for posterity, if anyone ever reads. 😃