기타 칼럼

리뷰(게임, 하드웨어, 칼럼, 영상리뷰) 게시판은
닥터몰라 운영진이 작성한 게시글을 보는 게시판으로 회원들의 작성은 금지되어 있습니다.
(단, 좋은 글이 있으면 글 작성자의 허락과 운영자의 회의를 통하여 리뷰게시판으로 이동 됩니다.)

[CPU] 현대 CPU의 구조 : 메모리 계층 구조와 성능

IYD | 조회 172 | 추천 0 | 2010.11.24. 15:53 http://drmola.com/etc_column/28926

Author : Daeguen Lee

(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)




1. Introduction

앞서 작성했던 두 '현대 CPU의 구조' 강좌의 속편입니다. 무려 7개월 만의^^;

- 현대 CPU의 구조 -백엔드 편-: http://iyd.kr/57
- 현대 CPU의 구조 -프론트엔드 편-: http://iyd.kr/73

두 강좌에서 첫머리에 등장했던 그림을 기억하시나요?


첫번째 강좌에서는 연두색 상자 안의 '백엔드' 구조에 대해 알아봤었습니다.
두번째 강좌에서는 보라색 상자 안의 세 단계 - '프론트엔드' 라 불리는 - 중 디코드 부분을 자세히 살펴봤고,
이번 강좌에서 다룰 것은 CPU 밖의 나머지 파란 상자들 - '메모리 계층 구조' 라 불리는 부분입니다.

본격적으로 강좌에 들어가기 앞서 제 컴퓨터의 메모리 계층 구조를 간단히 살펴볼까요?


이 한 장의 스크린샷에 제 컴퓨터의 메모리 계층 구조가 모두 나타나 있습니다.
이 글 뒷부분에서 이 한 장의 스크린샷으로 어떻게 여러분 컴퓨터의 성능을 예측할 수 있는지 알아보도록 하죠.


2. SISD vs. SIMD

우선 컴퓨터의 작업 형태는 다음의 두 가지로 분류될 수 있습니다.
- SISD (Single-Instruction, Single-Data)
- SIMD (Single-Instruction, Multiple-Data)

전자는 하나의 명령어가 하나의 데이터 스트림을 처리하는 것이고 후자는 하나의 명령어가 여러 데이터 스트림을 병렬적으로 처리합니다. 수학적으로 전자는 스칼라 연산, 후자는 벡터 연산이라고도 하는데 이해를 돕기 위해 간단한 예를 들어 보겠습니다.
- SISD의 예: A + B <- 하나의 명령어 (덧셈) 가 데이터 스트림을 한개씩 상대함
- SIMD의 예: {A, B, C} + {D, E, F} <- 하나의 명령어가 여러 데이터 스트림에 대해 동시에 적용됨


▲ SISD와 SIMD의 예
그림 출처: Ars Technica, [SIMD architectures], Jon Stokes, 3/21/2000

통 하나의 연산을 여러 데이터에 적용하는 것은 같은 성질을 가진 데이터의 집합체에서, 그리고 특정 작업을 반복적으로 시행해야 할 때 큰 성능 향상을 이끌어낼 수 있는데 이러한 성질은 대개 멀티미디어 어플리케이션에서 잘 관찰됩니다. (예를 들어 이미지 편집 프로그램에서 이미지에 필터를 적용할 경우, '필터링'에 해당하는 특정 명령어 스트림이 이미지 데이터 전체에 대해 매 픽셀마다 같은 연산을 반복적으로 수행하게 됨. 스트리밍, 렌더링, 인코딩 등의 작업도 마찬가지)

반면에 동질한 성질의 데이터를 다루지 않는 경우나 여러 종류의 작업이 불규칙하게 수행되는 경우엔 SIMD 방식을 적용할 수 없는데 이러한 패턴을 보이는 것은 주로 오피스 프로그램입니다. (워드프로세서, 데이터베이스 관리, 스프레드시트 등) 사실, SISD와 비교했을 때 SIMD 방식의 약점은 범용성이 떨어진다는 것인데 따라서 오늘날의 CPU는 SISD 구조를 바탕으로 별도의 SIMD 처리 유닛을 내장하는 식의 확장을 꾀하고 있습니다.

또한 흔히 SISD를 정수 연산과, SIMD를 부동소수점 연산과 동일시하는 시각이 있는데, 이론적으로는 부동소수점 데이터를 SISD 방식으로 처리해야 할 경우도 있고 정수 데이터에 대해 SIMD를 적용할 수도 있으니 엄밀히 말해서 맞는 말은 아닙니다. 하지만 정수 데이터가 많이 쓰이는 오피스 어플리케이션, 부동소수점 데이터가 많이 쓰이는 멀티미디어 어플리케이션의 특성상 위에서 살펴본 분류를 따르자면 결국 오늘날의 컴퓨팅 환경에서는 SISD = 정수, SIMD = 부동소수점으로 수렴하는 경향이 있단 것도 틀린 말은 아닙니다.

따라서 이 글의 나머지 부분에서는 필요에 따라 SISD/정수 연산, SIMD/부동소수점 연산이란 용어를 같은 것으로 간주해 혼용해 사용하도록 하겠습니다.


3. Locality of Reference

