Figure 8.16. Communication Hot-Spot Issue

A communication hot-spot issue is reported when Freja finds two locations in different threads, or rather in threads bound to different caches, that communicate a lot. But, unlike the communication utilization issue described in Section 8.1.3, “Communication Utilization”, this issue indicates that these locations use the communicated cache lines efficiently.

There is, however, always a cost to communication between caches, so you should always try to minimize the communication. It might be possible to address this by using techniques similar to blocking, to avoid communicating data ever so often. Sometimes, it might make sense to critically evaluate if the producer and consumer needs to be in different threads.

In many cases communication has hidden costs, in that additional high level synchronization, or locking, is needed to ensure proper protocol between the communicating threads. Synchronization inevitably leads to serialization of the execution of the threads, which can be a limiting factor for performance. Whenever there is communication, ensure that proper synchronization is used, but that locks are held as short a time as possible.

Finally, carefully binding the two threads to cores sharing a cache can make a difference, since the data will not have to migrate at all as both the producer and the consumer share that cache. This also depends on the cache size and the footprint of each thread sharing this cache. Freja can help evaluate different bindings of threads to cores, to help you make an informed decision.

The communication hot-spot issue has these sections: