I went through the GC docs, and how they can be used to enable "soft" realtime. In there it says:
"Tests show that a 2ms max pause time will be met in almost all cases on modern CPUs unless the cycle collector is triggered"
Unfortunately most of the work we do is "hard" realtime (compared to that). Everything we do must be done in less than 1 ms. We can still use nim for pre or post processing or for tasks that are not so time sensitive, but it seems we could not use it for our main tasks unless we disabled the GC. Is that feasible? Is there a known, usable subset of the language and standard library that works with the GC disabled?
I think a 1ms pause is achievable with no sweating, and I heard that it works with 0.5ms too. It mostly depends on the amount of garbage you produce per collection run. You need to try it. The cycle collector IS a problem if you produce cycles, but depending on your use cases, you can break cycles via ptr. (I do know how to create a hard realtime GC, so eventually things will improve.)
There is also the --gc:none switch and the compiler tells you when you use code that produces garbage, but it's certainly a limiting and so my advice is to not use it. The --gc:none language subset is not worse than C or C++ though. (In my completely biased opinion.)
What do you mean by "achievable"? Do you mean by using the GC functions to control where and how the GC runs or do you mean by improving nim's GC?
It seems that the cycle collector is the biggest unknown (in terms of how long it can take to run). Is that correct?
I'm very happy to read that you are thinking about hard realtime garbage collection. Can you share some specifics in terms of the kind of performance that could be expected from such a GC? A lot of people believe that GC and hard realtime are incompatible...
Would what you have in mind fit an scenario like ours?:
We measure the time it takes to do our processing in microseconds. Anything that takes longer than ~25 us is not negligible. We get triggered by a HW interrupt (a "doorbell") every ms (as we say, every frame). We need to do a bunch of work during that frame, i.e. before the next doorbell arrives. Because there are multiple threads in the system that share resources and use mutexes to avoid contention my guess is that the GC would need to wait until the very end of the frame to run. Then it should only run until the next doorbell arrives and no longer.
Does that scenario sound realistic for a GC?
What do you mean by "achievable"? Do you mean by using the GC functions to control where and how the GC runs or do you mean by improving nim's GC?
By using the procs described here: http://nim-lang.org/gc.html
It seems that the cycle collector is the biggest unknown (in terms of how long it can take to run). Is that correct?
Yes.
I'm very happy to read that you are thinking about hard realtime garbage collection. Can you share some specifics in terms of the kind of performance that could be expected from such a GC? A lot of people believe that GC and hard realtime are incompatible...
Yes I can, but I won't. Sorry.
Does that scenario sound realistic for a GC?
The current GC has been designed for this scenario. ;-)