대개의 경우 캐시메모리는 메인 메모리에 비해 매우 적은 용량을 갖고 있습니다. 그럼에도 불구하고 적은 용량의 캐시메모리가 CPU와 메모리 사이에서 원활히 가교 역할을 할 수 있는 것은 명령어/데이터 스트림의 '참조 집약성'이라는 성질 때문입니다. 다시 말해 이 성질을 추적함으로써, 캐시메모리는 단지 넓은 메모리 용량 중 일부분을 임의로 저장해 두는 것보다 더 효율적인 방식으로 '필요할 것으로 예측되는' 스트림을 콕 집어 저장해 둘 수 있는 것이죠. 이번 장에서는 이 참조 집약성이란 성질에 대해 알아 보겠습니다.

참조 집약성에는 아래의 두 가지가 있습니다.
- 공간 집약성 (Spatial Locality)
- 시간 집약성 (Temporal Locality)


▲ 공간 집약성의 예
그림 출처: Ars Technica, [Understanding CPU caching and performance], Jon Stokes, 7/7/2002

공간 집약성은 CPU가 메모리상의 어느 한 위치에서 명령어/데이터를 참조했다면 머지 않아 그 근처의 연속된 주소에서 다음 명령어/데이터를 찾는다는 것이고, 시간 집약성은 CPU가 특정 명령어/데이터를 과거에 사용했다면 머지 않은 시간 내에 그 명령어/데이터를 다시 사용한다는 것입니다. 이 참조 집약성은 프로그램에 따라, 그리고 한 프로그램 내에서도 명령어와 데이터에 따라서 달라질 수 있는데, 그 예를 보도록 하죠.

(1) 첫번째로 워드프로세서 작업을 상상해 봅시다. 문서 파일을 열어 특정 단어를 다른 단어로 치환한 후 글꼴을 변경할 때, 단어를 검색하는 명령어 / 치환하는 명령어 / 글꼴 변경 명령어가 메모리상에서 연속적인 위치에 있을 가능성은 크지 않습니다. 즉 공간 집약성이 작다는 것이죠. 하지만 그 작업들의 대상이 되는 '문서 파일' 데이터는 메모리상의 연속적인 공간에 집약되어 있으므로 공간 집약성이 매우 큽니다.

(2) 또다른 예로 음악 재생 프로그램으로 여러 개의 음악파일을 재생할 때를 상상해 봅시다. '음악 재생' 명령어는 전체 음악파일의 재생시간 내내 반복적으로 사용되지만 (즉 시간 집약성이 높지만), 음악파일 데이터에서 한번 '사용'된 부분이 머잖아 다시 반복 재생될 가능성은 크지 않습니다. 다시 말해 이 경우엔 데이터의 시간 집약성은 매우 작다고 봐야 합니다 (특정 구간만 반복해서 듣지 않는 한). 대신 하나의 파일은 메모리상에 연속적으로 저장되어 있으니 데이터의 공간 집약성은 큰 편이죠.


따라서 명령어와 데이터를 별도의 캐시메모리에 나누어 담아 각각 다른 참조 집약성 관리정책을 쓰는 것이 성능상 유리하고, 이렇게 명령어-캐시와 데이터-캐시를 따로 두는 구조를 '하버드 아키텍처'라고 합니다. 오늘날의 CPU에서 L1캐시는 명령어/데이터를 나눠 담는 것이 일반적입니다. (L1-D 캐시, L1-I 캐시)



특정 명령어/데이터 스트림이
시간 집약성이 뛰어나다면 과거에 사용했던 스트림을 항상 저장해 두는 것이 유리하므로 캐시의 용량이 클수록 좋습니다. (반면 캐시의 속도는 그리 중요하지 않게 됩니다) 이와 달리 특정 스트림의 공간 집약성이 뛰어날 때에는, 과거에 사용했던 스트림을 하염없이 저장해 두는 것보다는 메모리상의 연속적인 위치에서 스트림을 '연속적으로' 끊임없이 읽어들이는 것이 중요하므로 캐시의 속도가 빠른 것이 중요합니다. 이 경우엔 과거에 사용했던 스트림이 다시 사용될 가능성이 낮으니 한번 사용된 스트림을 바로 비우더라도 성능에 악영향을 미치지는 않습니다. 따라서 캐시의 용량이 일정 수준 이상 커질 필요는 없죠.

(1) 게임을 예로 들자면 하나의 명령어 스트림이 다량의 데이터를 반복 처리하는 SIMD 작업이 대부분인데 (예: 렌더링, 필터링, 안티알리아싱), 하나의 맵 (= 화면) 을 플레이할 때 해당 화면을 구성하는 데이터는 메모리상의 인접한 경로에 저장되어 있을 가능성이 크므로 공간 집약성이 크다고 볼 수 있습니다. 따라서 게임의 흐름에 따라 다음 화면을 구성할 데이터의 위치를 예상해 미리 캐시에 담아 두는 것이 바람직하죠. 따라서 캐시의 속도가 빠를수록 좋습니다. 반면 과거에 플레이했던 구간의 화면이 언젠가 다시 사용되리란 기대를 가지고 이를 모두 저장하기 위해 큰 용량의 캐시를 사용하는 것은 효율적인 캐시 관리 정책이 아닙니다.

