4 ms·
The more interesting part is probably that Gil Tene, one of the authors of C4 makes some good comments on it.
by nulltype 12y ago
The more interesting part is probably that Gil Tene, one of the authors of C4 makes some good comments on it.
- tomp 12y agoAlthough he's technically correct, I think he's missing the point. > Neither the pauseless algorithm, nor more recent [generational] C4 algorithm impose any multi-core related performance overheads compared to the most efficient collectors out there. There are no added cross-thread synchronization of any kind compared to stop-the-world algorithms. In fact, the whole point of a concurrent algorithm like C4 is to dramatically reduce GC-related synchronization overhead [stop-the-world pauses are dramatic synchronization points between GC and mutator threads]. The main overhead of a concurrent, compacting collector is the need for read barrier. You simply cannot move data while the program is running without having a way of redirecting the read requests to the latest memory location. It's true that it's technically not multi-core related overhead (instead, it's a multi-threading related overhead), but the point is moot, since with a single core, you don't need multiple threads (in a managed language, you can simply use fibres (user-space threads), like Go or Haskell do). The only reason to use a multi-threaded (concurrent) GC is to support multiple cores.
- nulltype 12y agoI don't know enough about GC to argue about it, but the way I read his response (including the next paragraph which is not about multicore) he seems to claim that there is not a severe performance penalty for a C4 style collector, contrary to the email from Ian Lance Taylor, so I'm not sure he missed the point. He also has a graph showing supposedly how much it's not a severe performance penalty. He also has like 5 more responses, not just that one.