Comment by pizlonator
11 days ago
It’s a concurrent GC. Latency won’t kill you
I’ll admit that if you are in the business of counting instructions then other things in Fil-C will kill you. Most of the overhead is from pointer chasing.
11 days ago
It’s a concurrent GC. Latency won’t kill you
I’ll admit that if you are in the business of counting instructions then other things in Fil-C will kill you. Most of the overhead is from pointer chasing.
"Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case?
InvisiCaps sound unbelievably amazing. Even CHERI hasn't managed to preserve pointer size.
> "Concurrent" doesn't usually mean "bounded in worst-case execution time", especially on a uniprocessor. Does it in this case?
Meh. I was in the real time GC game for a while, when I was younger. Nobody agrees on what it really means to bound the worst case. If you're a flight software engineer, it means one thing. If you're a game developer, it means something else entirely. And if you're working on the audio stack specifically, it means yet another thing (somewhere in between game and flight).
So let me put it this way, using the game-audio-flight framework:
- Games: I bound worst case execution time, just assuming a fair enough OS scheduler, even on uniprocessor.
- Audio: I bound worst case execution time if you have multiple cores.
- Flight: I don't bound worst case execution time. Your plane crashes and everyone is dead
Haha, yeah, I know.
> "Concurrent" doesn't usually mean "bounded in worst-case execution time"
Sure, though this is also true for ordinary serial code, with all the intricate interactions between the OS scheduler, different caches, filesystem, networking, etc.
Usually when people care about worst-case execution time, they are running their code on a computer without caches and either no OS or an OS with a very simple, predictable scheduler. And they never access the filesystem (if there is one) or wait on the network (if there is one) in their WCET-constrained code.
Those are the environments that John upthread was talking about when he said:
> There's tons of embedded use cases where a GC is not going to fly just from a code size perspective, let alone latency. That's mostly where I've often seen C (not C++) for new programs.
But I've seen C++ there too.
If you're worried about the code size of a GC you probably don't have a filesystem.
3 replies →
For embedded use cases, it can definitely kill you. Small microcontrollers frequently have constant IPC for a given instruction stream and you regularly see simple for loops get used for timing.
There's tricks to improve the performance of pointer chasing on modern uarchs (cfr go's Greentea GC). You want to batch the address calculation/loading, deref/load and subsequent dependent ops like marking. Reorder buffers and load-store buffers are pretty big these days, so anything that breaks the addr->load->do dependency chain is a huge win, especially if there are any near that traverse loop.