3 ms·
That's not strictly true - if the GC requires all threads to pause ("stop the world") then there is no effective way to write code that isn't impacted without a
by duped 5y ago
That's not strictly true - if the GC requires all threads to pause ("stop the world") then there is no effective way to write code that isn't impacted without adding the soft real-time requirement and workarounds to every part of the program.
Essentially most GCs require you to pay for it even if you don't use it in critical sections. I'm not sure if Julia has the semantics for explicitly disabling GC during hot loops, but it is extremely difficult to do that without the dedicate hooks.
The issue is not performance - GCs are usually faster than not. It's determinism.
- cbkeller 5y agoYou can just turn off the GC with `Base.GC.enable(false)`
- duped 5y agodoes that disable it globally or just in critical sections?
- eigenspace 5y agoGlobally. Is your concern about running latency insensitive code concurrently with running latency sensitive code? For that, I'd probably just do multiprocessing and have one realtime process that only operates on preallocated or stack allocated buffers with the GC disabled, and then another separate process that does your latency insensitive stuff. I'm sure other languages are able to handle this sort of thing more elegantly in one process with tasks, but it can be made to work in julia, and there are lots of situations like robotics where you may want to leverage Julia's excellent ecosystem in a realtime system, so I just disagree with your earlier statement about julia being incompatible with the application domain, even if it's not a perfect language for it.