AMD 라이젠에 대해 많은 사람들이 궁금해하는 점을 가지고 테스트한 글입니다. 어떤 건 이미 꽤 전에 이슈가 지나가기도 했으나, 새로운 내용이 있으니 복습할겸 보시죠. 사실 테스트 결과보다도 방법이 좀 참신하다 싶은게 많아 올려 봅니다.

 

 

1. SMT는 게임 성능을 떨어트리는가?

 

 

 

SMT는 Simultaneous Multi-Threading의 줄임말로 AMD CPU 중에선 라이젠에 처음으로 도입됐습니다. CPU 코어가 가진 리소스를 잘 분배해 두개 이상의 스레드를 동시에 실행하는 구조입니다. 라이젠은 SMT로 1개의 코어에서 2개의 스레드를 동시 실행 가능해, 8코어 라이젠 7은 16코어 프로세서로 인식하게 됩니다. 물론 CPU 자원에는 한계가 있어, 1개의 코어에서 2개의 스레드를 동시에 실행하면 스레드 1개의 성능은 SMT를 껐을 때보다 떨어집니다. 그래서 윈도우에선 논리 CPU를 따로 구별해 내부에서 리소스 충돌이 일어나지 않도록 스레드를 스케줄링합니다.

 

SMT는 인텔의 하이퍼스레딩과 완전히 같은 기술입니다. SMT는 원래 1995년에 워싱턴 대학과 Digital Equipment Corporation(DEC)가 함께 개발한 기술로, 1997년에 인텔이 DEC의 반도체 부문을 인수하면서 SMT에 하이퍼쓰레딩이란 이름을 붙였습니다. 이후 2000년대엔 IBM과 선 마이크로시스템(지금은 오라클)이 SMT를 구현했으나, AMD는 전혀 접근 방법이 다른 불도저 아키텍처를 선택하면서 SMT를 쓰지 않았습니다. 그래서 AMD가 SMT 기술 구현에 약하다거나, 윈도우가 라이젠의 SMT를 제대로 인식하지 못하는게 아니냐는 의혹이 있었지요.

 

이런 의혹에 대해선 AMD가 부정한 바 있습니다. SMT는 게임에 긍정적인 영향을 주며 윈도우 스케줄러에 문제는 없다는 것. 윈도우가 라이젠의 SMT를 제대로 인식하지 못한다는 의혹은 마이크로소프트의 코어인포 유틸리티가 잘못 인식했기 때문에 생겨난 것이라고 합니다. 3.31 버전 이후의 코어인포라면 라이젠 정보를 정확하게 인식합니다. 아래는 라이젠 7 1800X에서 코어인포를 실행해 논리-물리 CPU 코어 지도 부분을 뽑아낸 것입니다. 물리 코어 1개당 2개의 논리 CPU가 있다고 정확하게 인식했음을 알 수 있습니다.

 

Logical to Physical Processor Map :
** -------------- Physical Processor 0 (Hyperthreaded)
- ** ------------ Physical Processor 1 (Hyperthreaded)
---- ** ---------- Physical Processor 2 (Hyperthreaded)
------ ** -------- Physical Processor 3 (Hyperthreaded)
------ - ** ------ Physical Processor 4 (Hyperthreaded)
---------- ** ---- Physical Processor 5 (Hyperthreaded)
------------ ** - Physical Processor 6 (Hyperthreaded)
-------------- ** Physical Processor 7 (Hyperthreaded)

Logical Processor to Socket Map :
************ **** Socket 0

Logical Processor to NUMA Node Map :
**************** NUMA Node 0

 

 

그래서 테스트 환경입니다. 일본어가 섞였지만 보시는 데 지장은 없을 듯. 라이젠 7 1800X가 듀얼채널, 코어 i7-6900K가 쿼드채널로 메모리 구성이 다르긴 하지만 다른 스펙은 비슷한 수준으로 맞췄습니다.

 

 

 

우선 파이어 스트라이크의 종합 점수입니다. 라이젠은 SMT를 켰을 때 오히려 2~3% 정도 점수가 높네요. 반대로 코어 i7-6900K는 하이퍼스레딩을 껐을 때 점수가 크게 오른 경우가 있습니다.

 

 

 

그래픽 점수만 뽑아내서 보면 별 차이가 없습니다.

 

 

 

피직스 테스트입니다. 라이젠 7 1800X와 코어 i7-6900K는 SMT를 껐을 때 79%를 유지하네요. 즉 SMT 기능 자체의 효율은 인텔이나 AMD가 비슷한 수준이라 봐도 될 듯.

 

 

파이널 판타지 벤치마크입니다. GPU 부하를 낮춘 표준 품질에서 테스트했는데, AMD는 SMT 기능 여부에 따라 별 영향을 받지 않았으나, 오히려 인텔은 이 기능을 껐을 때 성능이 더 높았습니다.

 

 

프로세스가 만들어내는 스레드를 확인할 수 있는 프로세스 스레드 뷰를 쓰면 파이널 판타지 벤치마크에서 얼마나 많은 스레드를 만들고, 그 움직임은 어떤지를 확인할 수 있습니다. SMT를 썼을 때 컨텍스트 스위치, 즉 스레드가 활성화된 수를 보면 파이널 판타지 벤치마크는 사용할 수 있는 CPU 코어에서 1을 뺀 수만큼의 활성 스레드를 만들어 냅니다.

 

 

그럼 SMT를 끄면 7이 되겠죠. 바꿔 말해 라이젠 7은 코어 수가 많으니까 더 많은 스레드를 만들겠고, 코어 i7-6900K는 그 수가 적으니 영향을 많이 받게 될 것입니다. 파이널 판타지 벤치마크처럼 논리 코어 수에 따라 스레드를 만들어버리는 타이틀이라면 SMT를 썼을 때 성능이 높아질 것이며, 코어 수가 많다면 더 효과가 좋겠죠. 물론 이는 게임마다 다를 것이니 이거 하나만으로 모두 다 이렇다고 속단할 순 없습니다.

 

 

