예전에 잡다한 것들을 정리했던 empas 블로그가 있었는데, 이녀석이 자꾸 인수되면서 내 계정을 찾는 기간을 놓쳐 버렸다. ㅜ.ㅜ 현재 zum 에 있는데, 계정은 찾아줄 수 없고, 삭제는 가능하다고 한다. 그래서 조금씩 글들을 옮겨 놓으려 하고 있다.
작성일 : 2008-04-26
공유캐쉬
false sharing 에 관한 글(http://minjang.egloos.com/1094099)을 보다가 참조사이트를 따라 갔더니 multi-core system 에서 공유 캐쉬를 잘 활용하는 방법에 대한 글이였다. 그저 개인적인 호기심에 한 번 보기 시작하고 정리를 했더니 번역이 되어 버린 듯 하네.내가 정리한 내용은 그다지 충실하지 않으니 관심이 있으시면 아래 링크를 가서 보는 것이 좋을 듯 하다.
Software Techniques for Shared-Cache Multi-Core Systems
프로그램적으로 multicore processor 를 잘 사용하는 법.processor affinity
이것은 어떤 core에 어떤 thread 를 할당할 것인가에 관한 얘기다.data의 공유없이 그저 각자의 일을 하는 thread들은 (contention-only threads) cache 를 share하지 않는 core에 넣어야 하고, 어떤 data를 공유하는 thread 들(data-sharing threads) 은 cache를 share 하는 곳에 넣어야 한다.
만약 정말 밀접하게 연관되어 있는 thread 들이라면(closely tied to each other) 같은 core 안에 놓는 것이 data를 공유할 때 cache miss 가 적게 발생해 훨씬 빠르다.
cache blocking technique. (data tiling)
하나의 data set 이 있고, 이것의 size가 cache 의 size 보다 크고 이 data set을 사용하는 loop 이 있다. 이 때 A라는 작업(operation)에서 data set 을 전부 한 번씩 처리하고 나서,다시 처음부터 data set을 처음부터 건드리면서 B라는 작업을 한다면 계속해서 cache miss가 날 것이다. 이것을 줄이기 위해 일단 cache size 만큼 data를 불러서 A, B operation 을 끝내고, 그 다음 data를 불러서 다시 A, B operation 을 하는 방식을 하면 cache miss를 줄일 수 있다. 이것이 cache blocking technique의 한 방법이다.
예제 : ref. 1 의 example
Hold approach
이것은 shared L2 cache에서 shared data 를 L2 cache에 계속 업데이트 하는 것을 낭비라 생각하고 이를 필요할 때만 update를 하는 식으로 바꾸는 것을 말한다.이것을 구현하는 방법중 하나는 modified data가 shared copy에 update가 될 때까지 tracking 을 위한 private data copy를 갖고 있는 것이다.
이것의 실질적인 사용은 OpenMP* reduction clause(http://blog.empas.com/i5on9i/25398368) 를 이용하는 것이다.
예제 : ref. 1 의 example
Delayed approach
만약 Thread 0 가 사용한 data를 Thread 1 에서 사용하는 routine을 가진 program이 있다고 하자.Thread 0 은 core 0 에서 사용되고, Thread 1 은 core 1 에서 동작하고 있다.
그러면,
- Thread 0 가 data를 memory에서 L1 cache로 받아와서 data를 수정한다.
- Thread 0 가 일을 끝내고 나서 data를 건드려도 좋다고 Thread 1 한테 신호를 보낸 것이다.
- Thread 1은 L2 cache를 뒤져볼 것이다. 근데 아직 data가 L1 cache에서 L2 cache로 안넘어갔다.
- 그러면 core 1에서는 cache miss 가 발생하고나서 data가 L2 cache 로 evicted 될 것이다.
- Thread 1 이 L2 cache에서 data를 가져올 것이다.
이 과정에서 data가 L2 cache로 evicted 될 때까지 signal 을 보내는 것을 늦추는 것이다.
그러면 Thread 1 이 signal 을 받는 순간에 이미 data가 L2 cache로 넘어왔기 때문에
cache miss 가 아닌 cache hit가 될 것이다.
예제 : ref. 1 의 example
false sharing
이것은 cache-coherency protocol 로 인해 발생한다.cache는 보통 block 단위로 data를 가져오는데 이것을 cache-line이라고 한다.
우연하게 이 block 에 thread 0 에서 쓰는 data도 있고, thread 1 에서 쓰는 data도 있다면
양쪽의 L1 cache 는 서로 같은 내용의 cache-line을 가지고 있다.
이 때 한쪽에서 data를 고치게 되면 cache-line 전체가 고쳐진것으로 인식하고,
다른 한 쪽의 cache-line이 이제 쓸모없음을 알려서 cache-coherency를 유지한다.
이런 cache-coherency 때문에 공유되지 않는 data지만 같은 block 안에 묶여서
계속 cache miss가 발생한다. 이것이 false sharing 이다. 보다 자세한 내용은 "art.oriented : 정답: 다음 코드의 문제점은 false sharing" 를 보자.
댓글 없음:
댓글 쓰기