(2) 반면 오피스 프로그램은 앞서 말했듯 SISD 작업이 주가 되는데, 이 경우엔 전체 스트림에서 데이터가 차지하는 비중은 SIMD 작업보다 크게 적은 편이고 (∵ SISD는 명령어:데이터가 1:1, SIMD는 명령어:데이터가 1:多) 다시 말해 명령어 스트림의 참조 집약성에 의거해 캐시를 관리하는 것이 현명합니다. (물론 SIMD 작업에서도 명령어는 공간 집약성을 따르지 않을 수 있지만, 명령어:데이터 비율이 1:多인 SIMD 작업의 특성상 데이터의 비중이 압도적으로 크기 때문에 데이터의 참조 집약성만을 고려해도 성능이 크게 떨어지지는 않습니다)

스프레드시트나 데이터베이스 관리 프로그램의 경우, 과거에 수행한 몇 가지의 작업을 계속해서 수행하는 빈도가 높기 때문에 시간 집약성이 큰 편이고, 따라서 한번 사용했던 명령어 스트림을 저장해 두었다가 언젠가 다시 사용될 경우를 대비하는 것이 합리적입니다. 다시 말해 저용량/고속의 캐시보다는 속도가 조금 느리더라도 용량이 큰 캐시가 성능상 유리합니다.


아마 이 글을 읽고 계신
여러분은 과거 셀러론 (멘도시노) CPU가 L2 캐시 용량이 펜티엄 II보다 작아 정수 연산 성능이 크게 떨어졌지만 게임 성능은 펜티엄 II와 대등했던 것을 기억하실 겁니다.
(펜티엄 II는 CPU 외부에 CPU 속도의 절반으로 작동하는 512KB L2 캐시를 장착했지만, 셀러론은 128KB L2 캐시를 CPU 내부에 탑재해 CPU와 같은 속도로 작동하게 함으로써 캐시의 속도가 펜티엄 II보다 빨랐습니다)


4. Latency vs. Bandwidth of Hierarchies

기본적으로, 캐시메모리의 존재 이유는 CPU와 메모리의 속도 차이를 극복하여 CPU에게 '끊김 없이' 스트림을 전달해주기 위해서입니다. ('끊김 없이'가 중요한 이유는 오늘날의 CPU는 상당히 깊은 파이프라인 구조를 사용해, 파이프라인 버블이 성능에 미치는 악영향이 크기 때문입니다)

이론상 고속 & 고용량의 캐시메모리를 장착하면 성능상 가장 좋은 결과를 얻겠지만 비용 문제를 고려했을 때 이는 현명한 해결책이 못 됩니다. 따라서 대부분의 CPU는 초고속/미세용량 - 고속/저용량 - 저속/고용량으로 이어지는 '메모리 계층 구조'를 채택해 각 단계별 속도 차를 세분화함으로써 CPU가 최대한 끊김 없이 스트림을 공급받을 수 있도록 대책을 강구했습니다.

대개 오늘날의 CPU는 CPU - L1 캐시 (명령어/데이터) - L2 캐시 - (L3 캐시) - 메모리로 이어지는 메모리 계층 구조를 갖고 있는데, 첫 장에서 보았던 스크린샷을 다시 한번 보도록 합시다.


▲ 에버레스트 캐시 & 메모리 벤치마크 결과를 보면 각 계층별로 대역폭과 레이턴시가 나와 있습니다.
아시겠지만 L1 캐시의 레이턴시가 가장 짧고 대역폭도 가장 높습니다 (= 속도가 가장 빠릅니다).
그리고 그 뒤를 이어 L2 캐시, L3 캐시, 메모리의 순으로 속도가 떨어지는 것을 알 수 있죠.

가능한 한 속도가 빠른 L1 캐시가 높은 적중률을 갖춰 CPU에게 스트림을 공급해 주는 것이 성능상 가장 유리하기 때문에 용량 대비 L1 캐시의 적중률은 다른 계층보다 훨씬 높게끔 설계됩니다. 하지만 아무리 좋은 정책에 의거해 캐시를 관리하더라도 캐시 미스가 발생하는 경우가 생기는데, L1 캐시에서 캐시 미스가 발생한 경우 CPU는 L2 캐시에게 데이터를 요청하고 L2 캐시가 데이터를 찾게 됩니다. (L2 캐시에서도 미스 발생시 L3 캐시로 넘어가고, 그 다음 순위는 메모리입니다)

이 때 각 계층이 CPU에 응답하는 시간이 레이턴시, 필요한 스트림을 CPU에 전송해 주는 통로의 폭이 대역폭인데 CPU로 넘겨줄 스트림의 용량에 따라 레이턴시와 대역폭이 각각 성능에 미치는 영향력이 달라지게 됩니다. 간단한 예를 들어 보겠습니다.

모든 캐시에서 미스가 발생해 CPU가 메모리에 직접 스트림을 요청했다고 가정해 봅시다.


▲ 위의 스크린샷을 기준으로, 레이턴시 31.9ns / 읽기 대역폭 12614MB/s을 이용해 계산한 자료입니다.

보시다시피 스트림의 용량이 작을 경우엔 레이턴시가 성능에 큰 영향을 미치지만, 용량이 커질수록 레이턴시가 전체 소요시간에 미치는 영향은 점점 작아지는 것을 알 수 있습니다. 다시 말해, 작은 파일을 빈번하게 읽고 쓰는 경우에는 레이턴시가 성능에 더 큰 영향을 미치지만 큰 파일을 가끔 읽고 쓰는 경우라면 레이턴시보다도 대역폭이 성능에 더 중요하다는 뜻이 됩니다.

그렇다면, 레이턴시가 느리지만 대역폭이 더 높은 경우에 성능이 어떻게 변할지도 예상이 가능하겠죠?
레이턴시 45ns / 읽기 대역폭 16000MB/s인 경우를 가정해 보겠습니다.