2. CCX가 라이젠 성능에 얼마나 영향을 주는가?

 

 

젠 마이크로 아키텍처는 4개의 CPU 코어와 코어 1개당 512KB L2 캐시, 8MB의 공유 L3 캐시를 하나의 모듈로 구성한 CPU 컴플렉스, 줄여서 CCX를 기본 단위로 삼습니다. 인텔의 코어 프로세서라면 모든 CPU 코어를 링 버스로 연결한 아키텍처를 사용하나, 젠 아키텍처는 CCX끼리 내부 고속 인터커넥트 인터페이스, 인피니티 패브릭으로 연결됩니다. 이건 어디까지나 AMD 내부에서 쓰는 것이기에 기술 스펙은 명확히 드러나지 않았으나, 데이터 전송용인 데이터 패브릭, 모듈 사이의 제어 정보를 교환하는 컨트롤 패브릭의 두가지 데이터 버스가 있습니다. 데이터 패브릭은 높은 대역폭과 낮은 레이턴시를 갖춘 하이퍼트랜스포트를 기반으로 했으며 캐시 데이터의 일관성을 지닙니다.

 

 

여기서 중요한 건 CCX와 이들을 연결하는 인피니티 패브릭의 성능이 2개의 CCX를 하나의 다이에 통합하는 라이젠의 성능에 얼마나 영향을 주냐는 것입니다. 예를 들어 같은 데이터를 공유하며 관련성이 높은 스레드가 2개 있다고 칩시다. 이게 서로 다른 CCX에 할당된다면 CCX의 L3 캐시에 같은 데이터가 있어야 하고 그 일관성이 서로 유지되야 최고의 효율을 뽑아낼 수 있습니다. 또 이 데이터를 자주 업데이트하는 경우엔 데이터 패브릭의 일관성을 활용한 데이터 전송이 자주 이루어집니다. 반면 관련성이 높은 두개의 스레드가 같은 CCX에 있는 2개의 물리 CPU 코어에 할당된다면, 1개의 l3 캐시에서 데이터가 공유되기에 이런 문제는 생기지 않습니다.

 

윈도우는 캐시 맵을 통해 캐시 구성을 파악합니다. 현재 CPU에선 CPUID 명령 확장을 통해 캐시 구성을 검색할 수 있으며, 윈도우가 시작될 때 그 기능을 사용해 캐시 정보를 파악합니다. 아래는 라이젠 7 1800X와 코어 i7-6900K에서 코어 인포를 실행해 Logical Processor to Cache Map 부분을 뽑아낸 것입니다. SMT를 켜면 논리 프로세스가 함께 나와 알기 어렵기에 일단 SMT를 끄고 표시했는데요. 캐시와 물리 프로세서의 지원을 나타내는 별포를 보면 그 차이를 확실히 알 수 있습니다. L3인 Unified 캐시는 라이젠이 쿼드코어 x2로 나뉘어져 있으나 코어 i7-6900K는 모든 코어가 단일 캐시를 씁니다.

 

라이젠 7 1800X의 캐시 맵

 

Logical Processor to Cache Map :
* -------	Data Cache 0	Level 1	32 KB	Assoc 8	LineSize 64
* -------	Instruction Cache 0	Level 1	64 KB	Assoc 4	LineSize 64
* -------	Unified Cache 0	Level 2	512 KB	Assoc 8	LineSize 64
**** ----	Unified Cache 1	Level 3	8 MB	Assoc 16	LineSize 64
- * ------	Data Cache 1	Level 1	32 KB	Assoc 8	LineSize 64
- * ------	Instruction Cache 1	Level 1	64 KB	Assoc 4	LineSize 64
- * ------	Unified Cache 2	Level 2	512 KB	Assoc 8	LineSize 64
- * -----	Data Cache 2	Level 1	32 KB	Assoc 8	LineSize 64
- * -----	Instruction Cache 2	Level 1	64 KB	Assoc 4	LineSize 64
- * -----	Unified Cache 3	Level 2	512 KB	Assoc 8	LineSize 64
--- * ----	Data Cache 3	Level 1	32 KB	Assoc 8	LineSize 64
--- * ----	Instruction Cache 3	Level 1	64 KB	Assoc 4	LineSize 64
--- * ----	Unified Cache 4	Level 2	512 KB	Assoc 8	LineSize 64
---- * ---	Data Cache 4	Level 1	32 KB	Assoc 8	LineSize 64
---- * ---	Instruction Cache 4	Level 1	64 KB	Assoc 4	LineSize 64
---- * ---	Unified Cache 5	Level 2	512 KB	Assoc 8	LineSize 64
---- ****	Unified Cache 6	Level 3	8 MB	Assoc 16	LineSize 64
----- * -	Data Cache 5	Level 1	32 KB	Assoc 8	LineSize 64
----- * -	Instruction Cache 5	Level 1	64 KB	Assoc 4	LineSize 64
----- * -	Unified Cache 7	Level 2	512 KB	Assoc 8	LineSize 64
------ * -	Data Cache 6	Level 1	32 KB	Assoc 8	LineSize 64
------ * -	Instruction Cache 6	Level 1	64 KB	Assoc 4	LineSize 64
------ * -	Unified Cache 8	Level 2	512 KB	Assoc 8	LineSize 64
------- *	Data Cache 7	Level 1	32 KB	Assoc 8	LineSize 64
------- *	Instruction Cache 7	Level 1	64 KB	Assoc 4	LineSize 64
------- *	Unified Cache 9	Level 2	512 KB	Assoc 8	LineSize 64

 

코어 i7-6900K의 캐시 맵

 

