캐시 라인 거짓 공유 계산기

두 스레드가 서로 다른 변수를 쓰는데 그 변수들이 같은 캐시 라인에 있어서 생기는 성능 저하입니다. 캐시는 바이트 하나씩이 아니라 보통 64바이트인 줄 단위로 오갑니다. 한 코어가 어떤 변수를 쓰면 그 줄 전체가 다른 코어의 캐시에서 무효가 되므로, 자료 경합이 하나도 없는데도 서로의 캐시를 계속 무효화하게 됩니다.

원인이 코드가 아니라 메모리 배치에 있기 때문입니다. 락도 없고 공유 변수도 없는데 스레드를 늘릴수록 느려진다면 이것을 의심해야 합니다. 필드의 오프셋과 캐시 줄 크기를 함께 놓고 봐야 보입니다.

스레드마다 쓰는 변수를 각각 다른 캐시 라인에 놓으면 됩니다. 변수 사이에 줄 크기만큼 패딩을 넣거나 줄 크기로 정렬합니다. C++이라면 alignas(64), Java라면 @Contended, C라면 구조체에 더미 배열을 끼워 넣는 방법이 흔합니다.

메모리를 크게 씁니다. 8바이트 카운터 여덟 개가 64바이트에서 512바이트가 되어 여덟 배입니다. 캐시에 들어가는 양이 줄어 다른 곳에서 느려질 수 있으므로, 정말 자주 쓰는 필드만 갈라놓는 것이 낫습니다. 이 계산기는 그 비용을 함께 냅니다.

x86과 대부분의 ARM은 64바이트지만 애플 M 계열은 128바이트입니다. 이 값을 잘못 잡으면 64바이트로 갈라놓았다고 믿은 변수가 128바이트 기기에서는 여전히 같은 줄에 있습니다. 여러 기기에서 돌 코드라면 큰 쪽에 맞추는 편이 안전합니다.

물음이 반대입니다. 그쪽은 「구조체가 왜 필드 크기의 합보다 큰가」를 보고 필드 순서를 바꿔 크기를 줄이는 도구입니다. 이쪽은 같은 오프셋 계산 위에서 「어느 필드들이 같은 캐시 라인에 들어가는가」를 보고, 오히려 패딩을 넣어 줄을 갈라놓습니다.

그 필드 하나만 읽거나 써도 캐시 라인 두 개를 건드리게 됩니다. 다른 필드와 다투지 않더라도 캐시 미스가 두 배가 될 수 있습니다. 정렬을 맞추면 사라집니다.

알 수 없습니다. 실제 비용은 쓰기 빈도, 코어 수, 소켓 구성, 캐시 일관성 프로토콜에 달려 있어 메모리 배치만으로는 정해지지 않습니다. 이 계산기가 내는 것은 거짓 공유가 일어날 수 있는 자리이며, 실제로 그것이 병목인지는 프로파일러로 확인해야 합니다.

전송되지 않습니다. 계산은 모두 브라우저 안에서 이루어지고 넣은 값은 이 기기에만 남습니다.