▲ 100MB 스트림을 읽는 경우엔 레이턴시가 빠른 쪽이 성능이 더 좋지만, 500MB 스트림에서 성능차가 좁혀지더니 1GB 스트림에서는 대역폭이 높은 쪽이 역전했습니다. 즉 주고받은 스트림의 용량이 클수록 높은 대역폭이 더 중요해진다는 것을 보여주고 있죠.


5. Hierarchy and Performance

한편, 같은 계층의 레이턴시/대역폭뿐만 아니라 계층간의 레이턴시/대역폭 차이도 성능에 영향을 주게 됩니다.
예를 들어 L3 캐시가 없는 Athlon II 시리즈의 경우, L2 캐시에서 미스가 발생하면 공은 바로 메모리에게 넘어가게 되는데 이 경우 메모리 전 단계에 L3 캐시라는 완충장치가 한 단계 더 있는 Phenom 시리즈에 비해 필연적으로 성능저하가 생기게 됩니다. 이를 앞의 스크린샷을 바탕으로 유추해 보겠습니다.
(편의상 Athlon II의 메모리 레이턴시/대역폭은 위 스크린샷과 같다고 보겠습니다)



▲ 아래 그래프는 위의 그래프를 토대로 L3 캐시가 있을 때와 비교해 L3 캐시가 없을 때의 상대성능을 나타낸 것입니다. 작은 스트림을 읽고 쓰는 일상적인 작업에서 L3 캐시가 없는 Athlon II 시리즈는 성능 저하가 발생할 가능성이 크다는 것을 그래프가 보여주고 있습니다. 오히려 스트림의 용량이 늘어나면 캐시 미스로 인한 성능차가 줄어드는 편인데, 이때는 캐시의 적중률이 문제가 되겠죠.
(※ 위 그래프는 L1 캐시 미스 후 L2 캐시까지 미스가 발생했을 때에 한정된 결과입니다. 실제로는 L2 캐시까지에서의 적중률도 상당히 높은 편이라 저렇게까지 성능이 벌어지지는 않습니다)

그렇다면, L3 캐시가 있는 경우 L2 캐시가 적중한 때와 L2 캐시 미스가 발생한 때의 성능 차를 계산해 봅시다.
스크린샷에 따르면 L3 캐시의 레이턴시/대역폭은 5.5ns/12569MB/s, L2 캐시는 2.3ns/31709MB/s 입니다.



▲ L2 캐시 미스가 발생한 경우엔 L2 캐시가 적중한 때보다 거의 절반 가까이 떨어진 성능을 내게 됩니다.
즉 L3 캐시의 유무보다도 L2 캐시의 적중률을 끌어올리는 것이 성능에 더 유리하다는 뜻이죠.

즉 4장과 5장의 내용을 종합하면 아래와 같습니다.
- 작은 스트림을 다루는 작업의 경우 레이턴시가 성능에 중요하다.
- 큰 스트림을 다루는 작업의 경우 대역폭이 성능에 중요하다.
- 아래 계층의 메모리보다는 위 계층의 메모리가 성능에 더 중요하다.


6. Inclusive vs. Exclusive Among Hierarchies

인텔과 AMD는 자사의 CPU를 설계함에 있어 서로 다른 캐시 구조를 채택하고 있는데, 그 중 주요한 차이점은 인텔은 하위 계층 캐시가 상위 계층 캐시의 내용을 반드시 포함하도록 하는(inclusive)구조인 데 비해 AMD는 상/하위 계층 캐시의 내용이 서로 배타적인(exclusive)구조란 점입니다. 이는 단순히 우연에 의해 상위 레벨 캐시의 내용물이 하위 레벨 캐시에 존재하고 없고의 차이가 발생한 것이 아니라, 매우 의도적으로 그렇게 설계된 것인데 이 장에서는 이 두 설계 방식의 특징과 장단점에 대해 알아보도록 하겠습니다.


<Inclusive 방식>

Inclusive 방식은 앞에서 설명했듯 상위 계층의 내용물이 하위 계층에 포함되어야 하는데, 이 조건이 '상위 계층의 내용이 전부 하위 계층에 포함되어야 하는지' 혹은 '상위 계층의 내용 중 일부라도 하위 계층에 포함되어야 하는지'에 따라 다시 Stricly-Inclusive 방식과 Mainly-Inclusive 방식으로 나뉩니다. 어느 쪽이든 Inclusive 방식을 취할 때 장점이 되는 것은, CPU 이외의 장치(또는 멀티프로세서 시스템에서 다른 CPU)가 캐시에 담긴 자료를 참조하고 싶을 때 모든 계층의 캐시를 둘러볼 필요 없이 가장 낮은 계층의 캐시만 둘러보면 된다는 점입니다. 그 외에도 Inclusive 방식의 주된 장점이 하나 더 있는데, 이것은 뒤에서 Exclusive 방식의 단점을 설명할 때 함께 설명하도록 하죠.