Logical Processor to Cache Map :
* -------	Data Cache 0	Level 1	32 KB	Assoc 8	LineSize 64
* -------	Instruction Cache 0	Level 1	32 KB	Assoc 8	LineSize 64
* -------	Unified Cache 0	Level 2	256 KB	Assoc 8	LineSize 64
********	Unified Cache 1	Level 3	20 MB	Assoc 20	LineSize 64
- * ------	Data Cache 1	Level 1	32 KB	Assoc 8	LineSize 64
- * ------	Instruction Cache 1	Level 1	32 KB	Assoc 8	LineSize 64
- * ------	Unified Cache 2	Level 2	256 KB	Assoc 8	LineSize 64
- * -----	Data Cache 2	Level 1	32 KB	Assoc 8	LineSize 64
- * -----	Instruction Cache 2	Level 1	32 KB	Assoc 8	LineSize 64
- * -----	Unified Cache 3	Level 2	256 KB	Assoc 8	LineSize 64
--- * ----	Data Cache 3	Level 1	32 KB	Assoc 8	LineSize 64
--- * ----	Instruction Cache 3	Level 1	32 KB	Assoc 8	LineSize 64
--- * ----	Unified Cache 4	Level 2	256 KB	Assoc 8	LineSize 64
---- * ---	Data Cache 4	Level 1	32 KB	Assoc 8	LineSize 64
---- * ---	Instruction Cache 4	Level 1	32 KB	Assoc 8	LineSize 64
---- * ---	Unified Cache 5	Level 2	256 KB	Assoc 8	LineSize 64
----- * -	Data Cache 5	Level 1	32 KB	Assoc 8	LineSize 64
----- * -	Instruction Cache 5	Level 1	32 KB	Assoc 8	LineSize 64
----- * -	Unified Cache 6	Level 2	256 KB	Assoc 8	LineSize 64
------ * -	Data Cache 6	Level 1	32 KB	Assoc 8	LineSize 64
------ * -	Instruction Cache 6	Level 1	32 KB	Assoc 8	LineSize 64
------ * -	Unified Cache 7	Level 2	256 KB	Assoc 8	LineSize 64
------- *	Data Cache 7	Level 1	32 KB	Assoc 8	LineSize 64
------- *	Instruction Cache 7	Level 1	32 KB	Assoc 8	LineSize 64
------- *	Unified Cache 8	Level 2	256 KB	Assoc 8	LineSize 64

 

윈도우가 캐시 그룹을 파악한다면 서로 관련성이 높은 2개의 스레드를 한쪽 CCX에 몰아서 할당해준다면 좋겠으나, 정말 그렇게 될거라 단언할 순 없습니다. 스레드 스케줄링은 매우 복잡한 구조이기에 이를 파악하기도 어렵습니다.

 

 

AMD는 인피니티 패브릭의 세부 사항을 공개하진 않았으나, 데이터 패브릭은 라이젠의 메모리 클럭과 서로 동기화돼 작동한다고 밝힌 바 있습니다. CPU 메모리 컨트롤러가 DDR4-2667(실제 클럭 1333MHz)로 메인 메모리에 액세스한다면 데이터 패브릭의 동작 클럭 역시 1333Mhz가 된다는 것입니다.

 

앞서 언급한대로 데이터 관련성이 높은 2개의 스레드가 같은 CCX에 존재하는 경우와 다른 CCX로 나뉘어졌을 경우엔 스레드 실행 효율에 차이가 있을 것으로 추측됩니다. 다른 CCX로 분할됐다면 스레드 실행 효율은 CCX를 연결하는 데이터 패브릭 대역폭과 레이턴시에 영향을 받을 것입니다. 그리고 이 2개의 CCX는 라이젠에서 비교적 쉽게 눈으로 확인 가능한데요. 메모리 블럭에 데이터를 기록하는 스레드(W 스레드)와 데이터를 읽어오는 스레드(R 스레드)를 만들고, W 스레드와 R 스레드를 실행하는 코어 할당을 정기적으로 변경해, R 스레드의 평균을 내는 샘플 프로그램을 만들면 됩니다.

 

 

여기에선 라이젠 7 1800X의 L3 캐시 용량에 맞춰 1KB, 64KB, 1MB, 16MB의 4단계로 바꿔 총 15GB의 데이터를 읽고 쓰는 과정을 2개의 스레드에서 동시에 수행하는 프로그램을 만들었습니다. 그래서 15GB를 4블럭 만큼 1초에 읽어온 양을 계산해서 정리했는데요. W와 R 스레드의 동기화는 없고 W는 데이터 기록, R은 데이터를 읽기만 합니다. 그저 두개가 동시에 실행중일 뿐이죠.

 

 

 

 

RP0~RP7은 R 스레드가 실행되는 프로세서 코어의 번호. WP0~WP7은 프로세서 코어의 수입니다. RP0의 위치를 보면 WP1~WP7일 때 R 스레드가 1초에 얼마나 데이터를 읽어오는지를 파악 가능합니다. 이를 통해 RP0에서 W 스레드가 WP1, WP2, WP3일 때 RP0은 1700~1800MB/s인 반면, W 스레드가 WP4, WP5, WP6, WP7인 경우에는 1020MB/s가 나왔습니다. 마찬가지로 R 스레드가 RP1이고 W 스레드가 WP4, WP5, WP6, WP7이면 1020MB/s로 성능이 떨어집니다.

 

쉽게 말하면 W 스레드와 R 스레드가 같은 CCX에 있어도 데이터를 주고 받는 속도에 일정한 편차가 있으며, CCX의 경계는 매우 명확하게 드러난다는 것입니다. 연관성이 높은 두개의 스레드를 하나의 CCX 안에서 처리한다면 성능이 높고, 그렇지 않으면 성능이 떨어질 수밖에 없다는 것이죠.

 

그런데 앞서 말한대로 데이터 패브릭의 동작 클럭은 메모리 클럭과 동기화됩니다. 그럼 CCX의 데이터 전송 효율은 메모리 클럭에 따라 변할 것입니다. 그래서 메모리 클럭을 다르게 해서 테스트했습니다.

 

 

 

 

DDR4-2133으로 클럭을 낮췄을 땐 DDR4-2400에와 별 차이가 없습니다. 사실 메모리 클럭 변화 자체가 적어서 그런듯.

 

 

 

