1. 21
  1. 7

    I caught a bit of this talk while it was live. I liked it a lot because it’s advice you can apply to anything you’re doing, you don’t necessarily have to be working in the videogames industry or use C/C++ or use SIMD intrinsics to trim whitespace as he does at some point, but you can still get big performance wins by not using generic tools and specializing your code for the problem at hand, instead of trying to solve a more general problem.

    One thing I find interesting about how videogame programmers talk about code is the implication that code is cheap, and that you can and you should dump it and rewrite it when the problem changes. It’s a notion that seems to go against many “best practices”, but honestly not so much; one of the definitions of what “good code” constitutes that I prefer is code that is easy to delete.

    1. 3

      By far, my favorite talk from Handmade Seattle 2021.

      1. 3

        The SIMD intrinsics don’t come out as exactly readable but I guess this is something you’d mostly do for small self-contained things like whitespace trimming. Anyone know a good resource to learn how to write that stuff? Is it possible to take advantage of that in a manner that’s not assuming everything is x86?

        The branch-free approach is something I’ve done before and often results in shorter code anyway.

        1. 2

          Anyone know a good resource to learn how to write that stuff?

          I’ve been writing small programs to use simd instructions (e.g., count lines in a buffer, rot13 a buffer) mostly by practicing: I set 30 minutes aside, I try to solve the problem by looking at the intrinsics available and putting together a solution. After 30 minutes, I stop. If I’m not done, the next day I restart from scratch; that way, I become more familiar with the functions for loading bytes into a simd register or doing comparisons, etc.

          Is it possible to take advantage of that in a manner that’s not assuming everything is x86?

          I don’t know, but I don’t think so. Also, if you are going down to that level, it seems like you’d want to use the actual instructions and not an abstraction built on top of them.

        2. 2

          I really liked this talk! Even though I basically never think about performance in my various computing endeavors, I think the talk very clearly illustrates the importance of context when making any decisions. At my job, I’ve tried to express this importance by asking contextual questions. Sometimes we end up with an essential design decision or at least uncovering a previously-unknown question.

          “Why do we need another service instead of extending an existing one?”

          “What are the actual performance benefits? Have you benchmarked?”

          “How do we explain this component to teammates?”

          “What happens if we break this invariant? Can we fail more safely?”

          “What is a good next delivery goal for this project?”

          “How long, really, do we expect this code to last?”

          I’ve found that design and implementation decisions are difficult when we proceed with ignorance, and that they are ever easier when we go in with our eyes open. I’ve been thinking recently on a salient quote:

          The goal is always to write a program that solves some problem and that can be maintained over it’s [sic] useful lifetime.

          I’d qualify the “always” part, because sometimes it’s just better to write no program at all, but I otherwise find this statement to be very true.