이 말은 어떤 측면에서는 맞고 어떤 측면에서는 틀립니다. 단지 소프트웨어가 캐쉬를 생각하지 않고 프로그래밍해도 캐쉬 컨트롤러는 나름대로 제대로 알아서 동작한다는 의미로 적으신 거라면 더 할 말은 없습니다. 그러나 transparent의 정의는 또 하위 8가지 정도로 분류해서 설명할 수 있으나 그런 것은 다 접구요. 여기서 적용해서 말한다면 똑같은 Output이 나오지 않는다면 일단 그 시스템은 transparent하다고 할 수 없는 것이 일반적입니다. 똑같은 기능을 수행하는 프로그램이라도 cache hit의 빈도가 높게 프로그래밍을 할 수도 있고 cache miss의 빈도가 높도록 프로그래밍을 할 수도 있습니다. 물론 후자는 의도적이진 않지만 전자에 비하여 얘기한다면 cache가 운용되는 것을 고려하지 않고 작성하였기 때문에 조금 더 떨어진다고 할 수 있습니다. 저도 멀티 프로세싱 환경의 코드를 많이 보지는 못했습니다만 최소한의 샘플 코드만 봐도 어떻게 코딩하는 것이 cache에 stale 데이터가 많이 발생하지 않도록 하는 것인지 나옵니다. 당연히 stale이 많이 일어나게 되면 캐쉬 콘트롤러는 바빠지고 안좋은 경우 메모리로부터 올리는 penalty가 발생합니다. 따라서 소프트웨어에게 캐쉬 컨트롤러는 완벽한 투명성을 제공하지는 못합니다. 즉 소프트웨어가 어째되든 캐쉬 컨트롤러는 자기 일을 하기 나름이라기 보다 캐쉬 컨트롤러를 바쁘게 하는 소프트웨어가 있을 수 있다는 얘기가 됩니다.
cache coherency와 컴파일러는 관련이 없다:
앞서 설명한 바와 같습니다. 좀 더 쉬운 예를 들어 설명을 하면 우리가 어떤 기능을 수행하는 c 프로그램을 만들었을 때 컴파일러는 statement 그대로 컴파일 하는 경우는 드뭅니다. 최적화를 하는 것이죠. 다른 측면에서 보면 유능한 프로그래머는 프로그래밍에 첫 입문하는 사람에 비해 똑같은 기능을 수행하는 코드를 훨씬 효율적으로 만들 수도 있습니다. 기법 자체는 저도 테크니션에 속하는 편은 아니라 상세히 여기에 적을 수는 없지만. cache coherency도 예외는 아닙니다. 예를들어 똑같은 소스코드가 있을 때 A 컴파일러가 컴파일한 바이너리를 a, B 컴파일러가 컴파일한 바이너리를 b라고 했을 때 그 둘을 멀티 프로세서에 수행시킵니다. A 컴파일러는 캐쉬를 전혀 생각하지 않고 컴파일을 하고 B 컴파일러는 캐쉬를 고려하여 최대한 stale이 안나도록, 캐쉬 콘트롤러가 바빠지지 않도록 등등을 고려해서 컴파일 했을 때 a와 b는 그것을 수행하는데 있어 차이가 날 것이라 믿습니다.
이 때에 컴파일러의 역할이 나오는 것입니다. 그러나 이런 문맥을 모두 고려해서 컴파일러를 구현하는 것은 불가능하므로 기본적으로 지켜져야 할 것 들은 컴파일러에 맡길 수 있도록 하고 좀 더 그 때의 시나리오에 따라서 생각을 요해야 하는 부분은 프로그래머가 책임을 지고 코드를 작성할 필요가 있습니다.
컴파일러가 binary를 만들어 그것이 멀티 프로세서 환경에서 수행될 때, cache가 coherent하도록 하는 것은 콘트롤러가 보장을 합니다만 캐쉬 내부적으로 일어나는 수많은 일들과 또 그것으로부터 얻어지는 결과가 컴파일러와 전혀 관계가 없다라고 말하는 것은 무리라고 여겨집니다.
그럼 이만 줄이겠습니다. 이장원님 덕분에 공부가 많이 되고 있습니다. 한편으로는 AMD에 기만당한 거 같아서 기분이 씁쓸한데요. 좀 더 정확히 알기 위해 의뢰 메일을 보냈습니다. AMD의 MP에 대한 선전이 다 허구라면 대고객 사과를 해야할 판이군요. Smart MP라는 기술 설명을 봤을 때 멀티프로세서나 캐쉬를 공부한 사람이라면 누구나 다 캐쉬 운용이 다르구나라고 생각했을 법 한데요. 여튼 확답이 오면 이 곳에 글을 한 번 더 남기겠습니다.
짧은글 일수록 신중하게.