On Sunday, 29 December 2013 at 18:29:52 UTC, jerro wrote:
You can do that in D too. core.thread.Fiber is implemented in D
(with a
bit of inline assembly), without any special language support.
Yes, coroutines was a bad example, you probably can do that in
many stack-based languages. My point was more that the
transparency of the simple runtime of C is such that you can
easily understand the consequences of such tricks. And the
advantage of C(++) is that you can do focused low-level
fine-tuning one compilation unit while using a more standard
feature set on the rest of your code, because the part of the
runtime you have to consider is quite simple.
The GC trash cashes when it kicks in.
It can only kick in on allocation. In parts of your code where
latency is
crucial, just avoid allocating from the garbage collected heap.
I understand that. In a real-time system you might enter such
sections of your code maybe 120 times per second in a different
thread which might be killed by the OS if it doesn't complete on
time.
It is probably feasible to create a real-time friendly garbage
collector that can cooperate with realtime threads, but it isn't
trivial. To get good cache coherency all cores have to
"cooperate" on what memory areas they write/read to when you
enter timing critical code sections. GC jumps all over memory
real fast touching cacheline after cacheline basically
invalidating the cache (the effect depends on the
GC/application/cpu/memorybus).
