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

121–130 of 229 posts

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

#121

Post by mariusor »

HexDecOctBin wrote: post #92
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…

> that I could practically apply in my daily work When has History of any kind ever held practical value?

Is this.. is this a real question?

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

#122

Post by megagpt3 »

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…

Modern networks can transfer data more quickly than CPUs can process it. Starting at 100Gbps.

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

#123

Post by bena »

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…

I watch primeagen mostly for awareness of general tech news items.

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

#124

Post by kenfox »

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…

The computers at the time had very little ram. The IBM System/360 didn’t get 1MB until 1968. I suspect a lot of programs were I/O bound just to be able to work at all. Most modern engineers cannot conceive of doing anything useful with 64KB and I think it’s a mistake to project modern practices 50 years into the past.

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

#125

Post by Pannoniae »

bena wrote: post #119
Pannoniae wrote: post #109

Earlier quoted context omitted.

"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

[flagged]

He made middleware used by countless games over at RAD. I'd say that counts as contributing to game development.

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

#126

Post by bob1029 »

chamomeal wrote: post #112
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…

agree regarding primagen but I don’t think that’s a good comparison at all

Casey is a frequent guest on his shows. It's hard to not conflate the two.

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

#127

Post by yoyohello13 »

hirvi74 wrote: post #79
OtomotO wrote: post #54

Earlier quoted context omitted.

Absolutely. Like I agree with most everything he says and I like to optimise my own software, but for my day to day jobs and contracts it's simply not feasible. That level of performance and rigor is not what is demanded nor paid or appreciated. E.g. in Enterprise circles it's still OOP from top to bottom. Mixed with a tad more functional style due to varying adoption of that paradigm in the languages used by enterpr…

> not what is demanded nor paid or appreciated. I suppose it is a matter of what one works on, but that has been consistent in my career. I have seen many be rewarded for choosing what I would deem intentional, gross negligence. But hey, those devs get work finished faster, and that's all that matters to the non-technical folks.

It’s not a coincidence that Casey and other high profile performance minded people are in game dev. Thats a field where performance is important (or at least a consideration). In web dev or regular enterprise app dev it’s simply not a consideration that needs to be made most of the time.

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

#128

Post by yoyohello13 »

torginus wrote: post #59
andai wrote: post #34

Earlier quoted context omitted.

Maybe go for a long drive? Long walk? Whatever floats your boat. I used to do manual labor and I would work my way through like eight hours of audiobooks per day.

I've noticed after I've switched to audiobooks that my retention is horrible compared to reading. For actual complex topics, it's even worse.

I agree. I use audiobooks for fiction. For learning I need to read the thing to really retain anything.

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

#129

Post by wavemode »

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…

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 demonstrates is that it is possible in some cases for I/O to be fast enough to not be a performance bottleneck for certain kinds of programs. But not that I/O is not slow.

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

#130

Post by wavemode »

adgjlsfhk1 wrote: post #75
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 This isn't really true anymore. IO has bad latency, but modern SSD bandwidth is ~5-15GB/s. If your program is IO latency bound and processing less that 5GB/s you aren't IO bound, you aren't hiding your latency well enough.

> modern SSD bandwidth is ~5-15GB/s

That's nothing compared to modern memory bandwidth.

Post reply on HN