We measure the latency it takes for a CPU to send a message to another CPU via its cache coherence protocol.

By pinning two threads on two different CPU cores, we can get them to do a bunch of compare-exchange operation, and measure the latency.

How to run:

$ cargo install core-to-core-latency
$ core-to-core-latency

Data provided by Concyclics.

Data provided by Concyclics.

Data provided by Concyclics.

Data provided by zamadatix.

Data provided by zamadatix.

Data provided by SchrodingerZhu.

Data provided by Glavo.

Data provided by bizude.

This CPU has 8 performance cores, and 2 groups of 4 efficient cores. We see CPU=8 with fast access to all other cores.

Data provided by nviennot.

Data provided by Jonas Wunderlich.

Data provided by CanIGetaPR.

Data provided by Ashley Sommer.

Data provided by Felipe Lube de Bragança.

Data provided by Aditya Sharma.

We see the two efficent cores clustered together with a latency of 53ns, then two groups of 3 performance cores, with a latency of 40ns. Cross-group communication is slow at ~145ns, which is a latency typically seen in multi-socket configurations.

From an AWS c6i.metal machine.

From an AWS c5.metal machine.

From a machine provided by GTHost

From an AWS c6a.metal machine.

We can see cores arranged in 6 groups of 8 in which latency is excellent within (23ns). When data crosses groups, the latency jumps to around 110ns. Note, that the last 3 groups have a better cross-group latency than the first 3 (~90ns).

Data provided by Mathias Siegel.

We see the CPUs in 8 groups of 3, and better performance for CPUS in the group [13,24].

Data provided by Jakub Okoński

We see the CPUs in 4 groups of 4, and better performance for CPUS in the group [9,16].

Data provided by John Schoenick.

We can see two groups of 8 cores with latencies of 17ns intra-group, and 85ns inter-group.

Data provided by Scott Markwell.

We see two groups of 6 cores with latencies of 16ns intra-group and 84ns inter-group.

Data provided by George Melikov.

Data provided by Ashley Sommer.

Data provided by David Hoppenbrouwers.

We can see 2 groups of 4 cores with latencies of 24ns intra-group, and 92ns inter-group.

Data provided by r4nd0m1z3r.

From an AWS c7g.16xlarge machine.

From an AWS c6gd.metal machine.

Data provided by Kokoa van Houten.

Data provided by Kokoa van Houten.

The following shows dual-socket configuration latency where one CPU on the first socket sends a message to another CPU on the second socket. The number in parenthesis next to the latency denotes the slowdown compared to single socket.

Data provided by Concyclics.

From an AWS c6i.metal machine.

From an AWS c5.metal machine.

From a machine provided by GTHost

From an AWS c6a.metal machine.

This one is a bit odd. The single socket test for Socket 1 shows median latencies of 107ns cross-groups, but Socket 2 shows 200ns. It's 2x slower, very odd. The other platforms don't behave this way. In fact, the socket-to-socket latencies are than the core-to-core within Socket 2.

Anandtech have measured similar results on a Dual-Socket AMD EPYC 7763 and 7742.

Socket 2 does not behave similarly than Socket 1, it's twice as slow.

Data provided by Kokoa van Houten.

Data provided by Kokoa van Houten.

We measure the latency between two hyper-threads of the same core

The notebook results/results.ipynb contains the code to generate these graphs

First install Rust and gcc on linux, then:

$ cargo install core-to-core-latency
$ core-to-core-latency
Num cores: 10
Using RDTSC to measure time: false
Num round trips per samples: 1000
Num samples: 300
Showing latency=round-trip-time/2 in nanoseconds:

       0       1       2       3       4       5       6       7       8       9
  0
  1   52±6
  2   38±6    39±4
  3   39±5    39±6    38±6
  4   34±6    38±4    37±6    36±5
  5   38±5    38±6    38±6    38±6    37±6
  6   38±5    37±6    39±6    36±4    49±6    38±6
  7   36±6    39±5    39±6    37±6    35±6    36±6    38±6
  8   37±5    38±6    35±5    39±5    38±6    38±5    37±6    37±6
  9   48±6    39±6    36±6    39±6    38±6    36±6    41±6    38±6    39±6

Min  latency: 34.5ns ±6.1 cores: (4,0)
Max  latency: 52.1ns ±9.4 cores: (1,0)
Mean latency: 38.4ns

Use core-to-core-latency 5000 --csv > output.csv to instruct the program to use 5000 iterations per sample to reduce the noise, and save the results.

It can be used in the jupter notebook results/results.ipynb for rendering graphs.

Create a GitHub issue with the generated output.csv file and I'll add your results.

This software is licensed under the MIT license