IT's 잡탕찌개 블로그

메모리 거짓공유라는 용어가 있다. [MemoryFalseSharing]

인터넷에서는 거의다 메모리 거짓공유라고 부르는데 해당 용어에 대해서 알아본후에

개인적으로는 잘못된 메모리공유가 좀더 의미가 명확한 것 같다.

MemoryFalseSharing이란 무엇일까?

우선 이에 대해서 설명하기 전에 메모리 캐싱에 대해서 간략하게 알아보려고한다.

컴퓨터는 특정 데이터를 참조할때 훑어보는 순서가 있다.

바로 메모리들의 계층구조에 의한 순서인데 레지스터-캐시-메모리-하드디스크 순이다.

위의 순서대로 읽는 속도가 빠른것은 검색해보시면 바로 알수있으니 생략한다.

컴퓨터는 특정 데이터를 찾았다면 아래와 같은 가정을 통해 효율을 높이도록 되어 있다.

1. 현재 읽은 데이터는 다시 읽힐 확률이 높다.

2. 현재읽은 데이터 주변의 경우 빠른시일내에 참조될 확률이 높다.

아는게 적어서 개념적으로 간단하게 살펴보겠다.

위 코드에서 변수 i의 경우가 1번에 해당한다고 보면 된다. i의 경우 반복문 횟수만큼의 접근이 필요하기 때문에 캐시를 해두는 것이 성능에 좋을 것이다.

그리고 그 밑의 sum의 경우 arr에 대해서 연속적으로 참조를 하고 있다.

배열의 경우 메모리상에서 연속적으로 할당되어 있기 때문에 처음으로 참조한곳외에도 주변지역에 대해서 참조하게 되는 경우이다.

간단하게나마 예를 들어서 설명해봤는데 사실 능력자가 아니라 확실한 예가 되었는지는 잘 모르겠다.

아무튼 이 두가지에 의거해서 컴퓨터는 캐시를 관리하는데 이러한 캐시들이 얼마나 잘 적중하는지에 따라서 성능에 영향을 미친다.

그렇다면 캐시가 MemoryFalseSharing과 어떤 상관이 있는지 알아보자.

컴퓨터가 위의 두 작업을 위해서 특정 data를 참조시 우선적으로 현재 캐시메모리[L1]에 있는지를 확인한다.

만약 data가 없을 시 현재 캐시메모리에 있는 캐시라인을 비우고(flush) data을 찾은 후 

그 근처에 있는 주소를 캐시라인에 다시 채워준다.

그러나 이 때 MemoryFalseSharing이 발생하는 경우가 생긴다.

예를 들면 스레드A와 스레드B가 작업을 진행했는데 

참조하는 영역이 미묘하게 겹친다고 생각을 해보자.

AAAACCCCCCCCCCCBB

A : A가 캐시라인에 넣을 영역

C : A와 B 둘다 캐시라인에 적재할 영역

B : B가 캐시라인에 넣을 영역

자 이제 A가 우선 캐시라인에 넣는다고 생각을 해보자.

기존에 있던 캐시라인을 flush한 후 A의 참조영역을 캐시라인에 저장한다.

그 후 B가 다시 데이터를 참조한다.

여기까진 괜찮지만 다시 A가 캐시라인을 확인할 때 MemoryFalseSharing가 발생하게 된다.

A가 캐시라인을 읽을 때 C영역에 대해서 데이터가 변경되었을 확률이 있기때문에 

캐시라인을 비우고 다시 A영역에 대해서 캐시라인을 채우게 된다.

이러한 경우가 바로 MemoryFalseSharing이다.

이해한 내용 기반으로 포스팅했기때문에 세부적인 성능차이에 대해서는 코딩을 통해서 확인해봐야할 것 같다.

최근에 C#으로 Server프로그래밍을 하다가 일반적인 generic 컨테이너외에도 Concurrecny가 붙어있는 컨테이너들이 존재한다는 것을 알게 되었다.

이때는 단순히 동시접근에 대해서 내부적으로 관리해주는 컨테이너라고만 알고있다가 

심심해서 단어를 검색해봤는데 Parallelism과 다른 의미를 지닌다는 것을 알게되었다.

다른 블로그에서 정리되어 있는 글들을 보고 내가 이해한 내용은 아래와 같다.

Parallelism과 Concurrency는 각각 평행성, 동시성이라는 의미를 지닌다.

이 둘은 언뜻 비슷한것 아닌가라는 생각이 들수 있지만 엄연히 다른것이다.

우선 대표적인 Parallelism은 멀티스레딩이라고 생각한다.

이는 멀티스레딩이 여러개의 스레드가 '평행적'으로 실행되기 때문이다.

반대로 대표적인 Concurrenct는 유니티의 코루틴이라고 생각한다.

Concurrenct가 의미하는 동시성이라는 의미는 같은 스레드 내에서 '동시'에 실행되는 것이라고 생각한다.

유니티의 경우 우선 싱글스레드 기반으로 작동하며 하나의 스레드 내에서 코루틴을 활용하여 일종의 서브루틴을 만듦으로써 마치 일종의 '비동기'함수처럼 활용할 수 있기 때문이다.

Concurrency의 장점은 유니티의 코루틴이 충분히 보여주고 있다고 생각한다.

기존의 Parallelism의 경우 멀티스레드를 통해서 많은 작업을 빠르게 처맇라 수 있지만

Lock, 버그등을 생각해본다면 Concurrency한 로직으로 구현하는 것도 충분히 좋은것 같다