3 ms·
I guess the problem is usually not about 1% throughput, but about where the 1% is and how it affects the latency. You can have the 1% overhead evenly distribute
by pca006132 4y ago
I guess the problem is usually not about 1% throughput, but about where the 1% is and how it affects the latency. You can have the 1% overhead evenly distributed which is normally fine, but you can also have a latency spike for some operation (and I guess this is the case for barriers), which IMO really hurts in some cases.
- hayley-patton 4y agoBarriers are probably too small to cause latency spikes. The object logging barriers are a bit complicated, as they write an object into a thread-local log and infrequently have to get more memory for the log. But a card barrier is rather simple, and could look like SHR R_pointer, 9 AND R_pointer, <cards> MOV BYTE [R_cards + R_pointer], 0 where <cards> is one below an immediate power of two number of cards, each card covering 2^9 = 512 bytes of heap. This is roughly the write barrier in SBCL on x86-64; there isn't much of a reason to think it will cause a latency spike. On the other hand, "Barriers revisited" does mention a pathology about how cards can introduce false sharing, but that's still more of a smear than a spike.