그럼 메모리 클럭을 DDR4-3200으로 오버클럭하면? 서로 다른 CCX 사이의 데이터 전송 효율이 1100MB/s까지 올랐습니다. DDR4-2400으로 설정했을 때보다 10% 정도 성능이 높다는 것입니다. DDR4-2400에서 데이터 패브릭의 클럭이 1.2GHz인데 DDR4-3200은 1.6GHz니 1.33배가 됩니다. 그러니 클럭 향상분만큼 성능이 높아진다고 할 수 있겠습니다.

 

 

 

 

 

같은 테스트를 코어 i7-6900K의 DDR4-2400에서 실행하면 이렇게 됩니다. 여기에선 R 스레드가 P3일 경우에만 성능이 좋게 나온다는 독특한 결과가 나왔는데, 이건 또 따로 연구를 해봐야 할 듯.

 

 

 

 

3. 2개의 CCX가 실제 애플리케이션에 미치는 영향은?

 

그럼 이런 이론적인 테스트 말고 실제 애플리케이션에서 얼마나 영향을 줄지가 관건인데, 이를 검증하기란 매우 어렵습니다. 프로세스나 프로세스에서 실행되는 스레드를 어떤 CPU에 할당할지를 결정하는 건 OS 스케줄러이기 때문입니다. 그러나 윈도우는 Affinity Mask라는 값을 프로세스에 설정해 특정 스레드가 특정 코어에서 실행되도록 선호도를 정할 수 있습니다. Affinity Mask는 Win32 API의 SetAffinityMask에서 설정할 수 있으며 윈도우 명령 프롬프트에서 "start / affinity 0x00FF (실행 파일).exe" 같은 명령으로 스위치를 설정 가능합니다.

 

여기에 나온 16진수 0x00FF는 그 뒤으 실행 파일에서 어떤 CPU를 실행할 것인지를 지정하는 Affinity Mask입니다. 16진수를 2진수로 바꿔서 어떤 코어에서 실행할지를 정하면 됩니다. 다만 여기에 물리/논리 코어의 구분은 없습니다. 그럼 16개를 어떻게 지정하느냐. 그건 아래 예시를 보세요.

 

0x00FF : 00000000_11111111 (P0-P7에서 실행)

0xF00F : 11110000_00001111 (P0-P3, P12 ~ P15에서 실행)

0x5555 : 01010101_01010101 (P0, P2, P4, P6, P8, P10, P12, P14에서 실행)

0x0055 : 00000000_01010101 (P0, P2, P4, P6에서 실행)

0x5005 : 01010000_00000101 (P0, P2, P12, P14에서 실행)

0x0F : 0000_1111 (P0 ~ P3에서 실행)

0xCC : 1100_1100 (P2, P3, P6, P7에서 실행)

 

그래서 이게 효과가 있을까요? 테스트해 봅시다. 이번에도 역시 파이널 판타지. 위에서 DDR4-2400으로 메인 테스트를 했으니 그대로 유지하고, 표준 품질의 그래픽, 해상도는 1920x1080입니다.

 

 

 

SMT를 활성화하고 affinity 스위치를 사용해 할당된 논리 코어를 전환하면서 8스레드에서 파이널 판타지 벤치마크를 실행했을 때의 점수입니다. 0x00FF는 라이젠 7 1800X에서 8개의 스레드 전부를 한쪽 CCX에 할당한 것이고, 0xF00F는 4스레드씩 2개의 CCX에 나눠 할당한 것입니다. 그리고 0x5555는 스레드를 논리 코어를 제외하고 할당한 것으로 SMT를 끈 것과 다름이 없습니다.

 

이 결과 라이젠 7 1800X는 스레드를 한쪽 CCX에 몰아주거나, 논리 코어를 쓰지 않은 경우의 점수를 비교했을 때 약 95%가 됐습니다. 코어 i7-6900K는 SMT를 끈 것이나 다름 없는 0x5555에서 가장 좋은 성능이 나온 건 논외로 치고, 코어를 분산했을 때 오히려 더 좋은 점수가 나왔습니다. 코어 i7-6900K에서도 코어의 대칭 구조가 의심되는 결과가 때때로 나오는데 거기까진 분석이 안되네요.

 

 

SMT를 끄고 4개의 스레드에서 실행했을 때의 점수입니다. 라이젠 7 1800X의 경우 0x0055는 1개의 CCX에서 4 스레드를 할당해 실행하는 설정이며, 0x5005는 2스레드씩 2개의 CCX로 나눠 실행하는 구조가 됩니다. 여기에선 코어 i7-6900K는 별 차이가 없었으나, 라이젠 7 1800X는 97% 정도로 살짝 낮은 성능이 나왔습니다. 이 말인즉 2개의 CCX에 스레드를 나눠 분배하면 성능이 3% 정도 낮다는 소리 되겠습니다.

 

 

 

그럼 이번엔 SMT를 끄고 4스레드로 테스트해 봅시다. 라이젠 7 1800X에서 0x0F는 하나의 CCX에 4스레드를 할당, 0xCC가 2스레드씩 2개의 CCX에 분할하는 것인데 여기에서도 97% 정도의 성능을 보였습니다. 코어 i7-6900K도 0xCC가 1.5% 정도 점수가 높은데 그 이유는 명확하지 않습니다. 코어 i7-6900K는 8개의 물리 코어에 딸린 L2 캐시까지 독립적인 형태이니 구조적인 문제는 아닐 것입니다.

 

 

그럼 이번에는 종목을 파이어 스트라이크의 피직스 테스트로 바꿔 봅시다. 이건 SMT를 켰을 때. 0x00FF보다 0xF00F가 더 불리했으나 점수 차이가 매우 작았습니다. 이는 1개의 CPU에 2개의 스레드를 할당했을 때의 성능 손실이, CCX 사이에 데이터를 교환하는 손실보다 더 크기 때문으로 보입니다.

 

 

 

이건 SMT를 껐을 때의 비교입니다. 3D마크의 피직스 테스트는 스레드의 독립성이 매우 높다고 추측됩니다. 즉 개별 스레드가 독립적인 데이터를 사용해 연산을 수행하기에, 이런 프로그램에선 CCX 사이에 데이터 전송이 자주 생기지 않아, 스레드가 다른 CCX로 나뉘어져 있어도 성능에 부정적인 영향은 많이 주지 않을 것이라 봅니다.

 

