7 ms·

I think there is no js version implemented which accesses the bodies parameters like this: x = body.x[body_index] I expect this should be much faster than acc

I think there is no js version implemented which accesses the bodies parameters like this: x = body.x[body_index] I expect this should be much faster than accessing them like this: x = body.[body_index].x Because the latter requires pointer-from-property calculation for every single values access (which must be somehow optimised) The former just requires pointer-from-property calculation for every array (not element) involved in the nbody loops, the individual element|values are picked out by array addressing which is inherently much simpler than property access. I've used this method for nbody physics. I can modify a test to it and push to the repo.

krausest 10y ago
That would be great. Just send me a pull request!
- strainer 10y ago
  Well I got it completing and its taking about 35% longer than the 'original' method. I do expect index lookups to be faster than property lookups so believe there must be some inefficiency in my hasty refactoring. Or there might be an issue with there being only 5 bodies in the test. Im a bit puzzled. Ill send the code later in the day.
crocodileJS 10y ago
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.
      - 10y ago
pcwalton 10y ago
> Because the latter requires pointer-from-property calculation for every single values access (which must be somehow optimised) Global value numbering (GVN) should be trivially able to do this.
- strainer 10y ago
  Perhaps when things are very simple, but we can end up with thousands of objects each with dozens of optional properties. With the fields declared as arrays only each array needs a GVN.

krausest 10y ago

That would be great. Just send me a pull request!

strainer 10y ago
Well I got it completing and its taking about 35% longer than the 'original' method. I do expect index lookups to be faster than property lookups so believe there must be some inefficiency in my hasty refactoring. Or there might be an issue with there being only 5 bodies in the test. Im a bit puzzled. Ill send the code later in the day.

crocodileJS 10y ago

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.
    - 10y ago

pcwalton 10y ago

> Because the latter requires pointer-from-property calculation for every single values access (which must be somehow optimised) Global value numbering (GVN) should be trivially able to do this.

strainer 10y ago
Perhaps when things are very simple, but we can end up with thousands of objects each with dozens of optional properties. With the fields declared as arrays only each array needs a GVN.