I’ve started noticing articles and YouTube videos touting the benefits of branchless programming, making it sound like this is a hot new technique (or maybe a hot old technique) that everyone should be using. But it seems like it’s only really applicable to data processing applications (as opposed to general programming) and there are very few times in my career where I’ve needed to use, much less optimize, data processing code. And when I do, I use someone else’s library.

How often does branchless programming actually matter in the day to day life of an average developer?

  • Max-P@lemmy.max-p.meEnglish
    2·
    1 year ago

    I’ve never had to care about it in 16 years of coding. I’ve also seen a few absolutely horrifying code designs in the name of being branchless. Code readability is often way more important than eeking out every bit of compute out of a CPU. And it gets in a domain where architecture matters too: if you’re coding for a microprocessor or some low power embedded ARM processor, those don’t even have branch predictors so it’s a complete waste of time

    I’d say, being able to identify bottlenecks is what really matters, because it’s what will eventually lead you to the hot loop you’ll want to optimize.

    But the overwhelming majority of software is not CPU bound, it’s IO bound. And if it is CPU bound, it’s relatively rare that you can’t just add more CPUs to it.

    I do get your concern however, these interview questions are the plague and usually asked by companies with zero need for it. Personally I pass on any job interview that requires some LeetCode exercises. I know my value and my value isn’t remembering CS exercises from 10 years ago. I’ll absolutely unfuck your webserver or data breach at 3am though. Frontend, backend, Linux servers, cloud infrastructure, databases, you name it, I can handle it no problem.

    • Ethan@programming.devOPEnglish
      1·
      1 year ago

      Code readability is often way more important

      This. 100% this. The only thing more important than readability is whether it actually works. If you can’t read it, you can’t maintain it. The only exception is throw away scripts I’m only going to use a few times. My problem is that what I find readable and what the other developers find readable are not the same.

      I’d say, being able to identify bottlenecks is what really matters, because it’s what will eventually lead you to the hot loop you’ll want to optimize.

      I love Go. I can modify a program to activate the built-in profiler, or throw the code in a benchmark function and use the tool chain to profile it, then have it render a flame graph that shows me exactly where the CPU is spending its time and/or what calls are allocating. It makes it so easy (most of the time) to identify bottlenecks.