3 ms·

Fun fact, the GC really isn't an issue and instead the opposite issue was found. There had to be callbacks built to slow down the computations for the robotics

Fun fact, the GC really isn't an issue and instead the opposite issue was found. There had to be callbacks built to slow down the computations for the robotics simulations in order to get it to run at real-time because it was too fast. https://github.com/JuliaRobotics/RigidBodySim.jl/blob/34ac4352f882b5b3beb62ba2b4b90c1e57817b39/src/core.jl#L154 https://github.com/JuliaRobotics/RigidBodySim.jl/blob/34ac43... Notice that this function is purposefully sleeping the differential equation solver in order to slow it down to the exact amount to get the simulation back to real-time.

CyberDildonics 8y ago
That's a very amateurish way to solve this problem. Games typically have a main loop which will check the amount of time that has passed on every iteration of the loop. You can see how much extra time is left for that frame at the targeted frame rate, then sleep for that amount of time. Then you never have to slow down anything else, you can set a maximum amount of cycles per second and you can sleep once per cycle. The faster the CPU, the less power it should use.
- ChrisRackauckas 8y ago
  Interesting to hear. This just isn't a thing I think is ever encountered in this kind of stuff. The author's previous struggle was to get to real-time. Getting below it wasn't something they really considered. Here's a talk they gave: https://www.youtube.com/watch?v=dmWQtI3DFFo https://www.youtube.com/watch?v=dmWQtI3DFFo