[HN Gopher] Bytes before FLOPS: your algorithm is (mostly) fine,...
       ___________________________________________________________________
        
       Bytes before FLOPS: your algorithm is (mostly) fine, your data
       isn't
        
       Author : bofersen
       Score  : 27 points
       Date   : 2025-11-23 15:47 UTC (1 days ago)
        
 (HTM) web link (www.bitsdraumar.is)
 (TXT) w3m dump (www.bitsdraumar.is)
        
       | jmole wrote:
       | > worst case scenario being the flat profile where program time
       | is roughly evenly distributed
       | 
       | It sounds like the "worst case" here is that the program is
       | already optimized.
        
         | bofersen wrote:
         | Author here, kinda sorta. I should've been a bit more specific
         | than that. You can have a profile showing a function taking up
         | 99% of the time, but when you dive into it, there's no clear
         | bottleneck. But just because there's no bottleneck, that
         | doesn't mean it's optimized; vice versa-a well-optimized
         | program can have a bottleneck that's already been cycle-
         | squeezed to hell and back.
         | 
         | What I wanted to say was that a spiky profile provides a clear
         | path to optimizing a piece of code, whereas a flat profile
         | usually means there are more fundamental issues (inefficient
         | memory management, pointer chasing all over the place,
         | convoluted object system, etc.).
        
           | saghm wrote:
           | It sounds like a flat profile essentially is a local optimum,
           | compared to cases where there's a path "upwards" along a hill
           | to some place more optimal that doesn't require completely
           | changing your strategy.
        
             | bofersen wrote:
             | That's actually a good observation, yeah. It's often the
             | case that you dig deeper and deeper and find some
             | incomprehensible spaghetti and just say "fuck it, I'll just
             | do what I can here, should be enough".
        
       | colonCapitalDee wrote:
       | Great article. Can confirm, writing performance focused C# is
       | fun. It's great having the convenience of async, LINQ, and GC for
       | writing non-hot path "control plane" code, then pulling out
       | Vector<T>, Span<T>, and so on for the hot path.
       | 
       | One question, how portable are performance benefits from tweaks
       | to memory alignment? Is this something where going beyond rough
       | heuristics (sequential access = good, order of magnitude cache
       | sizes, etc) requires knowing exactly what platform you're
       | targeting?
        
         | bofersen wrote:
         | Author here. First of all, thanks for the compliment! It's
         | tough to get myself to write these days, so any motivation is
         | appreciated.
         | 
         | And yes, once all the usual tricks have been exhausted, the
         | nest step is looking at the cache/cache line sizes of the exact
         | CPU you're targeting and dividing the workload into units that
         | fit inside the (lowest level possible) cache, so it's always
         | hot. And if you're into this stuff, then you're probably aware
         | of cache-oblivious algorithms[0] as well :)
         | 
         | Personally, I almost never had the need to go too far into
         | platform-specific code (except SIMD, of course), doing all the
         | stuff in the post is 99% of the way there.
         | 
         | And yeah, C# is criminally underrated, I might write a post
         | comparing high-perf code in C++ and C# in the future.
         | 
         | [0]: https://en.wikipedia.org/wiki/Cache-oblivious_algorithm
        
       ___________________________________________________________________
       (page generated 2025-11-24 23:00 UTC)