8 ms·

> The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong? No.

> The blog mentions that Julia is supposed to be a general purpose language, and not a language built specifically for scientific computing. Is that wrong? No. Julia is a general purpose language that has so far been mainly focused on scientific and mathematical programming. It's design is probably least friendly to the real-time programming domain (GC based) but it can apparently be used there as well: http://www.juliarobotics.org/ http://www.juliarobotics.org/ I see an extremely bright future ahead for Julia!

ChrisRackauckas 8y ago
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

ChrisRackauckas 8y ago

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