4 ms·

You must mean: x = bodies_x[body_index] versus x = bodies[body_index].x The "issue" with the nbody benchmark from the benchmarks game is that there's only f

You must mean: x = bodies_x[body_index] versus x = bodies[body_index].x The "issue" with the nbody benchmark from the benchmarks game is that there's only four bodies, making this SOA-style approach have little payoff. It would be great if you could do such a test, but with a significantly larger amount of bodies.

strainer 10y ago
I do mean body.x[body_index], body.y[body_index], etc as: body={ x:[] ,y:[] ,z:[] ,vx:[] ,vy:[] ,vz:[] ,mass:[] } I find this is running 20% faster than the fastest on my chrome browser (an old version) but is slightly slower on firefox, but catches up a bit with 11 bodies. I expect it could run faster yet by crunching the code up more and maybe removing objects altogether, but i made few changes as possible just to compare the difference in addressing. There is also function "offsetMomentum" which tweaks the suns movement according to momentum of the planets, it seems very extraneous to me, gravitational influence should surely be sufficient in itself regarding conservation of momentum. I suspect that function is more likely a catch for large errors which can result from point grav bodies getting to close to each other.
- wyldfire 10y ago
  SoA vs AoS, see also [1] [2]. [1] https://software.intel.com/sites/default/files/article/392271/aos-to-soa-optimizations-using-iterative-closest-point-mini-app.pdf https://software.intel.com/sites/default/files/article/39227... [2] https://en.wikipedia.org/wiki/AOS_and_SOA https://en.wikipedia.org/wiki/AOS_and_SOA
  - strainer 10y ago
    Thanks. I note a different aspect of SoA is when different functions or loops involve only a subset of the feilds, only the arrays of the involved fields are fetched. With AoS the feilds are scrunched in memory next to each other byRecord. That could benefit algorithms which only touch some of the records, however every record usually needs accessed to see whether its involved or not - the 'involving feild' would need stored separately for AoS to have any benefit.
- gjjrfcbugxbhf 10y ago
  Floating point errors accumulate quite quickly when dt is small it could be a smoothing function.
  - strainer 10y ago
    Forgive me a boast about a nbody simulation ive been developing: I got the details 60 planets and moons etc. from Nasas JPL server and put them into it. Running at a timestep of 30 minutes or hours (virtual time) for a year, the Earth ends up within a moons orbit of where JPL says its supposed to go. I think the innaccuracy is due to limitation of javascripts 64bit float (rather than, possible relativistic effect). Not sure yet, Solar system scales are so huge. When dt is too large and bodies get too close, they get super-attracted to each other in one step, and by the time of the next step, they have travelled too far to get slowed again, this is where I see major errors can occur. Its necessary to put a throttle in the force calculation, or to reduce dt to deal with that 'near missing'. Or to substep but that seems to require excessive adjustments.
    - gjjrfcbugxbhf 10y ago
      Nice. Agreed on errors with big dt. For me it is usually when shortening the time step to try to minimize for these that floating point errors start to come in. Now chuck in some velocity dependent forces and start screaming (that's what I've found with physical simulations anyway).
      - strainer 10y ago
        One trick which improves stability heaps is 'tempering' the data to fit the dt. Weve got the verlet integration thing where they say the velocities should be half a step behind before updating forces. I find they should also be reduced a little as objects are cutting through the analog curve of their orbits in the timestep - as a hypotenuse instead of an arc. When I tempered the data like this orbits were all much stabilised. Its required for objects if they are added to the model later too. To have their precise velocities measured while tempered they also need 'de-tempered' to tell where they are going precisely. Just calculate their acceleration move them half step and adjust for ratio of hypot/curve. "velocity dependent forces" I have been wondering how to implement a sort of quasi-electromagnetic force without the big expense of maintaining a magnetic field. I find the electro-magnetic force mind blowing compared to newtonian gravity. Like charges seem to be able to attract when travelling together, this would seem to produce patterns and structure more readily than gravitation.

strainer 10y ago

I do mean body.x[body_index], body.y[body_index], etc as: body={ x:[] ,y:[] ,z:[] ,vx:[] ,vy:[] ,vz:[] ,mass:[] } I find this is running 20% faster than the fastest on my chrome browser (an old version) but is slightly slower on firefox, but catches up a bit with 11 bodies. I expect it could run faster yet by crunching the code up more and maybe removing objects altogether, but i made few changes as possible just to compare the difference in addressing. There is also function "offsetMomentum" which tweaks the suns movement according to momentum of the planets, it seems very extraneous to me, gravitational influence should surely be sufficient in itself regarding conservation of momentum. I suspect that function is more likely a catch for large errors which can result from point grav bodies getting to close to each other.

wyldfire 10y ago
SoA vs AoS, see also [1] [2]. [1] https://software.intel.com/sites/default/files/article/392271/aos-to-soa-optimizations-using-iterative-closest-point-mini-app.pdf https://software.intel.com/sites/default/files/article/39227... [2] https://en.wikipedia.org/wiki/AOS_and_SOA https://en.wikipedia.org/wiki/AOS_and_SOA
- strainer 10y ago
  Thanks. I note a different aspect of SoA is when different functions or loops involve only a subset of the feilds, only the arrays of the involved fields are fetched. With AoS the feilds are scrunched in memory next to each other byRecord. That could benefit algorithms which only touch some of the records, however every record usually needs accessed to see whether its involved or not - the 'involving feild' would need stored separately for AoS to have any benefit.
gjjrfcbugxbhf 10y ago
Floating point errors accumulate quite quickly when dt is small it could be a smoothing function.
- strainer 10y ago
  Forgive me a boast about a nbody simulation ive been developing: I got the details 60 planets and moons etc. from Nasas JPL server and put them into it. Running at a timestep of 30 minutes or hours (virtual time) for a year, the Earth ends up within a moons orbit of where JPL says its supposed to go. I think the innaccuracy is due to limitation of javascripts 64bit float (rather than, possible relativistic effect). Not sure yet, Solar system scales are so huge. When dt is too large and bodies get too close, they get super-attracted to each other in one step, and by the time of the next step, they have travelled too far to get slowed again, this is where I see major errors can occur. Its necessary to put a throttle in the force calculation, or to reduce dt to deal with that 'near missing'. Or to substep but that seems to require excessive adjustments.
  - gjjrfcbugxbhf 10y ago
    Nice. Agreed on errors with big dt. For me it is usually when shortening the time step to try to minimize for these that floating point errors start to come in. Now chuck in some velocity dependent forces and start screaming (that's what I've found with physical simulations anyway).
    - strainer 10y ago
      One trick which improves stability heaps is 'tempering' the data to fit the dt. Weve got the verlet integration thing where they say the velocities should be half a step behind before updating forces. I find they should also be reduced a little as objects are cutting through the analog curve of their orbits in the timestep - as a hypotenuse instead of an arc. When I tempered the data like this orbits were all much stabilised. Its required for objects if they are added to the model later too. To have their precise velocities measured while tempered they also need 'de-tempered' to tell where they are going precisely. Just calculate their acceleration move them half step and adjust for ratio of hypot/curve. "velocity dependent forces" I have been wondering how to implement a sort of quasi-electromagnetic force without the big expense of maintaining a magnetic field. I find the electro-magnetic force mind blowing compared to newtonian gravity. Like charges seem to be able to attract when travelling together, this would seem to produce patterns and structure more readily than gravitation.