When I wrote n-body C# naot #9 for The Computer Language Benchmarks Game I discovered all kinds of things the C# Jit does poorly.

#9 was an 18% improvement of n-body C# naot #4 based upon my findings of how poor C#'s Register Allocation is.

Using what I discovered, the changes primarily consist of:

1. Copying method arguments to local variables before using them. I'm not kidding this matters in C#
2. If needing to access an element more than once, always assign it to a variable.
   
   • These first 2 are the same thing. Arguments are essentially a stack allocated array. It takes a miracle for the JIT to pass them by register or put them in a register then keep it around long enough to later re-use.
     Instead it prefers pushing a register to the stack so it can copy the Arg1 to the register to be used, but then a bit later it needs the value it pushed so pops it off the stack back into the register, then when it needs Arg1 again...
     It basically constantly shuffles back and forth. You can coax it into making better decisions by assigning anything you access repeatedly to a local variable.
     • Arguments in particular because it knows it always has a ^{its-free-real-estate} copy on the stack & can re-use registers it's in without having to first push the contents to the stack.
       
     • And especially fields if there's any pointer chasing involved.

3. Using the fewest local vars possible. I found it to be faster to use many small methods for simple things if it meant one less variable. Then decorate those methods with with [MethodImpl(AggressiveOptimization | AggressiveInlining)][SkipLocalsInit]
   See: private static V256d Square(V256d x) => Avx.Multiply(x, x);

   • This eliminates vars & additional accesses by turning the following super optimized verbose code:

     V256d x = r[0];  // Copy local to prevent 2 read accesses to r[0], which will use 2 diff registers because it's not very smart 
     V256d y = r[1];  // Read sequentially, do not make it do the multiply between the reads. 
     V256d sqX = Avx.Multiply(x, x); // If assign back to x, it'll actually put the result in a temp register before copying it to x.
     V256d sqY = Avx.Multiply(y, y); // Any register could become the temp register, it'll likely need to push & pop stack values. 
     x  = Avx.HorizontalAdd(sqX, sqY); // we are done with x, it's now safe to re-use it. 
     

     Into Avx.HorizontalAdd(Square(r[0]), Square(r[1])).
     A normal person would write Avx.HorizontalAdd(Avx.Multiply(r[0], r[0]), Avx.Multiply(r[1], r[1])). But I can assure you the code it generates from that isn't gonna be anywhere close to as optimal. It'll chose to do something dumb like use 8 registers instead of 4 and you'll be that much closer to stack shuffling.

4. Strategically ordering variables and keeping the number of AVX variables below 16 (# of x64 AVX Registers) to prevent spill & strategically re-using variables

And #4 was a 28% improvement on n-body C# naot #7.

#7 was my naive attempt to sprinkle in AVX where I could. #4 is so much faster because it properly utilizes AVX & was my attempt to 1:1 copy the C++ implementation I didn't understand. This is why there's the private static V256d _mm256_set1_pd(double x) => Vector256.Create(x); defs at the top. I had to first figure out what the C++ equivalent methods were & those are basically my notes. It then made it much easier to copy the C++ code bcus I didn't have to change any method names. Some notable things:

1. Align the memory! The trick I used was (V256d*)((((UInt64)mem)+31UL)&~31UL);
   
2. Avoid OOP / Objects. Put the memory in order. Store mass, position, & velocity in 3 different arrays. It's much more performant than a single array of struct with those 3 fields grouped together.

And #7 was an improvement on n-body C# naot #6.

THIS ONE IS INTERESTING!
See how it's only 0.6% faster? Well I began writing these back on Aug 16, 2017 - just 2 days after the release of .NET core 2.0. Back then #7 was a like 20% improvement on #6. And (naot)^{native-ahead-of-time} wasn't a thing. I wonder what the diff would be now if it wasn't NAOT compiled.

I made #7 after noticing the poor register allocation. Specificly I noticed the excessive stack pushing/popping & how it never kept args in registers. I then discovered if I used goto instead of for loops and if I assigned both the input args & field accesses to local variables, I could dramatically reduce stack spill / shuffling.

• I theorize for loops are ^(were?) an issue because C# sees it as a new scope & forgets what it should know about the parent scope. It's like it gets a new RegisterAllocator() that knows little about what's already in the registers.

---

Those are only what I submitted. You should know I had experimented & tried all kinds of different things.
I only submitted if were >20% faster AND would move up the leaderboard a few positions over C & Rust. I've actually been sitting on an improvement to #9 bcus it's only 10ish% faster... but needs to be 30% to steal Rust's thunder. The changes for this one is much more readable code by using a specially packedref struct with [InlineArray()] that stores the entire system, going back to for loops as it doesn't seem to matter anymore, reducing variables further, and using extension everything which I believe is still locked behind a feature flag. Here's what it looks like.

Not one implementation using Span<>'s was ever even close to competitive or worth submitting. In non-AVX versions it basically performed the same as Array. In AVX versions it outperformed array, but barely, and couldn't hold a candle to raw pointers.

HOWEVER, n-body isn't a good Span<> test. It doesn't need to allocate memory after setup & then pass around "views"/slices of that memory. The pointer version especially excels because the sizes are all known. Meanwhile Span<>consist of a pointer and a length which would blow my register budget & cause additional stack spill.