Inclusive 방식의 단점은 각 계층 캐시 용량의 총 합보다 적은 양의 자료만을 담을 수 있다는 것입니다. 정확히 말해 Inclusive 방식에서는 '가장 낮은 계층의 캐시의 용량'만큼의 자료밖에 담을 수 없게 되는데, 상위 계층의 모든 캐시에 담긴 자료가 최하위 계층의 캐시에 반드시 존재해야 한다는 것을 생각하면 당연한 결과입니다. 즉 256KB L1 캐시와 4MB L2 캐시를 장착한 인텔 Core 2 Quad Q8000 시리즈의 경우, 총 캐시 용량은 4.25MB이지만 실제로 담을 수 있는 자료의 양은 4MB를 초과할 수 없게 됩니다. (L2 캐시에 담긴 4MB의 자료 중에서 L1 캐시에 256KB를 선별적으로 저장해야 함)


<Exclusive 방식>

Exclusive 방식은 상위 계층과 하위 계층 캐시가 저장한 내용이 상호 배타적이어야 합니다. (상호 독립적인 것과는 다른 개념입니다. 예컨대 L2 캐시에 특정 데이터가 있든 없든 L1 캐시에 그 데이터를 담을 수 있다면 이는 상호 독립적인 것이지만, L1/L2 캐시에 데이터를 담을 지 여부를 판단할 때 L2/L1 캐시에 해당 데이터가 있는지 여부를 조사해 없을 경우에만 담는다면 이는 독립적이지 않은 것이죠) 이 방식의 가장 큰 장점은 각 계층 캐시가 하나의 거대한 캐시처럼 기능함으로써 캐시의 총 용량을 효율적으로 활용할 수 있게 된다는 점입니다.

예를 들어 인텔 펜티엄 III 카퍼마인 CPU는 32KB L1 캐시와 256KB L2 캐시를 탑재했지만 실질적으로 256KB의 자료밖에 저장해둘 수 없는 반면, 경쟁자였던 AMD 애슬론 썬더버드 CPU는 128KB L1 캐시와 256KB L2 캐시를 탑재해 L2 캐시의 용량이 같음에도 경쟁 상대보다 1.5배 더 많은 384KB의 자료를 저장할 수 있었습니다. (반면 이 특징은 양날의 검처럼 작용해, L2 캐시가 L1 캐시에 비해 매우 큰 경우에는 Inclusive 방식에 비해 그리 효율이 앞선다고 볼 수 없게 됩니다. 예컨대 인텔 Core 2 Quad Q9050 시리즈는 256KB L1 캐시와 12MB L2 캐시를 내장했는데, Inclusive 방식을 채택함으로써 못 쓰게 된 256KB의 용량은 전체 캐시 용량에 비하면 매우 미미한 수준일 뿐입니다)

Exclusive 방식의 또다른 장점은 L2 캐시의 감소가 성능에 큰 영향을 미치지 않는다는 것인데, 이는 성능상의 잇점이라기보다는 CPU 제조단가를 절감하는 데 도움이 되어 (= 성능을 크게 희생하지 않으면서 L2 캐시가 차지하는 면적을 과감히 줄일 수 있기 때문에) 제조사 차원에서 하나의 CPU 아키텍처에 기반한 여러 하위 모델을 손쉽게 파생시킬 수 있게 해 줍니다. 그 예로 AMD 애슬론의 하위 모델인 듀론은 L2 캐시를 256KB에서 64KB로 무려 1/4이나 줄인 모델이지만, L1 캐시는 애슬론과 같이 128KB를 탑재해 L2 캐시 절감에 따른 성능저하를 최소화하면서 다이사이즈를 성공적으로 줄일 수 있었습니다.

반면 Exclusive 방식의 단점은 그 특성상 모든 계층의 캐시가 거대한 단일 캐시처럼 작동하기 때문에, 모든 계층의 캐시에 걸쳐 같은 크기의 자료 단위를 사용해야 한다는 점입니다. 사실 캐시의 최소 단위는 CPU가 어떤 자료를 찾기 위해 캐시를 '둘러 보는' 시간에 직결되기 때문에 성능에 큰 영향을 미치는데, 일반적으로 캐시의 용량이 커지면 최소 단위도 적정 수준까지 커지는 것이 검색 시간 단축에 유리합니다. 하지만 Exclusive 방식에서는 용량이 상대적으로 큰 L2 / L3 캐시도 용량이 적은 L1 캐시와 균등하게 같은 크기의 최소 단위를 가져야 하므로 검색 시간에서 Inclusive 방식에 비해 불이익이 발생할 가능성이 높습니다. (이것을 뒤집으면 Inclusive 방식의 장점이 되는데, 각 계층 캐시의 용량에 따라 개별적으로 적당한 크기의 최소 단위를 설정할 수 있어 각 계층 캐시마다 최적화된 검색 시간을 가질 수 있게 됩니다)


보통 인텔 CPU는 L1 캐시에 비해 L2 캐시가 매우 큰 편이고, AMD CPU는 반대로 하위 계층 캐시에 비해 상위 계층 캐시의 용량이 큰 편인데 이러한 차이는 우연의 산물이 아닌 각 제조사의 캐시 구조 차이에 따른 고도로 계산적인 결과물이란 것이죠.

 

//

 