그런데 앞서 확인한대로 라이젠 7의 메모리 컨트롤러는 클럭을 높여 성능을 올릴 수 있습니다. 메모리 테스트에선 DDR4-2400보다 DDR4-3200이 10% 정도의 성능 향상이 있었죠. 그래서 DDR4-2133과 DDR4-3200으로 다시 테스트했습니다.

 

 

파이어 스트라이크의 피직스 테스트입니다. 1개의 CCX에 4개의 스레드를 몰아준 0x0F에선 라이젠 7 1800X가 DDR4-3200으로 오버클럭 시 DDR4-2133보다 1% 높습니다. 2개의 CCX에 2개씩 분배한 0xCC도 1%니 그냥 차이가 없다고 봐도 될 듯. 코어 i7-6900K도 DDR4-3200에서 1% 높으니 둘 다 같은 수준입니다. 위에서 말한대로 피직스 테스트는 데이터 독립성이 높아 보이기에 메모리 클럭 효괄르 받는거지, 데이터 패브릭 클럭의 영향은 별로 없습니다.

 

 

파이널 판타지 벤치마크입니다. 1개의 CCX에 4개의 스레드를 분배한 0x0F에서 라이젠 7 1800X는 DDR4-3200이 DDR4-2133보다 14% 높습니다. 또 2개의 CCX에 2개의 스레드를 분비한 0xCC에서 DDR4-3200과 DDR4-2133의 성능 차이는 15%였습니다. 그러니 둘 다 메모리 클럭이 향상된 만큼 성능이 높아졌다 보입니다. 또 코어 i7-6900K는 5~6% 정도 차이가 났기에, 파이널 판타지 벤치마크는 메모리 클럭 향상으로 인한 효과가 라이젠 쪽이 더 높다고 할 수 있습니다.

 

정리합시다. 이번처럼 극단적인 상황을 만들었을 때, 라이젠의 마이크로 아키텍처 레벨의 단점, 구체적으로 말해서 CPU 코어가 4개씩 2개의 CCX로 나뉘어져 있는 게 단점으로 작용하는 경우가 많진 않다는 게 결론입니다. 메모리 테스트 같은 극한 상황에서 10%였으나 실제 애플리케이션에선 한자리수에 그칠 것입니다. 또 윈도우가 캐시 맵을 참조해 관련성이 높은 스레드를 1개의 CCX에 집중할 수 있도록 Affinity Mask를 설정하면 효율이 과연 높아질 것인가, 라고 봐도 성능 향상에 그리 큰 영향을 주진 않습니다.

 

 

4. 라이젠의 캐시 액세스 레이턴시는 얼마나 큰가?

 

 

 

산드라 2016 SP1 벤치마크에서 라이젠 7 1800X의 캐시/메모리 액세스 레이턴시가 크다는 결과가 나왔지만, AMD는 그렇지 않다고 설명합니다. 스카이레이크와 비교해도 손색이 없는 수준이라는 게 AMD의 주장인데요. 왜 이런 차이가 나냐면 라이젠 7 1800X의 L3 캐시 중 16MB가 8MB씩 2개로 나뉘어져 있으며, 그 사이를 데이터 패브릭으로 연결하기 때문입니다. 산드라 2016이 affinity 스위치를 쓸 수 있다면 그걸 확실히 알 수 있으나 안됐다고 하네요.

 

다만 캐시 용량 범위 안에서 레이턴시가 바뀔 경우, 2개의 CCX로 나뉘어진 것이 레이턴시로 이어진다고 할 수 있겠습니다. 일반적으로 메모리 클럭을 바꿔도 캐시 용량 범위 안에서 액세스 레이턴시는 거의 변하지 않습니다. 하지만 라이젠은 메모리 클럭에 맞춰 데이터 패브릭의 클럭이 바뀌기에 데이터 패브릭 캐시 액세스 레이턴시에 영향을 준다면, 메모리 클럭에 따라 바뀌게 됩니다.

 

 

 

 

여기에선 메모리 클럭이 캐시에 영향을 주는지를 봤습니다. 레이턴시는 15-15-15-35로 고정하고 클럭만 수정했는데요. 4MB에서는 별 차이가 없었으나 8MB에서는 메모리 클럭에 따라 상당한 차이를 보입니다. L2 캐시의 512KB 레인지는 17ns, L1 데이터 캐시의 32KB에선 4ns로 AMD의 자료와 일치합니다. 다만 8MB와 16MB에서 산드라는 라이젠의 L3 캐시 액세스 레이턴시를 제대로 측정하지 못한다고 보입니다.

 

