Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video] • Hacker News Board

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#151

Post by groundzeros2015 » Sun, Aug 30, 2026, 10:11 PM UTC

zbentley wrote: post #107

Pannoniae wrote: post #49

Earlier quoted context omitted.

Being I/O bound is usually a result of bad engineering practices though. If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare, or more likely that your code is so unoptimised that barely any computation gets carried out while your code is waiting on memory/disk/network. "I can't do anything because my program is I/O-bound" is more of an excuse / menta…

> If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare This is backwards. I bet that by count, many more programs are written in domains where they're necessarily IO bound than the inverse. Anything that uses the network for its core functionality, anything reliant on a datasource whose aggregate contents are O(memory)+ size, or anything reliant on sl…

Bottleneck is a misleading word here. Yes the network is slow. But you can still save 200ms in response time by working on your CPU.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#152

Post by groundzeros2015 » Sun, Aug 30, 2026, 10:13 PM UTC

wavemode wrote: post #72

Pannoniae wrote: post #49

Earlier quoted context omitted.

Being I/O bound is usually a result of bad engineering practices though. If you're I/O bound, that either means the problem doesn't require much computation - which is possible but fairly rare, or more likely that your code is so unoptimised that barely any computation gets carried out while your code is waiting on memory/disk/network. "I can't do anything because my program is I/O-bound" is more of an excuse / menta…

No, I don't think the way you're characterizing this is accurate. I/O is inherently very slow compared to computation. And many programs genuinely don't have any useful computation to do while waiting for I/O - because the result of that I/O operation contains the information needed for the program to even make its next decision. Such programs are not necessarily impossible to optimize. One common optimization is to…

Cases where your cpu work is not a step in that pipeline are rare. (Cannot be parallelized)

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#153

Post by groundzeros2015 » Sun, Aug 30, 2026, 10:17 PM UTC

socalgal2 wrote: post #27

tialaramex wrote: post #5

tl;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…

> 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.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#154

Post by groundzeros2015 » Sun, Aug 30, 2026, 10:19 PM UTC

ex-aws-dude wrote: post #132

What I don't understand with both Muratori/Blow is that they seem to be incredulous that someone wouldn't just make software high quality and fast for the sake of it Like they can't comprehend the fact that these things only happen if there is an incentive for it I think its because they work in games where there is a business incentive for performance, users care a lot if framerate suffers in a game They are so used…

The fallacy is assuming it takes more work to get good performance. When what’s really lacking is clarity about the problem and solution.

Optimizing code for max performance does take work. But just not doing incredibly dumb things and writing simple programs just takes education (and re-education).

I can’t count how many times I’ve replaced a distributed system with for loop.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#155

Post by andersonpico » Sun, Aug 30, 2026, 10:24 PM UTC

guitarlimeo wrote: post #133

tialaramex wrote: post #103

Earlier quoted context omitted.

Sure, but the biggest reason to direct anybody to these videos is that they should actually make that video game they want to make, not just think about it - and so the fact that Handmade Hero just trails off and doesn't end up producing a finished video game is a problem. The craftsmanship is dubious. I think it's a problem that people assume Casey knows what he's doing when so often he's like "We're doing it live"…

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 such an incredible game and it shows how talented Billy Basso is in multiple disciplines

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#156

Post by andersonpico » Sun, Aug 30, 2026, 10:26 PM UTC

inigyou wrote: post #50

sirwhinesalot wrote: post #43

Earlier 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…

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

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#157

Post by mananaysiempre » Sun, Aug 30, 2026, 10:34 PM UTC

wavemode wrote: post #129

mananaysiempre wrote: post #83

Earlier quoted context omitted.

> I/O is inherently very slow compared to computation. Not anymore, no. Your SSD, before any caching, does gigabytes per second of sequential reads. For any bytewise processing, except the most trivial of tasks, you’ll struggle to get above a few hundred megabytes per second with scalar (native) code. To actually keep up with a modern SSD, you’ll virtually always have to hand-write SIMD loops, minimize the number of…

No, you're comparing apples and oranges. All an SSD sequential read is doing is copying data from one place to another. So you should be comparing SSD bandwidth to memory bandwidth, not SSD bandwidth to (time it takes to execute some arbitrary algorithm). Or you should be comparing SSD bandwidth when performing millions of tiny random non-sequential reads and writes, to the algorithm time. What your comment demonstra…

Muratori et al. like comparing speeds to (single-core) memory bandwidth (dozens of GB/s) and that’s a reasonable upper bound, but generally it seems to me that, unless you operate on huge elements and don’t do very much with them, you won’t get within an order of magnitude of it. Even if you think about RAM exclusively, the headline numbers are for sequential reads and things will slow down dramatically if you actually perform random accesses (IIRC, DDR5 is about as slow as DDR4 there in terms of physical time units, so much slower in terms of bus cycles). Meanwhile, in a real situation, you’re going to be bound by compute long before that.

And I think you’re being unfair labelling my couple of examples “some arbitrary algorithm[s]”: my choice was indeed arbitrary, but it’s also immaterial. The general setup would be that you’re processing elements in a loop and that your iterations are serialized (as they usually more or less are before you get around to optimization). A loop body of even three lines of C is likely to have a latency of 5–10 cycles or so, and you’re running on a core clocked somewhere from 5 GHz (desktop) to half that (server). So the best you should expect is ~500 MB/s if your elements are bytes, ~2 GB/s if they’re 32-bit integers, etc. For very simple tasks (that are also somehow not susceptible to vectorization), it is possible to not lose this order of magnitude and get down to almost 1 cycle/element in scalar code, but that requires heroic effort[1].

[1] https://github.com/powturbo/Turbo-Histogram

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#158

Post by namuol » Sun, Aug 30, 2026, 10:41 PM UTC

socalgal2 wrote: post #25

cuechan wrote: post #6

He is just legendary when it comes to game programming

What games has he shipped?

He did some work for The Witness and wrote some nice technical blog posts about it [1].

I don’t know the extent to which he contributed beyond that, but he is therefore by some reasonable definition _a_ game developer.

[1] the-witness.net/news/author/casey/

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#159

Post by georgemcbay » Sun, Aug 30, 2026, 10:42 PM UTC

tancop wrote: post #135

sirwhinesalot wrote: post #43

Earlier 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…

> They are probably stronger than ever in terms of games using their tech and collected license fees.

True, though they've been acquired by Epic since 2021. They keep the RAD Game Tools branding, but aren't their own separate company anymore.

Oodle/Kraken is mostly the work of Charles Bloom and Fabian Giesen, a couple of other "legendary game programmers" at RAD, but who aren't quite as visibly prominent as Casey has been in the modern software developer mediasphere.

Re: Casey Muratori – The Root of the Root of All Evil – BSC 2026 [video]

#160

Post by Kranar » Sun, Aug 30, 2026, 10:59 PM UTC

Barrin92 wrote: post #131

Almondsetat wrote: post #66

Earlier quoted context omitted.

Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science and the ideas that have not yet come to fruition despite being extremely old

>Feel free to point to anyone doing these deep dives that specifically tackle the lost knowledge of the early decades of computer science I skimmed through the video because I don't have two hours but there's no lost knowledge in it, he's going over well known papers from Dijkstra, Hoare or Knuth. The paper he bases most of the talk around Knuth's Structured Programming with go to Statements is his most often cited w…

The well known papers are not what the talk is about though. The talk is titled "The root of the root..." specifically to go over the specific and incredibly/almost impossible to find citations those well known papers used and built upon to see what historical insights that might have been lost went into how those papers are now interpreted (or as the video argues, misinterpreted).