This looks nice. But, ideas are more important than code. So to be honest, I would enjoy a description of how this works more than actually playing with this program.
From a quick look at the code it seems to be coded as a fairly standard particle system. Modern processors are fast, if you have a million particles, a 2GHz processor, and do 20 simulation steps per second you can spend 100 clock cycles per particle on simulating it. On modern processors 100 clock cycles usually translates to over 100 instructions.
Of course the ~100 clock cycles latency for fetching from main memory has to be avoided, so you code in a language like c++ (like this project) and pack your data in big arrays in the order it's accessed in. Then processor caches and prefetching do the magic.
Particle interactions that usually imply quadratic runtime can be made fast by mapping particle positions to a grid and either looking up neighbouring particles in the grid or calculating large scale effects directly with the grid.
Personally, I think for this project the working whole and the value it provides as a fun educational tool is a bigger deal than architectural or development ideas that went into it (but I'm happy to be proven wrong)
Of course the ~100 clock cycles latency for fetching from main memory has to be avoided, so you code in a language like c++ (like this project) and pack your data in big arrays in the order it's accessed in. Then processor caches and prefetching do the magic.
Particle interactions that usually imply quadratic runtime can be made fast by mapping particle positions to a grid and either looking up neighbouring particles in the grid or calculating large scale effects directly with the grid.
Personally, I think for this project the working whole and the value it provides as a fun educational tool is a bigger deal than architectural or development ideas that went into it (but I'm happy to be proven wrong)