Earlier quoted context omitted.
Is this.. is this a real question?
I hope the above user is being sarcastic.
Based on the answers below, I think that perhaps not. :(
Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
191–200 of 229 posts
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#192What is the thesis of his talk? Is it worth viewing?
He tracks down where the statement "Premature optimization is the root of all evil" actually comes from, and whether the assumptions set out in the text where it was published still hold.
It doesn't really contain anything new or earthshattering, but if you find diving into the history of programming as a discipline interesting, it might be for you.
I would recommend it to anyone who liked the rambling style of "The big OOPs", but imo that one was better. I still liked it.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#193Earlier quoted context omitted.
Well Billy Basso was hugely inspired by the Handmade Hero series and went on to make the critically acclaimed Animal Well because of it. That's enough of a win for that series in my eyes.
Animal Well is a great game, there's a lot in there and I appreciate it when a game is deep rather than big but I don't see much connection there. Maybe it's like how "Maze: Solve The World's Most Challenging Puzzle" (a book I disliked immensely) inspired Tonda Ros to make "Blue Prince" a game which I enjoyed tremendously.
Animal Well wouldn't exist without Handmade Hero, Billy himself said it in an interview. The first game architecture he made was RAII etc and full of spaghetti and then he actually followed Handmade Hero and started to getting somewhere.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#194Earlier quoted context omitted.
> He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same project file and code files. this shouldn't be right, wtf
https://www.youtube.com/watch?v=GC-0tCy4P1U at 21:30 for modern Visual Studio and then 35:51 for Windows XP era Visual Studio.
Wow, modern Visual Studio is unbelievable slop
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#195Earlier quoted context omitted.
> Measure. Measure. Measure. The problem is knowing what to measure. There's another saying "When a measure becomes a target, it ceases to be a good measure." As an example from memory, there was a game dev company that celebrated they had maxed out the cores on the PS3. That didn't mean anything though, anyone can max out the cores by filing them with bad code. But hey, their "measurement" told them they had maxed o…
That quote mostly applies to human organizations where the connection between outcome and metric is questionable. Or where incentives unexpectedly change behavior. If your goal is fast software it can be measured quantively and you’re likely to improve the actual thing using those metrics.
The goal above was to write fast software. The developers made the mistake of seeing that they had saturated all the cores as "We did a good job of using the entire machine" = "our code is fast". They had a measurement and misinterpreted what it meant.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#196Earlier quoted context omitted.
The legendary games programmer thing is a meme. Casey is professionally best known for his work at RAD game tools (a highly successful middleware provider for game development back in the day), not games he himself developed. What he is most highly regarded for is his teaching, particularly the Handmade Hero series on YouTube, which various programmers directly attribute as being responsible for their own professiona…
"Highly successful middleware provider back in the day" is an understatement. Bink was the cutscene video codec for a long time and it's still the most popular option by far. Kraken compression is so good Sony worked with AMD to make a hardware decoder for the PS5 and paid for a general license that lets games use it for free. They are probably stronger than ever in terms of games using their tech and collected licen…
Are you conflating what Casey worked on with what RadTools worked on?
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#197Earlier quoted context omitted.
Never as in, in BASIC, or you've never seen goto in C? The de-fanged C "goto" is all over the place in Linux and in similar close-to-metal C software. C does not (yet, likely C2Y will fix this) have labelled break, so goto is used to say "I am inside a mess of nested loops, we're done, end the loops" and as a catch-all failure handler in some codebases. My guess is that your ASM is inflected by structured programming…
To be honest, I do not have much experience with C nor BASIC. I only know the extreme basics of C, and I have never written a line of BASIC in my entire life. My first real exposure to programming was in high school (Java). From there, I basically went from high-level languages -> x86 -> high-level languages again -> starting to play with AArch64 in an attempt to but some grooves back in my smooth brain. > My guess i…
> Was it just a product of time?
Same reason that nobody did the Fosbury Flop at the 1948 Olympics - Dick Fosbury hasn't shown this technique yet and it's not obvious if you've never seen it that this is a better way to perform an Olympic regulation high jump. Twenty years later, he does exactly that and wins Gold and by the 1988 Olympics this is how everybody does a high jump, but in 1948 nobody knows it.
Your instinct to "create a separate function" is exactly Structured Programming.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#198Earlier quoted context omitted.
He mostly evangelizes non-pessimal software. He advocates that your program should only be a small factor like 3x slower than the hypothetical optimum - instead of 10000x slower as today's software often is. He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same proje…
> He compared Visual C++ 6's debugger on hardware from the time to current Visual Studio's debugger on current hardware, and found the former much faster when performing the exact same tasks on the exact same project file and code files. this shouldn't be right, wtf
It's right.
When did you start using computers? I'm getting older now, and some people weren't alive when I first used a computer.
It's because the older programming approach was to just tell the computer how to do the thing - and the modern approach is to write a framework inside which you write a framework inside which you write an inefficient version of the thing because it's constrained to the tools available in the framework stack.
Old-school implementation of "scroll up": copy pixels then redraw the pixels at the bottom.
New-school implementation of "scroll up": delete virtualized rows from the beginning of a DOM table and add more to the end. Change the height properties on different parts of the scrollbar. Relayout the whole DOM, several times if you're not careful. Redraw the whole screen.
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#199Earlier quoted context omitted.
The trouble is, his knowledge covers just a slice of it. He won't talk about stuff like functional programming for instance
Yeah. Casey is just some guy who’s good at software and YouTube. I’ve worked with dozens of people at his level technically. But very few with his interest and skill at making videos. It’s a pity there’s not more people like him. I’ve met some incredibly smart people in the FP world. I wish more of them made approachable YouTube videos explaining what they know. I recently learned about “Safe Haskell” which, if adapt…
Safe Haskell is just a worst version of Rust's unsafe. What it actually does is equivalent to Rust's #![forbid(unsafe_code)] which immediately lead to a question: so Haskell has unsafe, just like Rust? And of course it does. Any practical systems language has unsafe in one form or another, not only for FFI but also for performance, Rust is just honest about it.
There's two reasons Safe Haskell is substantially worse than what Rust does. Safe Haskell works by annotating code that is safe, but that's entirely backwards. We need to annotate unsafe code, and explain in plain English exactly why it is okay in that particular instance (of course it would be better to explain in code, like, give a formal proof that is checked by the compiler, but then it isn't unsafe anymore!). Safe Haskell answer for that is to annotate good unsafe code as trustworthy, but that doesn't work because it doesn't goes in detail on why the code is trustworthy (to do so you really need to go into the details, you can't handwave it). It's the // SAFETY comments that are at the heart of Rust's unsafe, carefully explaining safety invariants that must be kept (specially important if we are modifying code), not unsafe { } blocks.
The second reason is much simpler. It's optional, and approximately nobody uses Safe Haskell or cares about it. If people used it we would have something to improve upon. So Rust achievement here is mostly sociological, it's a community of programmers that care about safety. Which is good given that a Rust program typically have much more unsafe code than a Haskell program.
Here's a thread about Safe Haskell issues https://www.reddit.com/r/haskell/comments/zwkqke/deprecating... that links to https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
And an older thread https://www.reddit.com/r/haskell/comments/msa3oq/safe_haskel...
Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]
#200tl;dr the saying is that "premature optimisation is the root of all evil", and Casey burrows into contemporary data to show that really although the claim was 3% of the code takes up 90% of the runtime even then it was more likely 4% takes 50%. The best thing you could take away from this lecture is something a reasonable person should take away from the original "root of all evil" saying anyway. Measure. Measure. Me…
In other videos Casey argues against the profile–fix–repeat workflow (I’m not saying that you necessarily meant this by measuring), instead arguing for estimating the theoretical maximum, then trying to get close enough to it. His argument is that the former might push you towards a local minimum without realising that you could do much better
I've always used this method of working and can stand by it. For instance let's say you are working on a high-speed real-time image processing system. If you know that each image is 1080p for instance, that's 2 million pixels, and we will have 3 bytes per pixel for colour, then that's like 6MB per image (without compression). If you have 25 GB/s of RAM bandwidth, then there is a hard limit of ~4 thousand frames per second if you aren't even doing any processing. Therefore if you strip out your processing and are only getting say 400 frames per second, you know something is going wrong.
This can be applied roughly to anything. I find it very handy when thinking about CPU/GPU performance as well. For instance knowing that at 5GHz you have 5 billion clock cycles per second, which depending on instructions and pipe lining etc... can be roughly 5-30 billion operations per second per core tells you how long some process should take if you know roughly how many operations are required and the data size you are operating on.
Obviously as you drill down things get much more complicated, but they give you some rough idea about how fast things could be under some set of assumptions. Very similar to how a physicist works with models and assumptions.