Orrery
A GPU-accelerated N-body gravitational simulator
Loading...
Searching...
No Matches
particle_data.hpp File Reference

The particle store: one contiguous array per component. More...

#include <span>
#include <vector>
#include "orrery/core/aligned_allocator.hpp"
#include "orrery/core/types.hpp"
#include "orrery/core/vec3.hpp"
#include "orrery/core/vec3_span.hpp"

Go to the source code of this file.

Classes

class  orrery::core::ParticleData
 Storage for a set of point masses in structure-of-arrays layout. More...

Detailed Description

The particle store: one contiguous array per component.

This is the layout decision the rest of the project is built on, and it is made for bandwidth rather than for tidiness. The direct force kernel reads positions and masses and writes accelerations. It never reads velocities.

Held as an array of particle structs, a position, a velocity, an acceleration and a mass occupy 80 bytes in double precision, so a 64-byte cache line carries fewer than one particle and most of every line fetched is velocity and acceleration data the kernel does not use. Held as separate component arrays, every byte of every line the kernel touches is a coordinate or a mass it is about to multiply. On a machine where the binding constraint is roughly 135 GB/s of memory bandwidth shared with the integrated GPU, that is the difference between a kernel that is limited by arithmetic and one that is limited by waiting.

Separating the components rather than only the quantities buys the second half of the argument: the x coordinates of consecutive particles are adjacent, so a vector load takes eight of them with one instruction. An array of Vec3 would need a strided gather instead. ADR-0004 records both choices and what they cost.