그래서 여기에선 CPU-Z로 유명한 CPU(D가 배포하는 latency.exe를 사용해 테스트했습니다. 이는 매우 고전적인 방법으로 액세스 레이턴시를 측정하나, affinity 스위치를 사용해 실행하면 비교적 안정적으로 CCX의 8MB L3 캐시 레이턴시를 출력해줍니다. 그래서 여기에선 start / affinity 0x0001 latency.exe 로 실행해 테스트했습니다.

 

 

여기에선 비교적 안정적인 결과가 보이네요. AMD의 설명대로라면 L3 캐시 레이턴시는 40 클럭이니까 이 프로그램의 32클럭보다는 높지만, 그래도 산드라보다는 정확하다 보입니다. 그러니 산드라에선 라이젠의 L3 캐시 액세스 레이턴시를 제대로 파악하지 못하며, 서로 다른 CCX의 캐시 데이터는 데이터 패브릭을 통과하기에 액세스 레이턴시는 커지게 됩니다. 허나 앞에서 말한대로 애플리케이션을 다른 CCX에 분할해 실행해도 성능 하락은 몇 % 정도. 8MB L3 x2 캐시가 라이젠의 성능을 크게 저해하는 요소라 보이지 않습니다.

 

 

5. 바이오스 업데이트가 성능 향상 효과를 가져오는가

 

AMD는 3월 30일에 라이젠 시리즈의 바이오스, 더 정확히 말해 AGESA(AMD Generic Encapsulated Software Architecture)를 업데이트했다고 밝혔습니다. AGESA는 애슬론 64 이후 채용된 AMD CPU를 시작할 때 실행되는 코드인 부트스트랩 로더의 일종으로, AMD CPU 코어와 메모리 인터페이스, I/O 초기화를 담당합니다. AGESA는 AMD가 메인보드 제조사에 제공하며 메인보드의 바이오스에 포함됩니다. 3월 하순에 예고했던 AGESA는 버전 1.0.0.4로 4가지가 달라졌다고 설명했습니다.

 

1. DRAM (DDR4-SDRAM) 액세스 지연을 약 6ns 감소

2. FMA3 명령에서 라이젠이 멈추는 버그 수정

3. S3 절전 동작 후 클럭이 이상하게 높아지는 버그 수정

4. 라이젠 마스터 유틸리티에서 HPET(High-Precision Event Timer)를 비활성화

 

2번과 3번은 버그 수정이니 성능에 영향은 없습니다. 여기에선 1번과 4번이 중요합니다. 4번의 HPET는 PC의 클럭 소스(CPU의 동작 클럭과 직접적인 관련이 없이, 시스템이 시간의 흐름을 알기 위해 사용하는 컬럭) 중 하나입니다. IBM PC 시절에 등장한 Programmable Interrupt Timer(PIT) 외에도 펜티엄 시절 등장한 HPET, 그리고 최신인 타임 스탬프 카운터(TSC)라는 3개의 클럭 소스 하드웨어가 있습니다.

 

여기에서 PIT는 호환성 유지를 위해 넣은 것이며 측정 단위가 커 잘 쓰지 않습니다. HPET는 PIT의 문제를 해결하기 위해 칩셋에 장착한 정밀 타이머이고, TSC는 CPU 내부의 베이스 클럭을 쓴 타이머입니다. '정밀 타이머'라고 쓰면 좋아 보이지만 현재 PC에선 HPET보다 TSC가 더욱 세밀합니다. 그래서 윈도우 같은 최신 운영체제에서 HPET는 잘 쓰지 않습니다.

 

 

문제는 오버클럭 유틸리티인 라이젠 마스터에서 왜 HPET를 썼냐는 겁니다. 최근 운영체제에서 HPET를 써서 얻는 이득은 거의 없고, 오히려 TSC보다 정확성이 떨어지는 HPET를 OS 타이머로 쓰면 성능에 부정적인 영향을 줍니다. 그래서 AGESA 1.0.0.4에서 HEPT를 쓰지 않아도 라이젠 마스터 유틸리티를 쓸 수 있도록 했습니다. 라이젠 사용자 중에는 이걸 일부러 활성화해서 쓰는 사람이 있을지 모르는데, HPET를 켜도 부정적인 영향이 크니 그냥 끄세요.

 

 

AGESA 1.0.0.4 개선에서 가장 중요한 건 메모리 레이턴시 감소입니다. 4월 하순까지 ASUS ROG CROSSHAIR VI HERO에선 AGESA 1.0.0.4를 적용한 바이오스가 나오지 않았는데, 이번에는 테스트 버전인 1102를 써서 그 효과를 확인했다고 합니다. 물론 테스트 버전이니 앞으로 성능/호환성/안정성이 더 나아질 수 있습니다.

 

 

테스트엔 산드라 2016 SP1의 캐시/메모리 레이턴시를 사용했습니다. 앞에서 8MB와 16MB 부분 테스트는 믿을 수 없다고 했으나, 시스템 메모리의 액세스 레이턴시 측정 결과는 안정적인 편이나 믿을 수 있겠죠. 여기에선 캐시 용량보다 더 큰, 그러니까 시스템 메모리의 레이턴시를 나타낸 32MB 이상의 데이터를 사용했습니다.

 

 

DDR4-2400. AMD는 AGESA 1.0.0.4의 도입으로 6ns의 개선이 있다고 설명합니다. 그럼 30클럭 정도 차이가 나야 AMD의 말이 맞겠죠. 여기에선 22, 21, 15, 7클럭 정도의 차이를 보였습니다. AMD 주장만큼은 아니어도 어쨌건 성능 향상은 분명 있습니다.

 

 

DDR4-3200에서는 이렇습니다. 각 용량에 따라 22, 39, 25, 1클럭의 향상이 있네요. 1GB에서 효과는 더욱 떨어졌지만, 32~256MB에선 분명 AMD가 주장하는 만큼의 성능을 볼 수 있었습니다.

 

 

6. 메모리 클럭과 메모리 액세스 타이밍에 따라 라이젠의 성능이 달라지는가?

 

지금까지 메모리 테스트는 15-15-15-35로 레이턴시를 통일했습니다. 그러나 지스킬의 3200MHz 메모리 중에는 14-14-14-34가 가능합니다. 따라서 메모리 클럭과 레이턴시에 따른 성능 변화를 확인할 수 있지요. 여기에선 메모리 클럭을 DDR4-3200, 267, 2400. 메모리 레이턴시는 14-14-14-34, 15-15-15-35, 17-17-17-39의 9가지를 놓고 비교했습니다.

 

 

파이어 스트라이크에서 메모리 설정별로 얼마나 차이가 나는지를 테스트했습니다. 우선은 배포 버전인 1002부터. 그래픽 렌더링의 부하가 높아져 CPU가 주는 영향이 줄어드는 파이어스트라이크 익스트림은 거의 오차 범위 수준의 성능이나, 상대적으로 CPU빨을 많이 타는 파이어 스트라이크에선 메모리 설정에 의한 성능 차이가 두드러집니다. 신경이 쓰이는 건 DDR4-3200에서 17-17-39가 가장 점수가 높고, 14-14-14-34의 점수가 오히려 낮다는 것입니다. 다만 바이오스 1002에선 14-14-14-34에서 불안정한 모습을 보였기에 바이오스 안정화의 문제일 가능성도 있습니다.

 

 

사실상 CPU 테스트인 피직스 테스트만 따로 떼어냈습니다. 여기에서도 14-14-14-34의 점수가 부진하네요.

 

 

파이널 판타지로 종목을 바꿔봤습니다. DDR4-3200의 14-14-14-34가 점수가 떨어진 걸 제외하면 나머지는 다들 납득이 가는 수준입니다. 점수 차이는 DDR4-2400 17-17-17-39와 DDR4-3200 15-15-15-35가 13% 정도. 결코 무시할 수 없는 수준입니다.

 

 

이제 메모리 액세스 지연을 줄였다는 테스트 버전 바이오스인 1102(AGESA 1.0.0.4)의 결과입니다. 1002에선 14-14-14-34에서 시스템이 부팅되지 않던 문제가 간혹 발생했는데, 1102에선 그런 일이 전혀 없었습니다. 이 바이오스에선 DDR4-3200의 동작 안정성이 개선됐을 가능성이 높다 보입니다. 파이어스트라이크 점수의 경우 메모리 액세스 레이턴시가 어느 정도 반영이 됐습니다. 역시 DDR4-3200 14-14-14-34의 점수는 낮지만요.

 

 

피직스 테스트만 뽑아서 정리한 것입니다. 메모리 클럭이 높고, 레이턴시가 낮을수록 결과가 좋습니다.

 

 

피직스 테스트보다도 파이널 판타지 벤치마크가 더 직관적인 결과가 나옵니다. DDR4-2400 17-17-17-39와 DDR4-3200 14-14-14-34는 점수가 딱 1.13배네요. 10% 이상의 성능 향상이 있다 할 수 있습니다.

 

물론 1102 바이오스는 테스트 버전이니 이걸로 성능을 속단하긴 어려우나, AMD가 말한대로 AGESA 1.0.0.0인 바이오스 1002보다는 메모리 클럭 최적화, 메모리 레이턴시 조정이 이루어졌다고 봐도 무방합니다.

 

 

7. 라이젠 밸런스드 전원 관리 옵션의 효과는?

 

다음은 4월 6일에 발표되고, 26일에는 칩셋 드라이버에 포함된 라이젠 전용 윈도우 10 64비트 전원 관리 설정인 Ryzen Balanced에 대한 것입니다. AMD는 라이젠이 나왔을 때부터 윈도우의 기본 전원 관리 옵션인 균형 설정에선 라이젠의 잠재력을 이끌어내지 못하기에 고성능 옵션을 쓰라고 권장했습니다. 고성능에선 P 스테이트가 떨어지나 소비 전력은 C 스테이트로 제어되기에 CPU 소비 전력이 지나치게 높아지진 않는다는 게 AMD의 주장입니다.

 

P 스테이트는 현재 CPU의 부하 상황에 따라 CPU 동작 클럭을 동적으로 바꾸는 기능이며, C 스테이트는 아이들 중 캐시 전송 전력을 떨어트리는 절전 기능입니다. 전원 관리 옵션에서 고성능을 선택하면 CPU 동작 클럭은 P0의 최고 클럭 상태로 고정되나, 여기에서 라이젠을 비롯한 최신 CPU는 아이들 시 C 스테이트가 변화해 CPU 소비 전력을 줄여줍니다. 물론 P 스테이트가 떨어지지 않으면 CPU 클럭이 항상 높게 유지되기에 소비 전력에서 분리한 게 사실. 그래서 성능 손실 없이 P 스테이트를 제어할 수 있는 전원 관리 옵션인 라이젠 밸런스드가 나온 것입니다.

 

AMD는 라이젠 밸런스드가 프레임 속도에 미치는 영향이 윈도우의 표준 균형 설정보다 작다고 설명합니다. 그럼 실제로 어떨까요.

 

 

파이널 판타지. 표준 옵션과 비교하면 라이젠 밸런스드가 4% 높고 고성능은 6% 높습니다.

 

 

파 크라이 프라이멀. 여기에선 고성능보다 라이젠 밸런스드가 1프레임 더 높네요. 다만 이건 오차 범위에 들어갑니다. 그냥 고성능과 같은 수준이라 봐도 될 듯.

 

 

PC마크 8입니다. 경우에 따라선 라이젠 밸런스드가 고성능보다 더 높은 결과가 나오기도 하네요. 다만 큰 차이는 아님.

 

 

그럼 소비 전력은 어떨까요. 라이젠 밸런스와 균형 설정에선 순간 90W 정도로 치솟는 구간이 있습니다. P 스테이트 제어에선 상태 변화에 따라 라이젠의 프리시전 부스트가 작동해 순간적으로 높은 클럭이 들어가는 게 아닌가 추측됩니다. 그리고 이런 예외적인 경우를 제외하면 소비 전력의 추세는 비슷하다 보입니다.

 

 

소비 전력을 정리한 것입니다. 위에서 말한대로 순간적으로 치솟는 구간이 있어 균형/라이젠 밸런스드 옵션이 오히려 고성능 프리셋보다 더 높게 나왔습니다. 그냥 고성능에 높고 쓰는 게 마음 편하지 않을까요.

 

 

8. AMD는 라이젠의 상황을 어떻게 파악하고 있는가

 

 

아래는 AMD의 데스크탑 CPU 마케팅 매니저인 Don Woligroski (Desktop CPU Marketing Manager, AMD)와의 인터뷰를 간추린 것입니다. 개발자가 아닌 마케터라는 건 염두에 두고 보세요.

 

SMT기능을 쓰면 프레임 속도가 줄어드는 타이틀이 있는데, 이는 SMT의 문제가 아니라 해당 애플리케이션이 프로세서를 어떻게 파악하느냐에 따라 달라집니다. 라이젠 SMT를 켜면 프레임 속도가 떨어지는 게임에선 '인텔 CPU를 찾는 코드'가 있기도 했습니다. 이런 게임에서 인텔 CPU가 발견되면 논리 CPU를 염두에 두고 가상 스레드를 예약했습니다. 반면 라이젠에선 논리 CPU의 수만큼 물리 CPU가 있다고 판단했습니다. 물론 이를 개발자의 실수라고 생각하진 않습니다. 인텔 CPU 외에 라이젠도 동일한 스레드 스케줄링을 적용해야 한다고 개발자에게 안내하는 노력이 필요하다 봅니다.

 

현재 가장 심각한 건 '싱글 스레드 성능에선 라이젠이 경쟁 CPU 수준이나, 게임에선 그보다 못한 이유를 알려달라'는 것입니다. 여기에 대해선 내부에서 많은 테스트를 하고 있습니다. SMT 비활성화, 1개의 CCX에 스레드를 집중하는 것 등 말이죠. 그 결과 단 하나의 답은 나오지 않았습니다. 예를 들어 2개의 CCX를 써야 성능이 잘 나오는 반면, SMT를 켜야 잘 나오는 경우도 있었습니다. 단순히 하나의 해결책으로 성능 향상을 이끌어낼 순 없습니다.

 

윈도우 스케줄러는 예상대로 작동한다고 생각합니다. 물론 마이크로소프트가 스케줄러 개선을 하길 원하는 건 아니고, 우리 나름대로의 움직임을 하고 있습니다. 일단 라이젠 사용자들에겐 SMT 긴으을 켜고 코어 파킹은 꺼달라고 조언하고 있습니다. 지금은 메모리 안정성과 속도에 주력하고 있습니다. 라이젠은 데이터 패브릭과 메모리가 밀접하게 연동됐거든요.

 

우리의 목표는 3가지로, 라이젠을 최대한 빨리 개선해나가는 것, 특히 메모리가 해결해야 할 숙제입니다. 경쟁상대는 우리보다 더 먼저, 더 오랫동안 DDR4를 사용했습니다. 그리고 아시는대로(AGESA 1.0.0.4의 액세스 레이턴시 감소) 상당한 발전이 있었습니다. 두번째는 게임 개발자의 제휴입니다. 게임 성능에서 문제를 해결하기 위해 개발자들에게 적극적인 어필을 하고 싶네요. 마지막은 앞으로 스케줄러 개선에 착수해 나간다는 것입니다. 이 3가지에 집중해서 최대한 빨리 해결책을 내놓으려 합니다.

 

 

DOTA 2와 AotS에서 성능 향상이 있었던 건, 제가 엔지니어가 아니기에 구체적으로 설명할 수 없습니다. 다만 코드에 이상한 스위치가 있고, 그게 효율을 크게 떨어트렸다는 정말 작은 실수 때문에 성능이 떨어졌다고 합니다. 라이젠 하나를 위해 코드 전체를 바꾼다는 건 말도 안됩니다. 아주 작은 요소 하나 때문에 프레임이 떨어지는 경우도 있습니다. 라이젠은 나온지 아직 한달밖에 안됐으니 라이젠에서 실행하는 걸 염두에 두고 게임을 만들진 않았을 것입니다. 최적화는 앞으로 꾸준히 해나가야 할 일입니다.

 

정말 힘든 건 수백만 줄에 달하는 게임 코드에서 어디가 문제인지를 찾는 것입니다. 그래서 우리는 게임 개발에 계속 참여하고 있습니다. 우리가 처음으로 관여한 건 다른 타이틀에 비해 라이젠에서 성능이 크게 떨어진 게임이었습니다. 사실 실제 플레이에선 60fps 이상을 꾸준히 얻을 수 있음에도 불구하고 경쟁상대인 카비레이크에 비해 프레임이 낮기에 느리다는 말을 듣는데요. 라이젠보다 카비레이크가 IPC는 약간 높기에 IPC가 제약되는 타이틀은 라이젠이 늦을 수밖에 없습니다. 그러나 그 격차를 줄일 수 있다는 게 AMD의 견해입니다.

 

 

우리는 라이젠의 미래에 대해 낙관적으로 보고 있습니다. 라이젠의 최적화 방법이 개발자 쪽에서 서서히 보이고 있거든요. 또한 멀티 스레드에 최적화된 다이렉트 X 12나 벌칸 API를 사용하는 게임 타이틀도 많아질 것입니다. 앞으로 우리는 개발자와 협력을 추진해 1년 동안 조금씩 라이젠의 성능을 높여나갈 것입니다.

 

인피니티 패브릭이 성능의 핵심이지만 스펙은 공개되지 않았습니다. 저도 메모리 클럭의 절반 정도라는 말 밖에 듣지 못했습니다(DDR 메모리의 1/2라는 소리입니다. DDR4-3200라면 데이터 패브릭의 클럭은 1.6GHz가 됩니다. 데이터 패브릭의 성능이 메모리의 절반이라는 건 아닙니다). 라이젠 L3 캐시 액세스의 성능을 제대로 측정할 방법이 없다는 점에 대해선 우리도 놀라고 있습니다. 우리도 소프트웨어를 이용해 테스트했는데 그 결과가 AMD의 이론적인 추정치와 전혀 맞지 않았습니다. 개발자와 협력화 이 문제를 개선하기 위해 노력 중이나, 그 툴이 언제 나올지는 아직 말씀드릴 수 없습니다. 일단 개발중이라는 것만 알아주세요.

 

우선 우리는 라이젠 플랫폼을 안정화하고 오버클럭을 쉽게 할 수 있도록 작업해 나가고 있습니다. 라이젠이 나온지 얼마 되지 않았기에, 일부 업체와 협력해 사용자가 DDR4-3200을 도달할 수 있도록 하자는 목표를 세우고 거기에 맞춰 작업을 진행하고 있습니다. 다양한 메모리 모듈을 메인보드 제조사에 전달해 클럭이나 레이턴시를 최적화하는 작업은 시간이 많이 걸립니다. AGESA 1.0.0.4에선 그 결과 DDR4-3200의 안정화 및 액세스 레이턴시의 절감을 실현했습니다. 물론 이게 다는 아니며 앞으로 더 개선해 나가도록 노력할 것입니다. 앞으로 한달 단위로 새 바이오스(AGESA)를 내놓을 계획도 있습니다.