(아래 위젯은 티스토리의 크라우드펀딩 시스템인 '밀어주기' 위젯입니다. 100원부터 3000원까지의 범위 내에서 글쓴이에게 소액 기부가 가능합니다. 사견으로는 이러한 형태의 펀딩이야말로, 성공적으로 정착될 경우 이해관계자로부터 독립된 벤치마크가 지속가능해지는 원동력이 될 것이라 생각합니다. 제가 작성한 글이 후원할만한 가치가 있다고 여기신다면 밀어주기를 통한 후원을 부탁드립니다. 물론 글을 '가치있게' 쓰는 것은 오롯이 저의 몫이며, 설령 제 글이 '후원할 만큼 가치있게' 여겨지지는 못해 결과적으로 후원을 받지 못하더라도 그것이 독자 여러분의 잘못이 아니란 건 너무 당연해 굳이 언급할 필요도 없겠습니다. 저는 후원 여부와 관계없이 제 글을 읽어주시는 모든 독자분께 감사합니다.)

 

 

 

  • |
  • |
  1. latency_twodiff.jpg (File Size:38.3KB/Download:0)
  2. 1_general_architecture.jpg (File Size:59.7KB/Download:0)
  3. latench_bandwidth.jpg (File Size:28.8KB/Download:0)
  4. two_architecture.jpg (File Size:28.8KB/Download:0)
  5. 31.9ns.jpg (File Size:227.2KB/Download:1)
  6. level_3_norm.jpg (File Size:0Byte/Download:1)
  7. 31.9ns.jpg (File Size:227.2KB/Download:0)
  8. spatial_locality.png (File Size:5.9KB/Download:0)
  9. level_3.jpg (File Size:36.4KB/Download:0)
  10. sisd_simd.gif (File Size:9.6KB/Download:0)
  11. level_2.jpg (File Size:35.4KB/Download:0)
facebook twitter google plus pinterest kakao story band

서명

no image

IYD

(level 1)

적용중인 트로피가 없습니다.

Profile image DJ™ 2011.02.19 20:12
글 잘 읽었습니다.
제가 산수를 잘 못해가지고 질문 할게 있어서 이렇게 글 남기고 갑니다

레이턴시와 대역폭을 비교하는 그래프 자료에서
Transfer Time의 단위가 ns가 맞는가요? 제가 계산했을 때는 ms가 맞는것 같아서;;

제가 지식이 짧아서.. 자세한 설명 부탁드려요..
수정 삭제
Profile image ㄷㄱ ver.2 2011.02.19 20:29
다시 계산해보니 밀리세컨드가 맞군요;;
조만간 수정판을 올릴 건데 그때 고쳐 올리도록 하겠습니다.
지적 감사합니다...^^ㅋ
수정 삭제
Profile image K.S.J 2011.02.21 00:21
안녕하세요ㅎㅎ 이번에는 수정해야할 부분이 있는거 같아서 댓글올려봅니다.
시간집약성과 공간집약성을 설명하는 부분중 워드프로세서를 예로 들어 설명하는 문단을 보면 3번쨰 줄에는 공간집약성이 작다고 되어있는데 마지막 줄에는 공간집약성이 크다고 되어있네요;; 3번째 줄의 공간집약성을 시간집약성으로 고쳐야 할꺼 같네요...
그런데 이거 너무 자잘한거긴 하네요;; 안 고쳐도 왠만한 사람은 이해할꺼니... 왜 L1캐시는 명령어와 데이터를 따로 저장할까... 가 궁금해서 자세히 보다가 발견한거라;;ㅋ
수정 삭제
Profile image ㄷㄱ ver.2 2011.02.21 00:43
"첫번째로 워드프로세서 작업을 상상해 봅시다. 문서 파일을 열어 특정 단어를 다른 단어로 치환한 후 글꼴을 변경할 때, 단어를 검색하는 명령어 / 치환하는 명령어 / 글꼴 변경 명령어가 메모리상에서 연속적인 위치에 있을 가능성은 크지 않습니다. 즉 공간 집약성이 작다는 것이죠. 하지만 그 작업들의 대상이 되는 '문서 파일' 데이터는 메모리상의 연속적인 공간에 집약되어 있으므로 공간 집약성이 매우 큽니다."

...이 대목을 말하신 거라면 원문에 적힌 내용이 맞습니다.
즉 워드프로세서 '프로그램 (= 명령어)' 자체는 공간 집약성이 작지만,
그 프로그램의 작업 대상인 '문서 파일 (= 데이터)'은 공간 집약성이 크다는 얘기인데...
다시 한번 읽어보시겠어요? ^^;

위의 워드프로세서 예제는 한 프로그램 내에서도 명령어와 데이터의 집약성이 서로 다를 수 있다는 것을 보여주기 위해 고안한 것입니다.
수정 삭제
Profile image K.S.J 2011.02.21 00:52
아아... 너무 성급하게 결론을 지었군요... 죄송합니다;; 어쨌든 감사합니다ㅎㅎ
수정 삭제
Profile image 최민혁 2011.07.14 20:22
한가지 궁금한점이 있습니다. L1 명령어 캐쉬에 1024개의 명령어가 순차적으로 저장 되어 있다고 가정하고 어떤 프로그램에서 L1 캐쉬에 있는 1024개의 명령어들을 다 사용 하였을 경우.. 캐쉬에 있는 명령어들은 쓸모 없어 지게 된다고 생각이 드는데요.. 이럴경우에는 운영체제가 그 이후에 명령어를 L2 캐쉬로 가져오도록 요청을 하게 되는건가요..? L1 캐쉬에 있는 명령어들을 다 쓰고나서 L1 캐쉬에 존재하지 않는 명령어를 가져오게 될 경우에는 명령어를 프로그램이 요청할때마다 캐쉬에서는 적중 실패가 될 것 같은데.. 이럴 경우에는 캐쉬 적중 실패가 100%가 되리라 생각이 드네요;
이때에는 다른 1024개의 명령어를 캐쉬에 적재 할 것 같은데..으흠;; 혹시 읽어보시면 답변 부탁드립니다;
수정 삭제
Profile image ㄷㄱ ver.2 2011.07.14 20:28
일단 L1캐시상의 특정 명령어가 '이미 사용되었다'고 해서 쓸모없어지는 건 아닙니다. 멀티미디어 어플리케이션의 예를 들었듯, 몇몇 어플리케이션은 몇 개의 한정된 명령어를 반복적으로 수행하는 경우가 있기 때문이죠.

