[HN Gopher] I made Zig compute 33M satellite positions in 3 seconds
       ___________________________________________________________________
        
       I made Zig compute 33M satellite positions in 3 seconds
        
       Author : signa11
       Score  : 141 points
       Date   : 2026-01-21 09:51 UTC (13 hours ago)
        
 (HTM) web link (atempleton.bearblog.dev)
 (TXT) w3m dump (atempleton.bearblog.dev)
        
       | philipallstar wrote:
       | I've never seen SIMD code before, and this is quite a nice little
       | intro into that and Zig.
        
       | tylermw wrote:
       | Nice results! SIMD can be a pain, good to know Zig makes it easy.
       | 
       | However, note that the plot under "Native SIMD Throughput
       | Comparison" is extremely misleading: for an accurate proportional
       | comparison between bar charts, you should start the y-axis at
       | zero. The way the data are presented makes it look like a 10-100x
       | gain, rather than the actual 2x improvement.
        
         | voidUpdate wrote:
         | I was going to comment the same. I saw the huge difference and
         | went "wow", then read that it was a 2x improvement and had to
         | check the axes properly, thinking "slightly less wow". It
         | reminds me of that barchart of women's average heights in
         | different countries that starts at 5 feet
         | https://preview.redd.it/dohqa8l94kb41.png?auto=webp&s=865180...
        
           | apitman wrote:
           | Starting the axis at anything other than 0 for a length
           | comparison is hilarious.
        
         | tylermw wrote:
         | Looks like the author fixed the graph!
        
       | dfajgljsldkjag wrote:
       | It is funny how we often assume we need a graphics card for these
       | kinds of calculations when a standard processor is actually
       | plenty fast. The specific changes to the memory layout seemed to
       | make the biggest difference here by allowing the hardware to
       | actually use its vector capabilities.
        
         | Agingcoder wrote:
         | These days a single machine with lots of ram and cores will
         | handle almost everything you throw at it, barring specific
         | compute intensive / memory bound scenarios ( current AI, gaming
         | etc ).
        
         | JohnLeitch wrote:
         | At risk of being called out for my ignorance (I am still new to
         | GPU development and have only limited experience with CUDA), it
         | seems to come down to how appropriate the execution model is to
         | the work e.g. SIMT vs SIMD here.
        
       | androiddrew wrote:
       | You tell that language what to do!
        
       | exitb wrote:
       | Is that solving the right problem? The algorithm can give
       | reasonably accurate positions at arbitrary points in future, but
       | you don't need to run it over and over if you need positions
       | every second. You can generate keyframes and interpolate the
       | positions between, as the short term orbital movements are rather
       | trivial.
        
         | visviva wrote:
         | Totally agree. Cool little project, but I cannot think of one
         | use case where this is needed.
         | 
         | > But "fine" starts to feel slow when you need dense time
         | resolution. Generating a month of ephemeris data at one-second
         | intervals is 2.6 million propagations per satellite.
         | 
         | Ok, except SGP4 loses its accuracy over WAY shorter time frames
         | than a month (think hours/days)
         | 
         | > Pass prediction over a ground station network might need sub-
         | second precision across weeks.
         | 
         | a) sub-second ephemeris for antenna pointing is crazy overkill,
         | and b) same comment about accuracy as above.
        
       | ginko wrote:
       | There's one example given where either the result of a simple or
       | complex calculation is picked depending on eccentricity
       | mentioning it's faster to just always calculate both and picking
       | with a mask.
       | 
       | If you calculate both, wouldn't it be even faster to just always
       | do the complex calculation? (presumably that's more precise?)
        
         | dnautics wrote:
         | I wonder if there is more fp drift from extra math that makes
         | it LESS accurate in the case where the simple equation
         | suffices? I'm impressed that satellites even have
         | eccentricities so close to 1.0 that this makes sense, but I
         | guess from, generically, an orbital planning perspective this
         | make sense.
        
         | magicalist wrote:
         | > _If you calculate both, wouldn 't it be even faster to just
         | always do the complex calculation? (presumably that's more
         | precise?)_
         | 
         | The naming does imply that, but maybe they are simple vs
         | complex, but also they're calculating different things? Seems
         | like a stretch though.
         | 
         | Also the paragraph covering that part doesn't make much sense
         | to me:
         | 
         | > _This felt wasteful at first. Why compute both paths? But
         | modern CPUs are so fast at arithmetic that computing both and
         | selecting is often faster than branch misprediction. Plus, for
         | SGP4, most satellites take the same path anyway, so we 're
         | rarely doing truly "wasted" work._
         | 
         | I'm always skeptical of claims about branch misprediction
         | penalties without actual benchmarking (branch prediction is
         | often very good!), and it also seems potentially undermined by
         | the next sentence that "most satellites take the same path
         | anyway", ie easily predictable.
         | 
         | But I don't understand at all what it means that _because_ most
         | satellites take the same path, the SIMD code is rarely doing
         | wasted work, since the masking seems to be wasting part of the
         | work by construction? (you could maybe handwave at pipelining
         | or speculative execution making it irrelevant or wasted
         | regardless, but no sign of those arguments).
         | 
         | The library seems good and always extremely nice when people
         | produce write ups like this, but it might just be they're out
         | over their skis when it comes to what was actually important
         | about their optimizations.
        
       | lbeckman314 wrote:
       | Beautiful visualization at https://attron.github.io/astroz-demo!
       | (~160 MB transfer)
       | 
       | My (very amateur) belief is that we're in a quiet golden age of
       | cool space viz/tools, for example:
       | 
       | - https://www.asterank.com/3d
       | 
       | - https://dmytry.github.io/space/
       | 
       | - https://www.tng-project.org/explore/3d
       | 
       | - https://github.com/da-luce/astroterm
       | 
       | - https://ssd.jpl.nasa.gov/tools
       | 
       | Feels like the halcyon techno-optimism from TOS + TNG!
        
       | notthemessiah wrote:
       | This compares it to Python and Rust implementations, I wonder how
       | it compares to Julia's SatelliteToolbox.jl? Julia also compiles
       | to LLVM and has macros for explicit SIMD.
       | 
       | https://github.com/JuliaSpace/SatelliteToolbox.jl
        
       | ww520 wrote:
       | Nice to have a huge speed up. Kudos for applying the right tools
       | and right approaches to get it done. I especially like your
       | explanation of how to utilize SIMD in Zig. Learned something
       | today.
        
       ___________________________________________________________________
       (page generated 2026-01-21 23:01 UTC)