‹ BackHN Continuity

Thread

Writing Efficient C++ Code (2013)

176 points · 161 comments · ibobev

  1. hn_submit · · focus · HN ↗
    I write in C++ almost every day but never have the need to optimize for speed. Even when you write straightforward code it's already blazingly fast.
    1. hackrmn · · focus · HN ↗
      I started writing a [CPU-only] 3-D rendering library in C++ recently, after having written the equivalent in C as a proof-of-concept and an experiment. The reason I decided to write it in C++ after C, is not only because I wanted to tap into meta-programming which is facilitated much better with C++, or that I wanted niceties like procedure overloading, but because some things with C or C++ aren't automagically optimised -- like if you want to leverage struct-of-array (SoA) memory layouts because it allows fewer SIMD (AVX in my case) instructions in the rendering pipeline. You do _not_ get that "for free" just writing a single procedure in C++, much less with C. Both languages are layout-sensitive, I mean this is in part what gives you the speed -- optimising with memory layout for cache locality etc. But you have to do it yourself. Meaning that if you need array-of-struct (AoS) or in fact don't know which path the CPU would prefer, there's no other way than roll up your sleeves and one way or another implement both.

      The kicker is, in my case I chose C++ because templates allow me to reuse most of the code in the rendering pipeline _regardless_ of whether I go for AoS or SoA layout. I leverage operator overloading to do vector by matrix multiplication which is implemented in both variants. I do have to specify the desired variant during building, but I've profiled and for Intel x86 AVX in my case SoA is something like twice as efficient because I process ("shade") 8 vertices with 4-5 instructions instead of 1 vertex at a time (still shaded with vectorisation -- just "rotated", i.e in the pipeline axis and not vertex buffer axis).

      TL;DR; C++ gives you plenty fast by default, but it's not always enough. The difference between 5 and 15 frames per second, well, makes all the difference -- our eyes are only fooled once the frames-per-second rate goes sufficiently up, anything below an acceptable threshold and it's completely different experience. You then either sacrifice resolution or level of detail etc, or decide to squeeze more from the language by helping the compiler.

      1. smallstepforman · · focus · HN ↗
        To do something like this, you really need to look at both cache locality and CPU core access patterns:

        <a href="https:&#x2F;&#x2F;youtu.be&#x2F;jsdwRf3JvZM?si=0tysoCsvaWl0R_PZ" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;jsdwRf3JvZM?si=0tysoCsvaWl0R_PZ

        40’000 NPC in game with collision avoidance, steering, on 8yo hardware.

        1. hackrmn · · focus · HN ↗
          I am sorry but what does cache locality and CPU core access pattern(s) have to do with the video you linked? Indeed it shows a lot of instances in animation, but the only technicalities it mentions are bare mention of Vulkan (which I assume implies GPU), and I am using the CPU and without any libraries.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.