Multithreading and coverage counters: disable coverage by default?

Developers
1

Coverage counters currently aren’t thread-safe but that’s easily fixed.

However, they significantly hurt performance when multithreading with large numbers of cores. For my parallel opt_merge pass doing multithreaded read-only access to RTLIL, on 20 cores I get 7.5x speedup over 1 core with (threadsafe) coverage enabled, 14.1x speedup with coverage disabled.

(With the current non-threadsafe data-racy counters, the speedup is even less than with the atomic counters, only 7x, which is a bit weird but suggests that the main cost is cache-line ownership ping-ponging between cores. The numbers might vary a lot depending on the hardware.)

Currently coverage is enabled by default on Linux and FreeBSD (and doesn’t work on other platforms). Personally I haven’t ever used its coverage data. Threading is enabled by default on most targets, and when we start using it for core passes like opt_merge most users should see significant benefits from turning off coverage. Should we disable coverage by default?

2

One alternative would be to reimplement the counters using thread-local data, but I’m not sure if the current approach using ELF sections would work and it would probably be more complicated.

3

Yikes, I never noticed we have this cooked coverage mechanism on by default. On current main there’s no performance change when I disabled it at least. I’m pretty sure it’s useless and unused. It has nothing to do with gcov or things like $cover or the linecoverage command, and I just checked that there are no actual uses of it on all of github either. If it’s convenient for you to remove it outright, go ahead