Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

youtube.com

Post reply on HN
Print view View original

101–110 of 229 posts

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

#101

Post by duped »

mananaysiempre wrote: post #83
wavemode wrote: post #72

Earlier quoted context omitted.

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…

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

Classic latency vs throughput problem. 10s of GB/s of disk bandwidth doesn't help when my problem is serialized durable writes.

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

#102

Post by AnimalMuppet »

mananaysiempre wrote: post #83
wavemode wrote: post #72

Earlier quoted context omitted.

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…

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

Your analysis is correct if and only if the data is on the same machine as the calculations. If the data comes from another machine, it comes at network speed. If it comes from the internet, it comes at non-local network speed. That's very different from SSD speed.

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

#103

Post by tialaramex »

inigyou wrote: post #91
bena wrote: post #82

Earlier quoted context omitted.

660+ and the game was never finished

Doesn't mean you can't learn a lot from the attempt. Technical craftsmanship and project management skill are two completely separate skills. Definitely don't learn project management from Casey.

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" and Casey's hand coded solution is pretty bad whereas the thing which came in the box is very good. Casey understands Casey's version, and that's an upside if you are Casey but you are not. If the result was a finished game then hey, whatever, the game was finished and that matters. But that part didn't happen either, so then it's just like watching Tsoding or something.

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

#104

Post by AnimalMuppet »

tialaramex wrote: post #98
hirvi74 wrote: post #90

Earlier quoted context omitted.

So, I have never seen anyone actually use GOTOs, so maybe a lot of the stigma comes from excessive, poor usage or something. However, having written a good chunk of ASM in my life. I don't think jumps or branches are really that hard to follow. Jumps/Branches and GOTOs specify the next location. It is not as though one has to guess where. It's not the arrow, it's the archer that is the problem.

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…

> My guess is that your ASM is inflected by structured programming everywhere.

I think you're probably right. To expand on this:

In asm, you can have things that are clearly functions. You have a stack discipline going in and out of them. They end with stack cleanup, then a RET or some such, which pops the return address off of the stack and jumps to it. Within that function, you have JMP instructions (or whatever) that move around within the function. You may also call other functions, by pushing variables on the stack, and then calling JSR or whatever to push the program counter on the stack and jump, and when those functions return, you'll be right where you were in this function. That's all sane, and it's "structured assembly".

Non-structured assembly would be like the example in your second paragraph. You're in one function, and you JMP (not JSR) into the interior of a second function. Or, you simply don't have functions, just labels that you jump around do. That's not structured, and not sane.

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

#105

Post by [deleted] »

bob1029 wrote: post #78
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 Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food. I used to spend a lot of time watching crap like lex and primagen befor…

[deleted]

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

#106

Post by ntstatusquo »

bsoles wrote: post #86
bob1029 wrote: post #78

Earlier quoted context omitted.

> Feel free to point to anyone doing these deep dives Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food. I used to spend a lot of time watching crap like lex and primagen befor…

As much as I like to watch Casey, Prime, etc. on YouTube, they are not going to teach anybody anything. They are just entertainment for software people with a certain viewpoint.

My one data point is that Casey’s handmade hero series, and his immediate mode gui video from way back in 2005, are what introduced me and some friends to an entirely new way to build graphical user interfaces, and I do feel a great appreciation for that. Guys like Ryan Fleury (of RadDbg) and Vjekoslav Krajacic of Filepilot similarly credit Casey with their “radicalization” :) To your point though, it was less about specific technical knowledge conveyed by these videos and more about him evangelizing a high level approach that many folks otherwise wouldn’t have considered

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

#107

Post by zbentley »

Pannoniae wrote: post #49
FacelessJim wrote: post #22

Terrific presentation. But I have a comment: His dismissal of the argument Knuth makes regarding the hot loops could have been explored a bit better. I found it weird he didn’t mention the difference of types of programs of then vs now. Even today, in scientific code it is still absolutely the case a lot of the time that a huge chunk of the runtime comes from a single very very hot loop. It might be hidden in a libra…

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 slow peripherals (lots of embedded software) are in this class.

Scientific simulations, HFT algorithms, video games, LLMs, etc.--the stuff in the other class--aren't inconsequential, but they're dwarfed in number by the class of software that spends 99+% of its time waiting for IO. Hell, entire programming languages (node.js) have been created in response to that proportion.

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

#108

Post by LtdJorge »

bsoles wrote: post #86
bob1029 wrote: post #78

Earlier quoted context omitted.

> Feel free to point to anyone doing these deep dives Most of this kind of content comes off as relevant/topical but mindless entertainment. This is not a "deep dive" of anything that I could practically apply in my daily work. It feels good to think this content might add value and then to subsequently consume it, but it's effectively junk food. I used to spend a lot of time watching crap like lex and primagen befor…

As much as I like to watch Casey, Prime, etc. on YouTube, they are not going to teach anybody anything. They are just entertainment for software people with a certain viewpoint.

You don’t know Computer Enhance then

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

#109

Post by Pannoniae »

bena wrote: post #80
torginus wrote: post #9

Personally I'm quite sure this is super interesting, but I don't really have 3 hours to listen to this, even 1.5h at 2x speed is too much. I would very much prefer something written down, so I could absorb this at my own pace. I know, gift horse, but still.

The last hour is a Q&A. I don't know if that changes your perception of how watchable it is. It's also a little fluffy. It's basically the history of how the book Structured Programming came about, because it's that book that essentially caused Knuth to write an article that contained the quote. A lot of it is fairly interesting but it also highlights a big problem I do have with Muratori. He generalizes from self. H…

"He didn't fully understand or appreciate the quote about premature optimization, so no one did."

He ain't wrong though.... most people definitely don't get the jive for sure. Knuth was talking about a massively different kind of optimisation than what we do today yet people keep continuing to parrot the 97% figure uncritically like as it was some gospel. [0]

[0] http://www.joshbarczak.com/blog/?p=580

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

#110

Post by LtdJorge »

smj-edison wrote: post #94
Pannoniae wrote: post #57

Earlier quoted context omitted.

Sure, but there are performance issues no profiler will catch in a straightforward flamegraph reading. Some examples: 1. Your hottest loop is spilling registers which only shows up as non-local cache thrashing (i.e. some other random code becomes slow) or randomly slow instructions i.e. "why is this xorps to initialise this float suddenly slow" due to pipeline stalls 2. Your code stops fitting into cache due to the c…

How do you even measure those? Will that show up under something like VTune?

You can do all that with perf on Linux, but everything is manual.
Post reply on HN