이미 사용된 명령어가 다시는 쓰이지 않을 것인지, 혹은 오래도록 반복되어 쓰일 것인지 여부는 별도의 분기예측 하드웨어가 판단하고 (ex: C언어에서 for문 안의 명령어는 대개 언제나 다시 실행된다고 보는 쪽이 가능성이 높고, 혹은 통계적인 분석에 근거할 수도 있습니다.) 그 판단에 의거해 캐시는 해당 명령어를 지우거나 남겨 두게 됩니다.
수정 삭제
Profile image 좋은 개발자 2015.09.07 19:24
좋은 글 감사드립니다 ^^
전공 이해 하는데 많은 도움이 되었습니다!

ps. 기억하고 싶은 몇몇 내용을 공부용으로 가져왔습니다^^;;
수정 삭제
Profile image DGLee 2015.09.07 21:05
제 글을 좋게 봐 주셔서 감사드립니다 :)
수정 삭제
  • 맥 프로의 가치 [ICT] 맥 프로의 가치 [7] file

    Author : Daeguen Lee(Any action violating either copyright laws or CCL policy of the original source is strictly prohibited)0. 내색한 적은 한번도 없지만 (그리고 아무도 안 믿을테지만) 내겐 완제품 PC에 대한 로망이 있다. 특히 맥... 새로 나온 맥 프로가 그간 이미지로만 보던것과 달리 매우 아담하단 사실에 ...

    • IYD |
    • 13.12.26 |
    • 조회 30 |
  • A short essay on "Kaveri" [CPU] A short essay on "Kaveri" [13] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 사실 "Future is fusion" 이라는 AMD의 슬로건에서부터 예견되었던 것이기도 하지만 CPU+GPU 이종교배의 진정한 힘은 다이사이즈 축소를 통한 원가절감 따위를 훨씬 상회하는 것이리라. Ma...

    • IYD |
    • 13.11.27 |
    • 조회 6 |
  • [VGA] 라데온 R9 290 -> R9 290X 변신?! [14] secret

    비밀글입니다.

    • IYD |
    • 13.11.15 |
    • 조회 2 |
  • [VGA] GeForce GTX 780 GHz에 관한 썰 [4] secret

    비밀글입니다.

    • IYD |
    • 13.10.31 |
    • 조회 0 |
  • NVIDIA GeForce GTX 780 Ti 성능 예측 [VGA] NVIDIA GeForce GTX 780 Ti 성능 예측 [6] file

    글쓴이 : 이대근연락처 : leedaeguen [at] kaist.ac.kr(이 블로그의 CCL정책에 위배되는 무단전재 및 재배포를 금지합니다)두시간 전 해외 포럼인 ChipHell을 통해 GTX 780 Ti의 사양으로 추정되는 스크린샷이 유출되었습니다.▲ GTX 780 Ti의 사양으로 2496SP설, 2688SP설, 2880SP설 등이 분분했는데, 위의 정보가 정확한 것...

    • IYD |
    • 13.10.22 |
    • 조회 46 |
  • An essay on NVIDIA GeForce GTX 780 Ti [VGA] An essay on NVIDIA GeForce GTX 780 Ti [5] file

    글쓴이 : 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재 및 재배포를 금지합니다) 엔비디아에서 방금 지포스 GTX 780 Ti라는 새 제품의 출시를 예고했습니다. 그간의 네이밍 정책에 비춰 볼 때 해당 제품은 GTX 780의 상위 모델일 것은 확실하나 모델 넘버가 없는 GTX TITAN과의 우열관계는 확실치 않은데, 일단 단선적...

    • IYD |
    • 13.10.19 |
    • 조회 5 |
  • FCAT : 프랩스에 종언을 고함 [VGA] FCAT : 프랩스에 종언을 고함 [2] file

    글쓴이 : 이대근 (이 블로그의 CCL정책에 위배되는 무단전재/재배포를 금지합니다) 재미있는 글을 읽었습니다. 일단 글을 소개하자면 원문은 아래 링크와 같습니다. (see this : http://techreport.com/review/24553) 간단히 요약하자면 "Fraps로 측정하는 프레임레이트는 정확하지 않다. 나아가 현존하는 모든 방식의 프레...

    • IYD |
    • 13.09.30 |
    • 조회 16 |
  • GK110, 하와이 가상 대결 : by VGA 계산기 [VGA] GK110, 하와이 가상 대결 : by VGA 계산기 [7] file

    글쓴이: 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 그동안 '그래픽카드 성능 방정식'을 사용해 몇번의 포스팅을 올리곤 했는데, 혹시 이 방정식의 배경이 궁금하셨던 분은 안 계셨는지요. 오늘은 아직 출시되지 않은 '가까운 미래의' 그래픽카드의 성능을 예측함과 함께 그간 한번도 직접적으...

    • IYD |
    • 13.09.12 |
    • 조회 23 |
  • [VGA] A short essay on GK110 [4]

    글쓴이: 이대근 (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 지금으로부터 약 19개월 전, AMD는 코드명 Southern Islands로 명명된 새 GPU를 발표했고 이들 제품군은 전세대 자사/경쟁사 플래그십 제품군 대비 2배~2.5배에 가까운 압도적인 성능 향상을 가져온 반면 소비전력은 전세대와 별 차이가 없...

    • IYD |
    • 13.09.05 |
    • 조회 7 |
  • [ICT] 주파수경매 총평

    글쓴이: 이대근 연락처: leedaeguen [at] kaist.ac.kr (이 블로그의 CCL 정책에 위배되는 무단전재/재배포를 금지합니다) 주파수경매 총평 (매우 주관적임) : 1. KT는 (이미 보유하고 있던) 1.8GHz대역 20MHz폭(업로드 10/다운로드 10)의 바로 옆에 추가로 15MHz폭(업 5/다운 10)을 보유하게 됨으로써 별도의 기술적 변경 없...

    • IYD |
    • 13.08.31 |
    • 조회 18 |
  • [VGA] 지포스 GTX TITAN 성능 예상 : by VGA 계산기 [3]

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) ▶ 참고글1: http://iyd.kr/488 (그래픽카드 성능 방정식을 이용한 7970/680 성능 예측) ▶ 참고글2: http://iyd.kr/200 (그래픽카드 성능 방정식을 이용한 페르미 라인업의 성능 예측) ▶ 참...

    • IYD |
    • 13.02.19 |
    • 조회 32 |
  • It still works! : VGA 계산기로 돌려 본 7970, 680 예상 성능 [VGA] It still works! : VGA 계산기로 돌려 본 7970, 680 예상 성능 [8] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 안녕하세요. 한동안 올릴 글이 없었는데 지인의 요청을 받고 간단히 해 본 실험입니다.ㅎㅎ 다름이 아니라...... 오래 전 만든 'VGA 성능 방정식' 이 최신 VGA에까지 적용이 가능한지 여부...

    • IYD |
    • 12.04.11 |
    • 조회 40 |
  • [CPU] 잊혀진 아키텍처들 (예고편) [22] secret

    비밀글입니다.

    • IYD |
    • 11.10.17 |
    • 조회 4 |
  • [VGA] Hybrid PhysX 구성 팁 [12] secret

    비밀글입니다.

    • IYD |
    • 11.08.06 |
    • 조회 1 |
  • Hybrid PhysX : 6990 + GTX260 [VGA] Hybrid PhysX : 6990 + GTX260 [5] file

    글쓴이: 이대근 (ㄷㄱ)※ 무단전재 및 재배포를 금지합니다. 퍼가실 때에는 원제, 작성자, 출처를 반드시 병기해 주시기 바랍니다 ※ 안녕하세요. 오랜만에 벤치를 작성하게 되었습니다ㅋㅋ 이 블로그 개설 초기에 라데온 4870 + 9800GT를 사용한 하이브리드 피직스 구성 팁을 올렸었는데요,드라이버 버전들이 많이 올라가고 (...

    • IYD |
    • 11.08.05 |
    • 조회 6 |
  • AFR의 비밀 : 크로스파이어 미지원 게임 수동 설정법 [VGA] AFR의 비밀 : 크로스파이어 미지원 게임 수동 설정법 [14] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 크파 유저분들은 가끔 이 문제로 속을 썩으셨을 텐데요...비싼 돈 들여 크파를 구성해 놨더니 정작 갖고 있는 게임이 크파를 지원하지 않는다면?!눈물을 머금고 GPU 하나만 갈구며 게임을 ...

    • IYD |
    • 11.07.10 |
    • 조회 86 |
  • [VGA] Some articles on multi-GPU scaling [6] secret

    비밀글입니다.

    • IYD |
    • 11.06.30 |
    • 조회 0 |
  • 파이프라이닝의 이해 [CPU] 파이프라이닝의 이해 [22] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) (그림 출처: 위키피디아)명령어가 수행되는 과정을 아래와 같다고 칩시다.인출 - 디코드 - 실행 - 쓰기(완료)이 네가지 과정은 각각 해당 과정의 기능에 맞는 하드웨어에 의해 수행되고이...

    • IYD |
    • 11.03.02 |
    • 조회 73 |
  • 멀티스레딩 기술의 이해 [CPU] 멀티스레딩 기술의 이해 [53] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) 오늘은 현대 CPU의 성능향상 기법 중 하나인 SMT에 대해 간단히 알아 보겠습니다.SMT는 Simutaneous Multi-threading의 약자로, 동시에 여러 스레드를 처리하는 기법을 통칭합니다.CPU의 ...

    • IYD |
    • 11.02.05 |
    • 조회 97 |
  • 현대 CPU의 구조 : 프론트엔드 편 [CPU] 현대 CPU의 구조 : 프론트엔드 편 [36] file

    Author : Daeguen Lee (Any action violating either copyright laws or CCL policy of the original source is strictly prohibited) Tweet 얼마 전 백엔드 구조를 중심으로 현대의 CPU에 대해 알아 보았습니다.(현대 CPU의 구조 강좌 <백엔드 편> ☞ 여기)이번 강좌에서는 그때 설명하지 않고 남겨둔 프론트엔드에 대해 간...

    • IYD |
    • 11.01.22 |
    • 조회 177 |