korrents

Casey Muratori

@casey-muratori · 37 positions · 0 changes of mind

Game and engine programmer, creator of Handmade Hero and of the Computer Enhance course on performance-aware programming, and a long-standing critic of object-oriented design orthodoxy. He worked on the user interface of Jonathan Blow's The Witness, which is the codebase his writing on compression-oriented programming draws its examples from.

Casey Muratori did not write this page.

We collected these quotes from things they published elsewhere, and every quote links to where it was said. They have no account here and have not endorsed this site. Quotes are word for word; the short line under each one is our own restatement, not their wording. Their own site. Is this you? Claim it or ask us to remove it. Or tell us what is wrong here.

  1. Our reading

    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.

    Their wordsmaybe 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.
    spoken · machine transcript hear it at 0:18:28 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 1st of 26 in this recording

    Interesting

  3. Our reading

    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.

    Their wordsI 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.
    spoken · machine transcript hear it at 0:19:45 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 2nd of 26 in this recording

    Interesting

  5. Our reading

    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.

    Their words300 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.
    spoken · machine transcript hear it at 0:20:51 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 3rd of 26 in this recording

    Interesting

  7. Our reading

    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.

    Their wordsIt'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.
    spoken · machine transcript hear it at 0:21:36 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 4th of 26 in this recording

    Interesting

  9. Our reading

    Optimization means measuring the gap between your code and what the hardware could theoretically do, not making changes and checking whether the statistics improved.

    Their wordsWhat 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.
    spoken · machine transcript hear it at 0:24:09 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 5th of 26 in this recording

    Interesting

  11. Our reading

    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.

    Their wordsIf 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.
    spoken · machine transcript hear it at 0:27:37 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 6th of 26 in this recording

    Interesting

  13. Our reading

    Assembly is far simpler to learn than the modern web stack: anyone who can vertically centre a div can learn to read it.

    Their wordsit'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
    spoken · machine transcript hear it at 0:30:22 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 7th of 26 in this recording

    Interesting

  15. Our reading

    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.

    Their wordsthe performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be parallelized.
    spoken · machine transcript hear it at 0:35:23 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 8th of 26 in this recording

    Interesting

  17. Our reading

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

    Their wordsIf 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?
    spoken · machine transcript hear it at 0:35:57 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 9th of 26 in this recording

    Interesting

  19. Our reading

    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.

    Their wordseverybody 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.
    spoken · machine transcript hear it at 0:36:56 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 10th of 26 in this recording

    Interesting

  21. Our reading

    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.

    Their wordsThey'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.
    spoken · machine transcript hear it at 0:40:18 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 11th of 26 in this recording

    Interesting

  23. Our reading

    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.

    Their wordsOne 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.
    spoken · machine transcript hear it at 0:43:49 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 12th of 26 in this recording

    Interesting

  25. Our reading

    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.

    Their wordsSo 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.
    spoken · machine transcript hear it at 0:44:43 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 13th of 26 in this recording

    Interesting

  27. Our reading

    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.

    Their wordswhen 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?
    spoken · machine transcript hear it at 0:51:20 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 14th of 26 in this recording

    Interesting

  29. Our reading

    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.

    Their wordsYou 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.
    spoken · machine transcript hear it at 0:53:11 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 15th of 26 in this recording

    Interesting

  31. Our reading

    The games industry already ran the experiment everyone expects from AI, when engines became licensable, and the results were not good news.

    Their wordsI'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.
    spoken · machine transcript hear it at 1:07:23 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 16th of 26 in this recording

    Interesting

  33. Our reading

    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.

    Their wordsIt's it's so massive that there is no way that your game will be organically noticed anymore pretty much period.
    spoken · machine transcript hear it at 1:08:42 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 17th of 26 in this recording

    Interesting

  35. Our reading

    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.

    Their wordsBut 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.
    spoken · machine transcript hear it at 1:11:37 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 18th of 26 in this recording

    Interesting

  37. Our reading

    The specific rules taught as clean code are simply bad programming practices, and they get worse when you apply them together.

    Their wordsIf 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.
    spoken · machine transcript hear it at 1:18:34 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 19th of 26 in this recording

    Interesting

  39. Our reading

    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.

    Their wordsBut 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.
    spoken · machine transcript hear it at 1:20:46 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 20th of 26 in this recording

    Interesting

  41. Our reading

    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.

    Their wordsI 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.
    spoken · machine transcript hear it at 1:22:54 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 21st of 26 in this recording

    Interesting

  43. Our reading

    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.

    Their wordsI 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.
    spoken · machine transcript hear it at 1:25:50 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 22nd of 26 in this recording

    Interesting

  45. Our reading

    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.

    Their wordsI 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.
    spoken · machine transcript hear it at 1:32:14 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 23rd of 26 in this recording

    Interesting

  47. Our reading

    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.

    Their wordsit'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.
    spoken · machine transcript hear it at 1:35:09 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 24th of 26 in this recording

    Interesting

  49. Our reading

    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.

    Their wordsThen 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.
    spoken · machine transcript hear it at 1:43:40 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 25th of 26 in this recording

    Interesting

  51. Our reading

    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.

    Their wordsI 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.
    spoken · machine transcript hear it at 1:50:33 · all korrents from this recording

    ↗Why performant code matters (but gets widely ignored), with Casey Muratoriyoutube.com 26th of 26 in this recording

    Interesting
  52. 3 years earlier

  53. Our reading

    Unity is mainly an advertising company: more than half its revenue comes from advertising rather than from selling its game engine.

    Their wordsLess than half their revenue comes from game engines. Over half comes from advertising.

    ↗Game Development Post-Unitycomputerenhance.com

    Interesting
  54. 5 months earlier

  55. Our reading

    Software performance is central to long-term business success rather than a niche engineering concern.

    Their wordsSoftware performance appears to be central to long-term business interests.

    ↗Performance Excuses Debunkedcomputerenhance.com 1st of 3 in this piece

    software performance

    Interesting

  57. Our reading

    The evidence from the largest software companies says programmers should take performance more seriously than they do, not less.

    Their wordsthe logical conclusion would be that programmers need to take performance more seriously than they have been, not less!

    ↗Performance Excuses Debunkedcomputerenhance.com 2nd of 3 in this piece

    Interesting

  59. Our reading

    Performance-aware programming is a skill a working developer can learn in months rather than years.

    Their wordsLearning basic performance-aware programming skills is something a developer can do in months rather than years.

    ↗Performance Excuses Debunkedcomputerenhance.com 3rd of 3 in this piece

    Interesting
  60. 8 weeks earlier

  61. Our reading

    The programming practices taught as best practice are ruinous for performance and should not be followed.

    Their wordsThe ideas underlying the “clean” code methodology are almost all horrible for performance, and you shouldn’t do them.

    ↗"Clean" Code, Horrible Performancecomputerenhance.com 1st of 3 in this piece

    Interesting

  63. Our reading

    Giving up a decade or more of hardware performance to make programming more comfortable is not an acceptable trade.

    Their wordsIt 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 Performancecomputerenhance.com 2nd of 3 in this piece

    Interesting

  65. Our reading

    A programmer’s job is to write programs that run well on the hardware they are given.

    Their wordsOur job is to write programs that run well on the hardware that we are given.

    ↗"Clean" Code, Horrible Performancecomputerenhance.com 3rd of 3 in this piece

    Interesting
  66. 9 years earlier

  67. Our reading

    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.

    Their wordsthe landscape of educational materials out there still overwhelmingly falls into the "objectively bad" category

    ↗Semantic Compressioncaseymuratori.com 1st of 4 in this piece

    Interesting

  69. Our reading

    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.

    Their wordsLike a good compressor, I don't reuse anything until I have at least two instances of it occurring.

    ↗Semantic Compressioncaseymuratori.com 2nd of 4 in this piece

    Interesting

  71. Our reading

    Code written to be reusable before there is anything reusing it is likely to be reusable in the wrong way.

    Their wordsThis 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 Compressioncaseymuratori.com 3rd of 4 in this piece

    Interesting

  73. Our reading

    Code is procedurally oriented rather than object-oriented: objects are just constructs that emerge to let procedures be reused.

    Their wordsCode is procedurally oriented, and the "objects" are simply constructs that arise that allow procedures to be reused.

    ↗Semantic Compressioncaseymuratori.com 4th of 4 in this piece

    Interesting