Casey Muratori
Programmer; makes Handmade Hero and teaches Performance-Aware Programming, and argues loudly about how software got slow.
Tell me when Casey Muratori publishes
How you hear about it
- Email meSign in and we will email you when they publish
- Put it in my ppll feedSign in to follow them
- Send it to my reader appAn Atom feed of everything on this page. No account, nothing to sign up for.
https://ppll.app/casey-muratori/feed.xml
Casey Muratori did not write this page. What is this?
It collects the places they publish and what they have said there, each linked to the source. They have no account here. Is this you? Claim it, correct it, or ask us to remove it from ppll.
Where they publish
Newsletter Computer, Enhance! His course and newsletter on performance-aware programming. Has a feed.
Recent
- SIMD Mask Registers 14 Sept 2026 Although CPUs that support them are still relatively rare by percentage of installed base, mask registers are a powerful feature of modern SIMD hardware well worth understanding.
- What Is AI Doing to Math? 10 Sept 2026 Listen now (113 mins) | A special double-episode of Wading Through AI covering the recent headlines in the world of formal mathematics.
- High-Performance Database Architecture 9 Sept 2026 An interview with Tyler Cloutier
Show 17 more
- 520 Pages Per Hour 8 Sept 2026 I wanted to provide some perspective on the research process for The Big OOPs and The Root lectures. This was only feasible method I found.
- Is AI a Good Research Assistant? 2 Sept 2026 Listen now | Recently, I gave a talk called The Root of the Root of All Evil. Like The Big OOPs, it was a research-intensive talk, so Demetri and I decided it might serve as a good spot test for how well the frontier mo…
- SIMD Masking 31 Aug 2026 Once we execute both sides of an if/else, we need some way of merging the results.
- The Root of the Root of All Evil 26 Aug 2026 A Brief History of Programming's Most Ambiguous Catchphrase
- Q&A #87 (2026-08-25) 25 Aug 2026 Answers to questions from the last Q&A thread.
- The Pit of Success 19 Aug 2026 An Interview with Rico Mariani
- The Pattern Behind x64 CMPPS/PD Immediates 18 Aug 2026 If you're wondering how the 5 bits used in the CMPPD/PS immediate got assigned the way they did, Pete Cawley's got your back.
- SIMD Predicates 17 Aug 2026 Although counterintuitive at first, using purpose-built comparison instructions we can easily translate if/else branches into SIMD code.
- Branchless Absolute Value 10 Aug 2026 Some operations are uniform enough that, even though we might ordinarily think of them as using a predicate, they can nonetheless be done by direct manipulation of the underlying bit pattern.
- What New Jobs? 5 Aug 2026 Appeals to prior technological revolutions are often used to assuage fears that AI will lead to widespread unemployment.
- Three Steps from Scalar to SIMD 3 Aug 2026 When we want to change the interior of a loop (with complex control flow) from processing one thing to processing several at a time, it's best to tackle the problem in three sequential steps.
- Why AI Companies Need Scale 2 Jul 2026 AI companies seem fixated on scaling.
- Let's Decode the Mystery Bytes! 22 Jun 2026 In this follow-up to "Let's Answer Ray's Question!", we go all the way down the rabbit hole to decode the mysterious eight bytes that kept showing up in-between Ray's allocations.
- Will AI End the Open Internet? 16 Jun 2026 Listen now | With previously open source projects going closed, and artists increasingly concerned about posting their work online, is AI reversing the internet’s long-established trend toward openness?
- Q&A #86 (2026-06-10) 10 Jun 2026 Answers to questions from the last Q&A thread.
- Intuitive Random Selection (with Marc LeBlanc) 9 Jun 2026 After the ECS interview, Mahk shared a new random selection that's much more intuitive than the one typically used in game development.
- Will AI Make Me Worse? 4 Jun 2026 As people increasingly rely on AI to do some or all of their work, what effects will this have on people's work quality, skills, and emotional state?
Link verified 20 Sept 2026. Recent items update automatically from the channel.
Beliefs
Korrents What they believe 37 beliefs — each backed by an exact quote.
Each is a — compiled by korrents.com, not by them: the one-line wordings are korrents', the quotes are theirs.
Recent
Optimization means measuring the gap between your code and what the hardware could theoretically do, not making changes and checking whether the statistics improved.
What is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The software industry is massively underperforming its hardware, by factors of ten to a hundred, and people refuse to believe the numbers when you say them.
It's just like we are massively underperforming and people don't believe it when you say 10x 100x but it's actually true and we've seen a lot of proof of it as you point out.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
A 300-millisecond response budget is not an achievement but an admission: 300 milliseconds is an eternity in computing, and a product pitching it shows how far the bar has fallen.
300 milliseconds is like an eternity in computing, right? And so if you're talking about like our pitch is that we're not more than 300 milliseconds, that just shows you how the bar was so far past where it probably should have been for something.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Show 34 more
Performance cannot win a market on its own: against an incumbent held up by network effects, being far more responsive is a nice plus and nothing more.
maybe performance could be part of a package where you try to take on one of those players. like, hey, look at how much more responsive our thing is than theirs. Might be a nice plus, but that's not going to be sufficient.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
A decade of arguing that software is too slow has started to work: new products are now attacking established categories on a performance pitch alone, and getting traction.
I also see people attacking major product categories now with performance-based pitches. Things like File Pilot or the Blick video editor, like things like this that have been coming out lately where it's like, oh, really performant software to try to take on uh incumbents in a space and they've been getting traction.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Source code in any language tells you nothing about what the CPU is actually asked to do; only the compiler's assembly output does, and reading it is a skill every serious programmer should have.
If I look at the assembly language output from that compiler, I know exactly what the CPU is being asked to do. And it's not that hard to be able to learn to read assembly language so that you can see very quickly is the CPU being asked to do the things that I think it should be asked to do them.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Assembly is far simpler to learn than the modern web stack: anyone who can vertically centre a div can learn to read it.
it's really much easier if you can understand how to center a div as they say if you can vertically center a div in HTML then you can probably learn assembly language I would say
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The speed of a system is set by its longest serial dependency chain, which is a property of the architecture and cannot be parallelised away afterwards.
the performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be parallelized.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
"Optimize it later" would be safe advice only if every engineer already knew how to avoid the architectural mistakes that no later optimization can remove.
If every uh software engineer knew to watch out for false serial dependency chains, things where they were creating series of dependent operations that could not be optimized away or other sorts of architectural problems like that that cannot be easily fixed, then the world would look more like just wait and optimize the hotspot, right?
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Everyone on a team who makes architectural decisions must understand performance, because a codebase that can be optimized later only ends up that way on purpose.
everybody on your team who is making architectural decisions, those people must know performance and they must make decisions that will allow the other people downstream of them to use an architecture which can be optimized later. If you don't do that, you're just rolling the dice.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The steady stream of "we had to rewrite the whole thing because it was too slow" engineering blog posts is the proof that deferring performance to hotspot optimization does not work.
They've got blog posts of we had to rewrite this whole thing because the performance was bad. If it was always hotspots that made your performance bad, you'd never have to rewrite the whole thing. So, we know that that doesn't work anymore.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Hand-optimizing hot spots barely matters any more, because the libraries are already fast and CPUs are extremely good at running bad code quickly; what is left is architecture.
One of the reasons that you don't see hotspot optimization as a thing that really matters that much anymore and one of the reasons I advise that architecture and and not making bad decisions is much more important is because a lot of libraries already have been optimized for you that you might use.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Writing software far better than most of what ships today does not take an expert: you do not have to know very much at all.
So the good news is in order to write software that's much better than a lot of the software you use today, you don't have to know that much.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
How data is laid out and how it is accessed are architectural decisions with nothing to do with hot spots, and the difference between two layouts can be enormous.
when you're working with a lot of data, the the difference can be massive if you structure it in one way versus structuring another way, right? Again, architectural decisions that have nothing to do with hotspots, they're how all the data is laid out and what the access pattern is, right?
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Understanding how a modern CPU executes code is a few months of work, not a four-year degree, and it should be ordinary equipment for a software engineer.
You go to school for four years to learn this. There's no reason you can't learn this in a few months. It's not that hard.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The games industry already ran the experiment everyone expects from AI, when engines became licensable, and the results were not good news.
I've said like the licensable engine thing kind of was our AI transition already unfortunately and uh I regret to inform you that the news is not probably that positive.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Once the barrier to making a game collapsed, making a good game stopped being enough: no game gets noticed organically any more, so shipping without a marketing plan is unwise.
It's it's so massive that there is no way that your game will be organically noticed anymore pretty much period.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Graphics have stopped selling games: most of the market by revenue no longer cares how a game looks, so new games now compete with the entire back catalogue.
But a large portion of the gaming market by revenue doesn't really care what the game looked like all that much uh in a sense that whatever we're doing today is good enough. So 10 years from now if the games look much better for some reason no one will really think of that as a huge differentiation differentiator in terms of sales.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The specific rules taught as clean code are simply bad programming practices, and they get worse when you apply them together.
If you look at those things, they're kind of just bad programming practices. I I don't really know how else to say them. They don't mesh well when you put them together.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
What clean-code polymorphism really costs you is not the virtual call but the optimizations the compiler can no longer perform once it cannot see what runs.
But it's the cost of the compiler not being able to do any optimizations. That's the actual cost. And that cost can be severe.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Development should never be driven by tests: how much to test is an engineering decision to be costed project by project, not a methodology to adopt by default.
I would say the part that I don't like about test-driven development is the testdriven part. I don't think development should ever be driven by tests.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
There is no trade-off between well-architected code and fast code: in practice, the code that is architected properly is also the code that runs quickly.
I have never really understood the sort of mentality of there's a difference between code that is like well architected by some principles and code that runs quickly because in my experience usually the code that is architected properly is also the code that runs quickly.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Much of the wisdom programmers pass on to each other is nonsense that nobody ever tested, and refusing to be dogmatic about untested practice is what marks out a good engineer.
I find there's a lot of like received programming wisdom that's just nonsense. Like clearly no one's ever tested it and if they did they would have found out that it's that there's no actual basis for it.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Refusing to write code with AI can be a philosophical decision rather than a productivity one: the reason to program something is that you want to program it.
it's more about what do you want to do? Like what why are you spending this time, right? It's a philosophical question, not a productivity question.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
The absence of a visible productivity jump from AI proves nothing, because a real ten percent uplift across the board would be impressive and almost invisible from outside.
Then there's another possibility which is that it actually already has worked but just the productivity boost isn't as big as would be obvious if people got 10% more productive. That would still be pretty impressive because it's hard to get a 10% across the board uplift.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Programmers should be reading research papers and crawling their references, and the fact that almost none of them do is a bigger gap than any book recommendation could close.
I want to recommend that people read a paper. I'm trying to get more people to just to just read papers because I realized I read a ton of papers.
Why performant code matters (but gets widely ignored), with Casey Muratori Said 26 Aug 2026
Unity is mainly an advertising company: more than half its revenue comes from advertising rather than from selling its game engine.
Less than half their revenue comes from game engines. Over half comes from advertising.
Game Development Post-Unity Said 14 Sept 2023
Software performance is central to long-term business success rather than a niche engineering concern.
Software performance appears to be central to long-term business interests.
Performance Excuses Debunked Said 26 Apr 2023
The evidence from the largest software companies says programmers should take performance more seriously than they do, not less.
the logical conclusion would be that programmers need to take performance more seriously than they have been, not less!
Performance Excuses Debunked Said 26 Apr 2023
Performance-aware programming is a skill a working developer can learn in months rather than years.
Learning basic performance-aware programming skills is something a developer can do in months rather than years.
Performance Excuses Debunked Said 26 Apr 2023
The programming practices taught as best practice are ruinous for performance and should not be followed.
The ideas underlying the “clean” code methodology are almost all horrible for performance, and you shouldn’t do them.
"Clean" Code, Horrible Performance Said 28 Feb 2023
Giving up a decade or more of hardware performance to make programming more comfortable is not an acceptable trade.
It simply cannot be the case that we're willing to give up a decade or more of hardware performance just to make programmers’ lives a little bit easier.
"Clean" Code, Horrible Performance Said 28 Feb 2023
A programmer’s job is to write programs that run well on the hardware they are given.
Our job is to write programs that run well on the hardware that we are given.
"Clean" Code, Horrible Performance Said 28 Feb 2023
Duplication is cheaper than the wrong abstraction, so code should not be made reusable before there are real examples of what the reuse has to do.
Like a good compressor, I don't reuse anything until I have at least two instances of it occurring.
Semantic Compression Said 28 May 2014
Code written to be reusable before there is anything reusing it is likely to be reusable in the wrong way.
This is crucial for efficiency, because if you only have one example, or worse, no examples (in the case of code written preemptively), then you are very likely to make mistakes in the way you write it and end up with code that isn't conveniently reusable.
Semantic Compression Said 28 May 2014
Code is procedurally oriented rather than object-oriented: objects are just constructs that emerge to let procedures be reused.
Code is procedurally oriented, and the "objects" are simply constructs that arise that allow procedures to be reused.
Semantic Compression Said 28 May 2014
The material that teaches people how to program is overwhelmingly bad, because the programmers who know how to do it well rarely think it is worth writing down.
the landscape of educational materials out there still overwhelmingly falls into the "objectively bad" category
Semantic Compression Said 28 May 2014
Beliefs others hold too
Duplication is cheaper than the wrong abstraction, so code should not be made reusable before there are real examples of what the reuse has to do. 2 hold this
Like a good compressor, I don't reuse anything until I have at least two instances of it occurring.
Semantic Compression Said 28 May 2014
What is a korrent?
A korrent is a belief a person has stated in their own words: one sentence stating the claim, backed by a quote and a source, kept at korrents.com.
Under a name here, the quoted block is what they actually said. The korrent beneath it is the claim those words support, in korrents' wording — tap it to see the record, its source, and who else holds it.
Nobody here wrote their own korrents. They are compiled from public statements, and a person can change their mind, which is recorded too.
Feed
As its own page →Hiding
14 September
10 September
9 September
8 September
2 September
31 August
26 August
From one piece Why performant code matters (but gets widely ignored), with Casey Muratori 26 beliefs · youtube.com
-
Their words
I want to recommend that people read a paper. I'm trying to get more people to just to just read papers because I realized I read a ton of papers.
-
Their words
Then there's another possibility which is that it actually already has worked but just the productivity boost isn't as big as would be obvious if people got 10% more productive. That would still be pretty impressive because it's hard to get a 10% across the board uplift.
-
Their words
it's more about what do you want to do? Like what why are you spending this time, right? It's a philosophical question, not a productivity question.
+ 23 more
-
Their words
I find there's a lot of like received programming wisdom that's just nonsense. Like clearly no one's ever tested it and if they did they would have found out that it's that there's no actual basis for it.
-
Their words
I have never really understood the sort of mentality of there's a difference between code that is like well architected by some principles and code that runs quickly because in my experience usually the code that is architected properly is also the code that runs quickly.
-
Their words
I would say the part that I don't like about test-driven development is the testdriven part. I don't think development should ever be driven by tests.
-
Their words
But it's the cost of the compiler not being able to do any optimizations. That's the actual cost. And that cost can be severe.
-
Their words
If you look at those things, they're kind of just bad programming practices. I I don't really know how else to say them. They don't mesh well when you put them together.
-
Their words
But a large portion of the gaming market by revenue doesn't really care what the game looked like all that much uh in a sense that whatever we're doing today is good enough. So 10 years from now if the games look much better for some reason no one will really think of that as a huge differentiation differentiator in terms of sales.
-
Their words
It's it's so massive that there is no way that your game will be organically noticed anymore pretty much period.
-
Their words
I've said like the licensable engine thing kind of was our AI transition already unfortunately and uh I regret to inform you that the news is not probably that positive.
-
Their words
You go to school for four years to learn this. There's no reason you can't learn this in a few months. It's not that hard.
-
Their words
when you're working with a lot of data, the the difference can be massive if you structure it in one way versus structuring another way, right? Again, architectural decisions that have nothing to do with hotspots, they're how all the data is laid out and what the access pattern is, right?
-
Their words
So the good news is in order to write software that's much better than a lot of the software you use today, you don't have to know that much.
-
Their words
One of the reasons that you don't see hotspot optimization as a thing that really matters that much anymore and one of the reasons I advise that architecture and and not making bad decisions is much more important is because a lot of libraries already have been optimized for you that you might use.
-
Their words
They've got blog posts of we had to rewrite this whole thing because the performance was bad. If it was always hotspots that made your performance bad, you'd never have to rewrite the whole thing. So, we know that that doesn't work anymore.
-
Their words
everybody on your team who is making architectural decisions, those people must know performance and they must make decisions that will allow the other people downstream of them to use an architecture which can be optimized later. If you don't do that, you're just rolling the dice.
-
Their words
If every uh software engineer knew to watch out for false serial dependency chains, things where they were creating series of dependent operations that could not be optimized away or other sorts of architectural problems like that that cannot be easily fixed, then the world would look more like just wait and optimize the hotspot, right?
-
Their words
the performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be parallelized.
-
Their words
it's really much easier if you can understand how to center a div as they say if you can vertically center a div in HTML then you can probably learn assembly language I would say
-
Their words
If I look at the assembly language output from that compiler, I know exactly what the CPU is being asked to do. And it's not that hard to be able to learn to read assembly language so that you can see very quickly is the CPU being asked to do the things that I think it should be asked to do them.
-
Their words
I also see people attacking major product categories now with performance-based pitches. Things like File Pilot or the Blick video editor, like things like this that have been coming out lately where it's like, oh, really performant software to try to take on uh incumbents in a space and they've been getting traction.
-
Their words
maybe performance could be part of a package where you try to take on one of those players. like, hey, look at how much more responsive our thing is than theirs. Might be a nice plus, but that's not going to be sufficient.
-
Their words
300 milliseconds is like an eternity in computing, right? And so if you're talking about like our pitch is that we're not more than 300 milliseconds, that just shows you how the bar was so far past where it probably should have been for something.
-
Their words
It's just like we are massively underperforming and people don't believe it when you say 10x 100x but it's actually true and we've seen a lot of proof of it as you point out.
-
Their words
What is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
25 August
19 August
18 August
17 August
10 August
5 August
3 August
2 July
22 June
16 June
10 June
9 June
4 June
Nothing matches.
About the English under a post
Some people here publish in a language other than English. Where they do, this site shows a machine translation beneath the post, in this typeface — the site's own, not theirs.
The post itself is never changed, moved or hidden: what is set in the serif above is exactly what the person published, and it is what to quote them on. A translation can be wrong in ways that matter, especially about tone.
Only the post's own words are translated. A quoted post, a linked article and a belief on korrents.com are left in their original language.