전산관련 지식, 전자 관련 지식이 약간 있으시면 읽기 편합니다.

Barcelona의 내부 : AMD의 다음 세대

1페이지

데자부? AMD의 마지막 전략

2002년, AMD의 K7은 고 클럭의 130nm Pentium 4 Northwood에 밀리고 있었다. 2003년 K8의 발표는 AMD가 회사의 사활을 건 도전이었다. 그러나, 2005년엔, K8 마이크로 프로세서로 대박을 터뜨렸다. 네 개중 3개의 주력 OEM 들이 그들의 서버 제품을 판매하였고 Intel의 제품은 UP (1소켓) 와 DP (2소켓)  서버 시장에서 간신히 자리를 유지하고 있었다. MP (4소켓) 서버 시장에서, 이득 측면에서 AMD는 정확하게 최고의 선택이었다.

이 성공은 경영, 기술적 선호 요인의 일치 때문이었다. 기술적으로, K8은 이전 K7 세대에서 만들어진 구조에서 보수적으로 충실한 설계이며, 서버 시장에 걸맞는 이상적인 설계이다. 이와는 반대로, Intel의 경쟁 제품군 Pentium 4 는 소비자와 미디어 작업에 주효한 설계로, 서버와 노트북 시장에서는 확실히 덜 최적화 되었었다. 설상 가상으로, 90nm 이하에서도 전력과 열 문제 때문에 마이크로 아키텍쳐에서 핵심적인 개념이었던 주파수 끌어올리기에도 실패했었다.

이런 설계 목표들은 최고 운영진들 사이에서 예견되었었다. Intel의 기업 전략은 서버 시장에서 Itanium을 밀어주고, 데스크탑과 노트북 영역에서는 x86 을 밀어주는 것이었다. 불행하게도, Itanium 프로젝트는 Sun과 IBM이 등을 돌려버림으로써, 그리고 가격/ 호환성/ 가용성 문제로 인해 예상한 만큼의 선구자 역할을 하지 못하였다. 이것은 Intel의 계획에서 공백을 남기게 되었고, 이것이 정확히 K8이 강점을 갖게 되었으며 Linux 커뮤니티와 MS에 의해 열광적인 지지를 받게 되었다. 어찌됐든, AMD의 회사의 사활을 거는 K8 전략은 아주 성공적이었으며, 그들에게 재정적 성공이라는 수치상의 데이터를 가져다 주었다.

불행하게도, 이것은 Intel의 경각심을 더 빠르게 일깨워 주는 계기를 마련하게 된다. Intel의 사내 문화와 근로자들의 한가지 강점은 압박 속에서 120% 성과를 달성한다는 점이다. Intel의 Israeli 설계 팀은 지난해 상반기에 선적한 (P6에 기반한) Core 마이크로아키텍쳐를 개발하였는데, 거의 모든 시장에 걸쳐 손쉽게 성능과 효율 면에서 선두를 차지하였다. 이 효과는 놀라웠으며, 올해 1사분기부터 시작되어 2사분기 까지 계속된 순이익, 평균 판매 가격, 시장 점유율 하락 모두를 경험한 AMD는 특히 뼈아픈 기억이었다. 물론, 정확히 Opteron 발매 전인 2002년 부터 2003년 초 그들이 있었던 자리이기에 AMD에게는 친숙한 위치이기도 하다. 그러나 다시, AMD의 신념은 근미래에 나올 제품에 의존하고 있다.

Barcelona - 공백기의 전설의 에이스

지난 몇년간, AMD는 그들의 차세대 프로세서 코드명 Barcelona의 세부 사항을 느릿느릿하게 밝혔다. 첫번째 정보는 2006년에 열린 Spring Processor Forum에서 Senior Fellow Chuck Moore의 기조 연설에서 흘러나왔다. 뒤이어 Fall Processor Forum에서, Ben Sander는 Barcelona의 마이크로 아키텍쳐의 윤곽을 더 정확히 해 주었다. 더욱 최근, Shawn Searles는 ISSCC '07에서의 프리젠테이션에서 Barcelona의 물리적 도입 도전 과제와 몇몇 설계상의 선택 사항을 말해주었다.

Barcelona는 2003년에 세상에 나온 K8에서 대부분의 주요 설계를 따왔다. K8은 아주 역량있는 K7 마이크로 아키텍쳐에서 64비트 연산, 2개의 내장 DDR 메모리 컨트롤러와 3개의 HyperTransport 레인을 추가한 것이다. 이런 특징들은 그리 특별나진 않다. ; AMD의 설계자는 (8채널의 DRDRAM) 메모리 컨트롤러, (4개 내부 프로세서 연결) 온다이 라우팅, 그리고 디렉토리 체계를 처음으로 내장한 MPU인 Alpha EV7의 발자취를 따라갔다. 그러나, K8은 64비트 명령 체계를 도입하고, 주 명령어 세트 아키텍쳐인 x86을 고수준으로 집적함에 따라 예술의 경지 수준으로 진보시키게 된다. K8 프로세서는 서버세상에서 성공에 부합되는 첫 AMD 제품으로, 지혜로운 혁명적이고 보수적인 설계 선택에 대한 명확한 입증 사례이다.

다양한 방향으로, Barcelona는 계속적으로 이 보수적인 방법의 혁신을 계속하게 된다. 이것에는 급진적인 변화가 없다. 사실 Barcelona는 K8과 같이 12 스테이지 파이프라인을 기본적으로 갖고 있고, Barcelona 내에서의 많은 향상점은 성공적으로 시연되어 왔다. AMD의 설계자와 엔지니어로 하여금 그들의 노력을 헛되게 할 것은 없다. - 위험성 높은 기능은 제품에 대한 고장을 용납 못하는 회사에겐 부적절하다.

이 기사는 Barcelona에 대한 현존하는 모든 정보를 한 곳에 모으게 될 것이며, 시스템 외관과 Barcelona의 마이크로 아키텍쳐를 회로 설계와 성능적으로 볼 것이다. 이것은 또한 경쟁사 Intel이 P6 코어를 개량하여 Pentium M과 Core 2 라인에 노력을 할 때 AMD는 어느 영역에 초점을 맞추려 했는지도 알 수 있는 절호의 기회이다.

Barcelona는 283 제곱 밀리미터 설계로 463M개의 트랜지스터를 집적하였으며 4개의 코어와 공유된 2MB의 L3 캐시를 AMD의 65nm 공정으로 처리하였다. 이 SOI 공정은 11층의 low-k 물질과 함께 구리 내부 연결을 사용하며 PMOS 트랜지스터에 SiGe를 주입하고 이중 stress liner를 적용시켰다. ISSCC에서 이 기기를 기술하기를 1.15v에서 2.2~2.8Ghz 정도의 동작을 목표로 하고 있으며, 최대 열 설계를 95W이내에서 구동시킨다고 하였다. AMD가 주장하기를 그들의 65nm 공정은 15ps FO4 반전 지연을 갖고 있다고 주장하는데, 이것으로 Barcelona의 파이프라인은 24ps FO4 지연 시간보다 약간 적을 것으로 추측된다. 이 기사의 이후 섹션들은 7가지 주요 영역을 심층적으로 볼 것인데, 시스템 설계, 마이크로 아키텍쳐의 다섯가지 주요 섹션과 마지막으로 회로 레벨에서의 향상점과 다른 기능들을 보게 될 것이다.

2페이지

시스템 아키텍쳐

K8 시스템 아키텍쳐는 이미 아주 양호하다. 4개 소켓 서버에서, 이것은 명확히 x86 세계를 평정하고 있다. AMD 시스템에서 두개의 주된 문제는 쿼드코어 프로세서의 부재와, 8개 소켓 서버에서의 떨어지는 성능이었다.

Barcelona에서 한가지 가장 강조된 판매 요인은 4개 프로세서 코어를 집적하였다는 것으로, Intel의 Xeon 53xx 시리즈와 동등성을 가져다 준다. 코드명 Clovertown인 Xeon 53xx는, 실제적으로 듀얼코어 Woodcrest의 한 쌍이 다수 칩 패키지로 (MCP) 된 것이다. 이들 프로세서는 칩 상의 버스나 캐시를 통하는 것 대신 FSB를 통해 통신하게 된다. 이와는 반대로, AMD는 캐시의 최 하위 레벨인 공유된 캐시로 접근을 하려 하기 때문에, L3는 모든 4개의 코어에서 쓰이게 된다. 아래의 Figure 1은 리비젼 F Opteron, Barcelona와 Intel 에서 곧 출시될 3Ghz Clovertown과 비교를 하고 있다.


Figure 1- 시스템 아키텍쳐 비교

Barcelona를 설계한 설계자는 완벽히 하나로 집적된 MPU를 의도하였었다. 단일기기는 확실한 고성능, 특히 HPC나 데이터 의존적인 캐싱에서 이득을 얻지 못하는 대역폭에 민감한 부하량에서 엄청나게 빛을 발하게 된다. 그러나, 어떠한 설계상의 결정도 기회비용이 따라오지 않는 것은 없다. 첫번째로, 완벽히 모든것을 집적하는 것은 계획을 시작할 때 결정을 해야한다. MCP로의 접근은 시간을 훨씬 절약시키며 현존하는 제품을 약간 변화시키는 것으로 사용할 수 있다. ; 가장 중요한 것은, 이들 변화가 설계 주기로 가는 데에 방해가 될 수 있다는 것이다. 단일 기기는 또한 낮은 수율을 가지게 되는데, 왜냐면 큰 다이 크기는 웨이퍼당 다이들을 적게 뽑아낼 수 있다는 것으로, 무작위 오염은 더 큰 파급 효과를 갖고 오게 된다. 단일 MPU들은 또한 주파수를 높이기가 더욱 어려운데, 주어진 속도로 동작을 해야하기 때문에, 모든 네개의 코어는 적절한 전력 소모와 함께 목표 수치를 꼭 뛰어 넘어야 한다. 그러나, 이런 설계 기술은 느린 코어와 빠른 코어를 가진 MPU로 하여금 더 낮은 전력으로 느린 속도로 동작하게 한다.

AMD의 마케팅 부서가 그들의 광고 접근법을 "네이티브" 나 "진정한" 쿼드코어 설계로 잡았는데, 사실 두가지 접근법은 동등하게 유효하다. ; 사실 몇몇 AMD의 임원진에서는 이것이 늦었다는 것을 인지하고 있다. Intel의 Clovertown은 쿼드코어 기기이다. OS는 Clovertown이 4개 프로세서라는 것을 인지하며, 이것은 확실히 듀얼코어 MPU보다 많은 어플리케이션에서 더 높은 성능을 제공하게 된다. 그러나, 대부분의 상황에서 성능은 완벽히 단일화된 쿼드코어 만큼의 성능이 나오게 된다.

Barcelona의 경우, 엄청난 집적의 장점은 I/O 대역폭에 집중하여 주장이 되어왔었다. Barcelona의 메모리 컨트롤러가 주로 완전히 분해되어 분석되었다. 가장 가시적인 변화는 각기 컨트롤러가 128비트 전송을 두 컨트롤러를 통해 지원하는 것 대신 독립적인 64B 전송을 지원하는 것이다. (현재는 메모리 미러링 또한 지원된다.) DDR2 는 버스트가 32B에서 머물게 되므로, 이것은 명령어 효율을 향상시키게 된다. 그러나, DDR3를 사용할 때에는, 이 명령어 효율이 떨어지는데 버스트 길이가 두배가 되어 64B가 되기 때문이다. 각기 컨트롤러는 또한 DRAM 상에서 열린 페이지의 분리된 세트를 지원하는데, 이것은 새로운 기록 기반 패턴 예측자에 의해 제어된다. (이것은 마치 간단한 분기 예측자와 유사한 성격을 가진다.) 이 예측자는 뱅크 당 접근 기록과 뱅크를 통한 페이지 접근 모두를 사용하여 성능을 향상시키기 위해 페이지를 열린채로 두느냐 아니면 전력을 줄이기 위해 페이지를 닫느냐를 결정하게 된다. 마지막으로, Barcelona는 데이터 오염을 소개하였는데, 이것은 ECC에서 두개 비트 에러가 발생하였다면, 이것을 제한시켜 첫번째로 이것에 접근하는 프로세스에만 영향을 끼치고 전체 시스템의 크래싱이나 오염을 막을 수 있게 한다.

리비젼 F Opteron 프로세서들이 DDR2를 지원했었는데, 여기에서는 있어도 아주 적은 성능상의 이점이 있었다. 실제적으로 DDR2의 가용 대역폭에서 장점을 취하려면, 더 깊은 요청/응답 큐가 필요했다. ; 이들 변화는 리비젼 F에서 되지 않고, Barcelona에서 나오게 되었다. AMD는 또한 16~20 엔트리의 쓰기 버퍼를 메모리 컨트롤러에 넣어 소개 하였는데, 이로써 쓰기 지연이 가능해져, 버스가 불필요하게 사용되는 것을 피할 수 있다. 마지막으로, 메모리 컨트롤러는 이제 DRAM 프리페쳐를 지원하여 쓰기 버퍼를 공유하며, 이로 인해 긍정적이고 부정적인 면을 찾아낼 수 있게 되었다. 서버버젼의 Barcelona는 최대 667Mhz의 레지스터드 DIMM을 지원하며, 데스크탑 버젼은 약간 더 빠른 800Mhz DDR2를 지원할 것이다.

Barcelona는 또한 내부 프로세서 통신과 I/O 기기를 위한 네번째 Hypertransport 레인을 추가하였다. 네개의 레인으로 인해, 시스템 벤더들은 완벽히 연결된 4소켓 시스템을 만들 수 있게 되었다. ; 이것은 비약적으로 전송 지연시간을 줄이는데, 왜냐면 모든 프로세서들이 한번의 hop으로 다른 프로세서에 도달할 수 있기 때문이다. 시스템 내의 각기 노드는 I/O 허브까지 에도 접목될 수 있다. 그러나, 현재 소켓 인프라 기반은 오직 3개의 HT 1.1 레인만을 지원하므로, 이들 혁신적인 시스템 설계는 새로운 소켓 인터페이스가 나올 때까지 기다려야 한다. 초기에는, 각기 링크가 2GT/s로 동작하였지만, 이들은 HyperTransport 3.0과 호환되며 차후 새로운 시스템에서는 최대 5.2GT/s까지 동작할 것이다. HT 3.0은 또한 전력을 절약하기 위해 링크 폭과 주파수를 변조할 수 있게 된다. 일관성을 가진 HyperTransport는 또한 약간의 변화를 시켜서 몇몇 전송에서 지연시간에 대한 성능을 향상시켰다. K8이 그들의 L1 데이터나 L2 의 캐시 라인으로 데이터를 가져올 때, 이것은 시스템을 검사하며 결과를 기다리게 된다. 특히, K8은 메모리와 시스템 내의 다른 모든 캐시를 검사하게 된다. ; 이들 응답을 모두 얻었다면, 페치된 캐시 라인을 사용하게 된다. 그러나, Barcelona에서는 만약 요청된 캐시 라인의 상태가 M이나 O 라면, (이것은 메모리가 변조된 사본을 갖고 있다는 의미이다.) CPU는 메모리에서의 검사 응답을 기다리지 않으며, 이로 인해 전송 지연시간에 대한 면이 향상되게 된다. 이 새로워진 프로토콜은 또한 재시도 메커니즘을 추가하여 높은 클럭에서 일시적인 에러를 없애게 된다.

HyperTransport 3.0은 또한 'unganging' 또는 레인 분할이라고 불리우는 기능을 추가하였다. 이 HT 3.0 링크들은 실제적으로 각기 방향마다 16비트로 동작하는  레인으로 구성되었다. 이들 레인은 독립적인 8비트 폭 링크의 쌍으로 분리될 수 있다. 이것은 I/O 기기에 연결할 때에는 아주 유용한데, 몇몇 시스템은 8GB/s 라는 인터페이스로도 I/O 기기에 연결하기에 포화될 정도로 충분하기 때문이다. ; 심지어 8 개의 SAS 하드 드라이브와 10GBE 카드 한쌍이라도 이 대역을 요구하진 않는다. 그러나, AMD는 또한 이 링크 분할을 완벽히 내부 연결된 8 소켓 서버를 만들기 위해 만들었다. 이전 세대의 Opteron 기반 시스템은 최대 8소켓까지 지원하였지만 성능은 몇몇 벤치마크에서 공표한 것에서는 확실히 밑돌았었다. (주로 SAP 2단계와 SPECjbb2005) Barcelona는 8소켓에서 도입되면 더 높은 성능을 제공할 것인데, 최종 사용자에게서 얼마나 수요가 있을지는 명확치 않다. Sun과 Fujitsu는 현재 8소켓 서버를 판매하고 있지만, HP와 Dell은 2003년 일찍 판매를 하였었다.

3페이지

Fetch 국면

아래 Figure 2에서 보이는 것과 같이, Barcelona의 프론트 엔드는 엄청나게 복잡하며 K8에 비해 상당한 향상을 이루었다.각기 싸이클에서, Barcelona는 L1 명령어 캐시에서 predecode/pick 버퍼로 한번에 32B의 명령어를 가져온다. 이전 세대 K8은 각기 사이클에서 16B 만큼 가져왔는데, Intel의 Core 2와 동일하다. 명령어 페치는 대부분의 SIMD와 64비트 명령어가 길어지고, 이것들이 더욱 일반화되어, 나머지 코어를 바쁘게 만들기 위해 더 큰 페치 양이 필요 해졌기 때문에 늘어나게 되었다. 이에 따라, Barcelona에서의 pre-decode와 픽 버퍼는 늘어났는데, 얼마만큼 늘어났는지 정확히는 몰라도 최소한 32B 이상은 된다. - K8의 predecode 버퍼는 페치 크기의 1.5배여서, 48B 이상은 되지 않을 것이다.

이것으로 인해 Barcelona가 첫번째로 목표를 잡은 것이 거의 서버 쪽이라는 것을 이해할 수 있는데, 여기는 64비트 모드가 일반적이기 때문이다. 반면 Core 2는, 컴퓨터 시스템의 주 구매층인 소비자 쪽으로 초점을 맞추어 설계되었다. 이런 현실은 현재까지도, 64비트 OS가 이상하게도 데스크탑에서는 희귀하며, 특히 노트북에서는 더욱 희귀하다. ; 이들 세부 시장에서, 추가적인 이득은 더욱 제한되며 자원의 우세성도 없을듯 하다.


Figure 2 - 마이크로 아키텍쳐 프론트 엔드의 비교

K8 내의 분기 예측 또한 심층적인 정밀검사를 받았다. K8은 이중 형태 예측자와 전역 예측자 중 한가지를 선택하여 사용하는 분기 선택자를 사용했었다. 이 이중 형태 예측자와 분기 선택자 들은 명령어 캐시의 ECC 비트에 저장되는데, pre-decode 정보의 형태를 띈다. 전역 예측자는 전역 기록 레지스터와 함께 상황적인 분기를 위해 상대적 명령어 포인터 (RIP) 를 혼합하는데 이것으로 최근 8개 분기를 16K의 엔트리 예측 테이블로 2비트의 포화 카운터를 같이 넣어 색인을 시키게 된다. 만약 분기가 취해진 으로 예측되면, 이 목표는 2K의 엔트리 목표 배열에 들어가게 된다. 간접 분기는 배열의 한개 목표만을 사용하는데, CALL 들은 이 목표를 사용하며 또한 반환 주소 스택을 갱신한다. 분기 목표 주소 계산자 (BTAC) 는 상대적 분기에 대한 목표를 확인하며, 목표 배열에서의 예측을 수정할 수 있는데, 2개 사이클 페널티를 가지게 된다. 반환되는 것들은 12 엔트리 반환 주소 스택으로 예측된다.

Barcelona는 분기 예측을 근본적으로 바꾸지 않지만, 정확도를 향상시킨다. 전역 기록 레지스터는 이제 8개에서 12개의 최근 분기를 추적할 수 있게 되었다. Barcelona는 또한 새 간접 예측자를 추가하였는데, 이것은 (switch나 case 구문 같은) 제한적으로 다수의 목표를 가진 분기를 조종하기 위해 설계된 것이다. 간접 분기 예측은 Intel의 Prescott 마이크로 아키텍쳐에서 처음 소개 되었고 최근에는 Pentium M에서 나왔다. 한개 목표에서의 간접 분기는 여전히 현존하는 2K 엔트리 분기 목표 버퍼를 사용한다. 512 엔트리 간접 예측자는 간접 목표가 예측 실패를 하였을 때 위치되게 된다. ; 목표 주소는 전역 분기 기록 레지스터와 분기 RIP에 의해 색인화 되므로, 간접 분기와 자기 자신의 분기 주소 를 접근하는 데 쓰였던 경로를 고려해야 한다. 마지막으로, 반환 주소 스택은 두배로 24엔트리가 되었다.

몇몇 PC 게임에서의 우리 고유의 측정에 따르면, 16~50% 정도의 모든 분기 예측 실패는 간접적인 것이었다. (평균 29%) 간접 분기 예측 실패에 대한 실제 값은 Ruby, Perl이나 Python 같이 인터프리터를 사용하는 고레벨 언어나 새로운 스크립팅에 적용되게 된다. 다른 일반적인 간접 분기에 대한 일반적인 주범은 (C++에 쓰이는) 가상 함수와 함수 포인터라고 불리우는 것들이 포함되어 있다. 같은 설정의 게임들에서, 우리는 0.5~5% (평균 1.5%) 사이의 값이 오버 플로우로 모든 스택 참조 결과값이 들어가지만, 오버플로우는 서버 작업에서 훨씬 많이 퍼져 있다.

4페이지

디코드 국면

x86 명령어는 확실히 디코드 하기에 복잡하다. ; 이것들은 다양한 길이를 갖고 있으며 이것들은 접두사 때문인데, 이 연산 코드의 위치는 앞서 알아낼 수 없다. 디코딩을 단순화 하기 위해, K8과 barcelona 모두 pre-decode 정보를 이용하여 명령어의 끝단을 표시하게 된다. (이에 따라 다음 명령어의 시작 지점도 알게 된다.) 그러나, 처음에 명령어는 캐시로 페치되며 여기에는 pre-decode 정보가 없다. 명령어 캐시는 pre-decoder를 갖고 있어 이것은 각 사이클마다 4B의 명령어 흐름을 검사 하며, 각기 명령어 줄 마다 있는 L1 명령어, L2와 L3 캐시의 ECC 비트 내에 저장된 pre-decode 정보를 삽입한다. 명령어 스트림에서는 거의 기록이 이루어지지 않으므로, 메모리에서의 패리티와 재페치 과정은 명령어 캐시 내의 에러로부터 충분히 보호를 받으며 ECC는 코드를 실제적으로 요구하지 않게 된다. 이전에 말 했듯이, 이 pre-decode 정보는 또한 분기 선택과 다른 관련 정보까지도 포함하고 있다.

Pentium Pro 같이, K7/8은 확실히 RISC에 가까운, 마이크로 옵스로 구성된 내부 명령어 셋을 가지고 있다. 각기 마이크로 옵은 아주 복잡하며, 한개의 로드와, 연산과 저장을 포함할 수 있다. 3개 이상의 micro-ops로 디코드 되는 (VectorPath 명령어라고 불리우는) 명령어는 pick 버퍼에서 보내져 마이크로 코드 엔진으로 가게 된다. 예를들어, 여느 문자 조종 명령어는 마이크로 크드화 된다. 이 마이크로 코드유닛은 사이클당 3개의 micro-ops를 배출하게 되는데 이것은 x86 명령어가 완벽히 디코드 될 때까지 계속되게 된다. 마이크로 코드 엔진이 디코딩중일 때, 일반적인 디코더는 일을 하지 않게 된다. ; 이 두개는 동시에 동작하지 못한다. 거의 대부분의 x86 명령어는 1~2개의 micro-ops로 해독되며 이것들은 (singles이나 doubles의) DirectPath 명령어로 지칭된다.

Barcelona에서, 128비트 SSE 연산은 이제 2개 대신 1개의 micro-ops로 들어가게 된다. ; 이것으로 하여금 재 명령 버퍼와 예약 구역 같은 나머지 비순차적 장치를 좀 더 효율적으로 만들어준다. 새로운 SIMD 능력을 보완하는 데 필요한 정수와 부동소수 변환과, 128비트 로드 명령 같은 것에도 똑같은 현상이 일어난다. 그래도 128비트 저장은 여전히 2개의 micro-ops를 만들어내는 것은 알아 두어야 한다. AMD가 추가한 또다른 개선점은 정렬되지 않은 SSE 메모리 접근 지원으로, 이것으로 인해 코드를 좀 더 고밀도로 압축함으로 인해 페치 명령을 좀 더 효율적으로 쓰는 데에 도움을 준다.

디코드 스테이지 진행 중 어느 지점에서, 명령어들은 Barcelona에서는 새로운 하드웨어로 통과하기도 하는데, 측대역 스택 최적화기가 그것이다. x86 명령어 셋은 하드웨어 내에서 축적을 지원하며, PUSH, POP, CALL과 RET 명령어들을 사용하여 각 스레드의 스택을 직접적으로 조종할 수 있다. 이들 명령어는 스택 포인터 (ESP)를 변조 시키는데, K8에서는 이것을 micro-op으로 생성 시켰었다. ; 더 안좋은 것은, 보통 이들 명령어는 긴 의존형 체인 형태로 나오는데, 이것은 비순차적 처리기에서는 고통 그 자체이다.

AMD는 측대역 최적화기를 소개하면서 명령어 흐름에서 나오는 이들 스택 조종들을 없앴는데, 이것은 Pentium M의 분리된 스택 엔진과 비슷하다. 이 두 MPU들 모두 ESPO와 ESPD라는 두개의 레지스터를 사용한다. (이것은 Intel에서 지칭하는 단어이다.) ESPO는 스택 포인터에 대한 원래 값이며 비순차 기기 내의 레지스터에 저장이 되는 반면, ESPD는 델타 레지스터로, ESP의 변화량을 추적하며 프론트 엔드에 귀속되어 있다. ESP는 아키텍쳐 레지스터이기 때문에, Barcelona에서는 이런 '조정' 과정이 최소화 되었음에도 불구하고 특별한 micro-op이 ESPO와 ESPD에서 ESP로 복원시키기 위해 제공된다. 스택을 변조시키는 명령어가 검출되면, 이것은 제거되고 ESPD를 변조시키는 분리된 ALU로 인해 해결된다. 이것은 많은 스택 관련 작업들이 병렬적으로 수행되며, 예약 구역, 재명령 버퍼와 일반적인 ALU들을 다른 작업을 하도록 자유롭게 풀어주게 됨을 의미한다. 이 기술에 대한 이득은 높은 부하 의존적인 성향이지만, AMD와 Intel은 보통 5%의 micro-ops가 제거된다고 보고 있다.

디코딩의 마지막 부분은 압축 버퍼이다. (K8 같은 데에서는 아마 여전히 6개 엔트리일 것이다.) 그러나, 압축 버퍼의 방법을 이해하기 위해서는, 어떻게 비순차적 실행이 Barcelona와 K8에서 실제적으로 구동되는가를 자세히 보아야 할 필요성이 있다. ; 그러므로 이 논의는 다음장까지 기다리자.

5페이지

비순차 명령 엔진 - 재명명과 스케줄링

첫번째 느끼는 것은 비순차 제어 회로가 Core 2보다 K8과 Barcelona가 훨씬 더 복잡하다는 것이다. Intel의 마이크로 아키텍쳐와는 다르게, K8과 Barcelona는 정수와 부동소수 클러스터를 분할하였는데, 이것으로 분리된 스케줄러/예약 구역을 갖게 된다. Core 마이크로 아키텍쳐는 이전에 논의 했던 것과 같이, 통합 스케줄러/예약 구역과 다수의 전송 포트와 함께 한개의 실행 클러스터를 갖고 있다. ( http://gigglehd.com/zbxe/special/1205413 ) P6과 Athlon 시절로 날짜를 되돌아가는 듯한 이런 선택들은, 부동소수 부하량에 있어 AMD 마이크로 프로세서들이 강함을 보여주는 주된 원인 중 하나이다.


Figure 3 - 비순차 명령 자원의 비교

디코딩 국면에서의 압축 버퍼 부분은, 정확히 3개 micro-ops의 그룹을 재명령 버퍼에 (ROB) 보내야 하는 책임을 안고 있다. 그러나, 72개의 명령어 재명령 버퍼는 실제적으로 72개의 독립적인 엔트리를 가지고 있지 않다. 이것은 24개 엔트리를 가지고 있으며, 각기 엔트리 내에 명령어를 위한 3개의 레인을 갖고 있다. 재명령 버퍼는 수행중인 각기 작업에 대한 결과를 위해 재명명 레지스터를 가지고 있다. (또는 FP 작업의 경우, FP 레지스터 파일에 대한 포인터를 가지게 된다.)

ROB가 완벽하게 사용되게 하기 위해, 정확히 3개 명령의 1개 그룹이 각 사이클마다 ROB에 보내지게 된다. 그러므로, 압축 버퍼의 기능은 두 가지이다. ; 세 개의 명령어들을 한개 그룹으로 합체 시켜 ROB에 들어갈 수 있게 만드는 것이다. 중요한 것으로는, 압축 버퍼는 레인 간 명령어를 이동 시킬 수 있어 예약 구역의 다운스트림의 혼잡을 피하거나 전송 제약을 감시한다는 것이다. 예를들어, 부동소수나 정수 곱셈은 첫번째 레인에서 꼭 일어나야 하는데, LZCOUNT는 세번째 레인에서 일어나야 한다. 각기 레인은 파이프라인을 타고 내려가면서 특정 예약 구역에 상응되며, ROB 내에서 명령어가 특정 레인으로 진입하면, 이것은 옮겨질 수 없다. 그러므로 압축 버퍼는 또한 명령어를 위한 레인 전환에 있어 마지막 기회를 제공하는 셈이기도 하다.

이 때, 부동 소수와 정수/메모리 명령어에 대한 경로가 갈리게 된다. 정수 측에서 다음 장애물은 Integer Future File and Register File (IFFRF) 이다. IFFRF는 40개의 레지스터를 3개의 분리된 셋으로 갖고 있게 된다. 첫번째로, 아키텣겨 상의 레지스터 파일로써, 이것은 x86-64 명령어 셋으로 규정된 16x64 비트의 비추론적인 레지스터를 갖고 있다. 명령어들은 이들이 완료될 때 아키텍쳐적 레지스터 파일을 한번 변조시킬 수 있을 뿐이다. 16개의 설계적 명령에 대한 최근 추론 상태를 포함하는 추론 명령은 Future File에 읽어와서 쓰는 것을 대신 한다. 마지막 8개 레지스터들은 스크래치 패드 레지스터로써 마이크로 코드가 쓰게 된다. 분기 예측 실패나 예외의 경우, 파이프라인은 꼭 뒤로 돌아가야 하며, 설계적 레지스터 파일은 Future File의 내용을 덮어쓰게 된다.

ROB에서, 명령어는 적절한 스케줄러에 발행된다. 정수 클러스터는 세개의 예약 구역 (이나 스케줄러) 를 갖게 된다. 각기 하나씩은 ROB 내의 특정 레인에 묶이며 8개의 명령어를 갖게 되는데, 원본 피연산자를 포함한다. 이 원본 피연산자는 Future File이나 앞선 버스의 결과에서 오게 된다. (이것은 그리기에 너무 복잡하기 때문에 보여주지 않겠다.)

부동소수 클러스터

부동소수 명령어들은 동떨어진 방법으로 조종된다. 예약 구역으로 바로 보내지지 않고, 이들은 처음으로 FP Mapper와 Renamer로 발걸음을 옮긴다. x86 명령어 셋의 짜증나는 외양 하나가 부동소수 작업이 스택 기반이라는 것이다. ; FP mapper는 이들 스택 작업을 평평한 레지스터 파일로 변환하여 재명명이 일어날 수 있도록 한다.

재명명자 내에서는, 120개의 부동소수 레지스터 파일에서 나온 최대 3개의 부동소수 명령어들이 사이클마다 목표 레지스터로 지정된다. 이 파일은 동작 중 최대 72개의 명령어까지 재명명을 할 수 있을 정도로 충분히 크다. 부동소수 레지스터 파일은 두개의 배열이 있는데, 설계적, 그리고 future 파일 배열이 있다. Barcelona에서, 설계적 파일 배열은 120개의 부동소수 레지스터 중 44개의 포인터를 갖고 있으며, 이것은 비추론적인 상태를 띄고 있다. : 8개는 x87/MMX, 마이크로 코드를 위한 8개의 스크래치 패드 레지스터와 8x128 비트 XMM 레지스터가 있는 것이다. 이전에, K8은 XMM 레지스터를 16x 64 비트 레지스터로 간주 했지만, '네이티브한' 데이터 포맷을 위해 128비트로 바뀌었다. 비슷하게, future 파일은 44개의 재명명된 레지스터 포인터를 갖고 있어 부동소수 레지스터 파일 내에 가장 최근 추론 값을 갖게 된다.

micro-ops가 한번 재명명되면, 이들은 3개의 부동소수 스케줄러로 전송된다. 각기 예약 구역은 원본 피연산자와 함께 최대 12개의 명령어까지 저장할 수 있다. 정수 스케줄러와 같이, 피연산자는 부동소수 레지스터 파일이나, 전면 네트워크에서 올 수 있으며 각기 스케줄러는 ROB의 특정 레인에 귀속되어 있다.

6페이지

비순차 명령 엔진 - 실행 유닛

작업이 스케줄러에 진입하면, 이들은 원본 피연산자가 준비될 때까지 기다리게 된다. 그리고 스케줄러는 가장 오래된 명령어와 피연산자를 적절한 기능 유닛에 보내게 된다. Barcelona의 정수 기능 유닛은 K8에서 가장 변경이 없는 유닛이다. K8 과 Barcelona 내의 세개의 정수 ALU들은 대부분의 명령어를 실행할 수 있으며 대칭적이다. 두가지 예외라곤 첫번째 ALU만이 정수 곱셈기를 가지고 있다는 것과, 세번째는 POPCOUNT와 다른 비슷한 명령어에 쓰인다는 것이다. Barcelona의 전면 네트워크는 이런 조직도 도시 방법으로는 너무 복잡하여서 생략됐음을 주의하라.


Figure 4 - 실행 유닛의 비교

Barcelona의 정수 유닛에서 첫번째로 실질적으로 변화한 것은 정수 나눗셈이 이제 피연산자에 의존하여 다양한 지연시간을 가지게 되었다는 것이다. IDIV 명령어는 되풀이 알고리즘을 통해 조종된다. K8에서, 각기 IDIV는 정해진 횟수만큼 반복을 하게 된다. - 최종 값을 따기 위해 얼마나 많은 횟수가 요구되는지는 상관하지 않는다. 32비트 나눗셈은 42사이클을 소비하는 반면, 완벽한 64비트 나눗셈은 연산에 74사이클이 요구된다. 반면에, Barcelona는 정확한 답변을 만들어 내기 위해 최소한의 횟수만큼의 반복만 하게 된다. Barcelona의 지연시간은 일반적으로 23사이클이며, 여기에 피제수 절대값 내의 확실한 비트의 숫자만큼이 더해진다. (부호가 없는 나눗셈의 경우 대략 10 사이클정도 빠르다.) 추가적으로, 세번째 ALU 파이프라인은 이제 새로운 LZCOUNT/POPCOUNT 명령어를 제어할 수 있게 되었다.

Barcelona의 부동소수 유닛도 약간 바뀌었다. 이들은 128비트로 폭이 늘어나면서 SSE 명령어가 한번에 실행될 수 있게 되었다. (이전에는 이들은 Intel의 Pentium M 같이 64비트 부동소수 유닛을 두번 통과 하였다.) 비슷하게, 로드-스토어 유닛과, FMISC 유닛도 이제는 128비트 폭 데이터를 로드할 수 있게 되어, SSE 성능이 향상되었다.

AMD와 Intel의 마이크로 아키텍쳐 간 중요한 차이점은 AMD는 그들의 주소 생성 유닛이 (AGU) 로드 스토어 유닛과 (LSU) 분리되어 있다는 것이다. 이것은 우리가 이전에 언급 하였던 것과 같이, AMD의 micro-ops 는 로드, 작업과 저장을 가질 수 있기 때문에, 여기에는 최소한 ALU들이 있는 만큼 AGU가 있어야 한다. 이와는 반대로, Intel의 uops는 메모리 접근으로부터 완벽히 떨어진 연산을 함에 따라, AGU들은 로드/스토어 파이프라인 내로 집적되게 된다. uops와 micro-ops 에 깔려 있는 차이점으로 하여금 각기 다른 AGU 배열을 초래하게 된다.

Barcelona와 Core 마이크로 아키텍쳐 사이의 또다른 차이점은 AMD의 ALU가 대칭적이며 거의 모든 정수 명령어를 실행시킬 수 있는데 반해, Core 2의 ALU들은 대칭적이지 않으며 약간 더 제약이 있는 편이다. 각기 레인들은 작업을 최적화 하기 위해 AMD의 분배형 스케줄러와 명령어 그룹화에 대해 거의 동일해야 한다. 이것은 명백히 설계상에서 성능과 낮아지는 제어 복잡성과 전력과 늘어난 실행 복잡성을 기회 비용으로 바꾼 것이다. 완벽한 기능을 갖춘 세 개의 ALU들은 더 많은 다이 면적과 전력을 사용하지만, 특정 경우에 더 높은 성능을 제공하며, ROB와 스케줄러의 설계를 좀 더 단순하게 할 수 있게 한다.

7페이지

메모리 시스템

Barcelona의 메모리 파이프라인과 캐시는 확실히 개정되었다. ; 이들은 이제 약간의 제한된 비순차 명령 능력을 가지게 되었으며 각기 파이프는 128비트 로드나 64비트의 스토어를 매 사이클마다 수행할 수 있게 되었다. K8과 Barcelona 모두에서의 메모리 작동은 정수 스케줄러에서부터 시작하며, AGU와 12엔트리의 LSU1 에 보내지게 된다. 주소 생성에는 한개 사이클이 소요되며, 이 결과는 데이터 접근을 기다리는 LSU1 으로 향하게 된다.


Figure 5 - 메모리 파이프라인의 비교

이런 시점에서는, Barcelona와 K8의 행동거지는 갈리게 된다. K8에서는, 메모리 접근은 순차 처리 방식으로 진행되었었고, 그로 인해 로드가 나오지 않는다면, 모든 뒤따르는 로드나 저장 작업 또한 작업이 실행되지 않아 성능이 떨어지게 된다. Barcelona는 비추론적 메모리 접근 재명령을 제공한다.

전송 국면에서는, 로드 작업의 주소에서 낮은측 12비트가 선행된 저장 주소에 대해 테스트된다.; 이들이 만약 다르다면, 로드 작업은 저장에 선행되어 진행되며, 이들이 같다면, 이들은 로드-저장 진행에 대한 기회가 생기게 된다. 이것은 P6의 메모리 재명령 능력과 동등하다. - 로드는 또다른 로드에 대해 선행될 수 있으며, 로드는 무조건 각기 다른 주소를 접근할 시에 저장에도 선행될 수 있다. Core 2와는 다르게, 여기에서는 예측이나 복원 메커니즘이 없으며 알려지지 않은 주소에 저장하려는 작업을 로드가 앞설 수 없다.

12엔트리의 LSU1에서, 가장 오래된 작업이 L1 DTLB를 사용하여 그들의 주소를 가상 주소 영역에서 물리 주소 영역으로 변환한다. 이 L1 DTLB는 이제 1GB 페이지에 대해 8개 엔트리를 포함하게 되는데, 이것은 큰 작업량 셋을 가지는 데이터 베이스나 HPC에서 유용하다. L1 DTLB에서 실패가 나온다면 L2 DTLB를 검사하게 된다. 물리주소가 한번 발견된다면, 두개의 micro-ops로 하여금 각기 사이클마다 캐시에 대해 (저장의 경우에는) 조사를 하거나 (로드의 경우에는) 읽어올 수 있으며, 로드와 저장의 어떤 혼합도 가능하다. 한번의 사이클에 2개의 128비트 로드를 할 수 있는 능력은 주로 두번째 포트가 대역폭에 대해 여유로워지는 HPC에서 이로울 것이다. 한번이라도 로드나 저장이 캐시에서 조사 된다면, 이것은 LSU2로 옮겨가게 된다.

LSU2는 최대 32개의 메모리 접근을 가질 수 있는데, 이것들은 완료될 때까지 머무르게 된다. LSU2는 파이프라인 내의 대부분의 복잡한 것들을 조종한다. 이것은 캐시나 TLB 미스를, 필요한 구조를 스케줄링하고 조사함으로써 해결한다. 캐시 미스의 경우, 이것은 L2, L3나 메모리로 등급을 올려가는데, TLB 미스는 L2 TLB나, 페이지 테이블에 남아있는 메인메모리로 가게 된다. LSU2는 또한 저장 명령을 갖고 있는데, 정확성을 확보하기 위해 완료 전까지는 실제적으로 캐시를 변조하지 못한다. 모든 저장이 LSU2 에서 일어나기 때문에, 이것은 또한 로드-저장 진행도 하게 된다. 저장은 여전히 64비트 폭이라, 두 개의 엔트리가 완전한 128비트 SSE 기록을 추적하는데 쓰이는 것을 알아 두어야 한다. 이것은 몇몇 명령어 순서에서는 약간의 단점으로 작용할 수 있는데, 특히 메모리 내의 데이터를 일기와 쓰기를 같은 횟수로 카피하는 것이 포함된다. 그러나, 일반적인 추세는 어플리케이션 내에서 저장보다 로드가 두배 이상 많다.

64KB의 L1D 캐시는 2방향 연관성을 가지고, 64바이트 라인이며 3사이클의 접근 시간을 가진다. 이것은 write-back 정책으로 L2 캐시로 넘기기에, L1은 배타적인 캐시가 된다. L1D 캐시에서 나오는 것과 내부 데이터 경로 또한 256비트로 넓어져서, (128비트 전송과 128비트 수신) 64바이트 라인은 4사이클에 걸쳐 전송된다. K8에서는, L2 캐시는 각 코어 마다 따로 사용을 하였었다. L2 용적은 512KB로 반토막 났지만, 라인 크기와 연관성은 64B와 16방향으로 유지되었다.

Barcelona의 L3 캐시는 AMD에게는 완전히 새로운 기능이다. 이 공유된 2MB의 L3 캐시는 32방향 연합성을 가지며 64B 라인을 사용하지만, Figure 5에는 표시되지 않았다. 캐시의 컨트롤러는 유연하며 다양한 AMD의 문서에서 가리키기를 이것은 유연성으로 인해 최대 8MB의 L3 캐시까지 제어할 수 있다고 한다. L3 캐시는 데이터 공유를 염두에 두고 특이하게 설계 되었다. 이것은 AMD의 전통적인 캐시 위쳬에서 세가지 특이한 변화를 일으켰다. 첫번째로, 이것은 대부분 배타적 정책이지만, 완전한 배타 정책은 아니다. L3 캐시의 캐시 라인이 L1D 캐시로 보내졌을 때, 캐시 라인이 공유되었거나 공유된 것 같다면, 이 데이터는 L3 에도 남게 된다. - 완벽히 배타적인 위계에서는 절대 일어나지 않는 중복이 나오게 된다. 페치된 캐시 라인은 코드를 갖고 있거나, 데이터가 이전에 공유 되었다면 (공유 기록은 추적된다.) 캐시간 공유되는 경향을 보인다. 두번째로, L3 의 제거 정책 또한 바뀌었다. K8 내에서, 캐시 라인이 메모리에서 가져와지면, pseudo-least 최근 사용 알고리즘으로 하여금 캐시 내의 가장 오래된 라인을 제거할 것이다. 그러나, Barcelona의 L3에서는, 교체 알고리즘이 공유를 고려하여 바뀌게 되어, 공유되지 않은 라인의 제거를 선호하게 되었다. 마지막으로, L3는 네개의 다른 코어간 공유되기 때문에, L3로의 접근은 꼭 중재 되어야 한다. round-robin 알고리즘이 네 개 코어 중 한개의 코어에 사이클마다 접근 권한을 주는 데 사용된다. L3 캐시의 지연시간은 밝혀지지 않았지만, 이것은 상대적으로 노스브릿지와 코어의 주파수에 의존하게 된다. - 이 이유는 이후에 보게 될 것이다.

Barcelona 내의 메모리 파이프라인에 대한 마지막 향상점으로는 프리페쳐가 있다. 각기 코어는 8개의 데이터 프리페쳐를 가지고 있는데, (기기당 총 32개) Barcelona 에서는 프리페치된 데이터가 L1D 캐시에 들어가게 된다. K8 에서는, 프리페치 된 결과가 L2 캐시에 들어갔었다. Barcelona의 명령어 프리페쳐는 최대 2개의 눈에 띄는 페치를 어떠한 주소에서도 가져올 수 있는데, K8은 한개 페치는 기수 주소와 한개 페치는 우수 주소에서 가져와야 하는 제약이 있었다.

8페이지

회로 기술, 전력 절약과 나머지

회로 레벨의 관점에서, K8과 Barcelona 간의 차이점은 극도로 명확하다. Barcelona는 폭넓은 영역의 전압에서 구동되도록 정해졌는데, 0.8~1.4v까지이다. 그러나, 이들 전 세대 프로세서와는 달리, Barcelona의 각기 코어는 (PLL을 포함하여) 분리된 클럭 분배 시스템과 전력 공급 체계를 가지고 있다. 각 코어의 주파수는 다른 코어들과 독립적이 되며, 다양한 코어 외 영역이 있다. ; 모든 네개 코어의 전압이 공유 되지만, 코어 외 영역과는 분리되어 있다. 그 결과, 전력은 주파수와 전압을 언제든지 낮출 수 있게 되어 공격적인 관리가 가능해졌다. 독립된 클럭과 모듈러 설계를 지원함으로 인해, 비동기 동적 FIFO 버퍼가 각기 다른 코어들과 노스브릿지/ L3 캐시간 통신에 쓰인다. 이들 FIFO들은 전역 신호 비일치나 클럭 비율 변화를 제거하지만, 여기를 통과하는 데 걸리는 지연시간은 이 비일치와 주파수 변화폭에 의존한다. - 이것이 L3 캐시의 지연시간이 변화폭이 있는 이유이다. 노스브릿지와 L3 캐시가 혼합되면 대략 20%의 다이 면적을 차지하며 전압 공유와 클럭 도메인은 네개 코어와 독립적인데, 이것은 이동형 어플리케이션 분야에서 아주 핵심적인 것이다. 이전에는, 노스브릿지 클럭과 전압이 프로세서에 묶여있어서, 내장 그래픽을 채용한 시스템은 깊은 전력 절약 상태에서 프로세서 전압이나 주파수를 줄일 수 없었다. 분리된 슬립 상태로, 노스브릿지와 프로세서의 전압과 주파수는 AMD의 평균 전력 소모량을 낮출 수 있었고 이것으로 인해 이동형 시장에 도움이 되었다.


Figure 6 - Barcelona Die Micrograph

Barcelona는 또한 각기 코어마다 분리된 온도 센서 회로를 가지고 있으며, 분리된 한개는 노스브릿지에 있다. 각기 코어는 회로 상에 8개의 센서를 갖고 있으며, 노스브릿지는 6개를 가지고 있다. 모든 회로들은 연결되어 있으며 전역 온도 제어 회로에 의해 제어된다. 전역 온도 제어기는 이 결과를 통해 전력 절약 방식을 선택하여 기기의 온도를 낮추게 된다.

AMD의 설계 팀에서 까다로운 영역을 꼽으라면 캐시에 대한 SRAM 셀이었다. L1 캐시는 보통 1.06 제곱 마이크로미터 정도의 셀 설계를 공유한다. 6T SRAM 셀은 사이클의 첫 반 주기를 읽는데 쓰며, 그 후 자동 지연 쓰기를 수행하고 나머지 사이클을 재충전에 쓴다. 기록에 쓰이는 시간은 확장된 Monte Carlo 분석에 기반하며, 다대 다 변조와 지연 공정 변조의 혼합과 프로그램 가능한 퓨즈로 인해 생산후 변조가 가능하다.

L2와 L3 캐시는 많은 설계 요소들을 공유하는데, SRAM 셀도 포함된다. L2/3 셀은 0.81 제곱 마이크로미터이며 또한 안정성을 위해 낱개 마감이 되어 있는데, 이것은 비범한 것이다. AMD의 SRAM 설계자가 직면한 난점 중 하나는 모든 제품 라인에 같은 다이를 사용하기 떄문에, (잘못된 데이터를 읽는 것같은) 읽기 혼란과 비슷한 것이 아주 적어야 한다는 것이다. 구체적으로 말하면, 다섯개를 합한 여유폭이 대략 모두 0.7~1.3v 영역 정도가 요구된다. 불행하게도, SOI 기판의 floating body 효과는 작은 스윙 읽기 설계에서 더욱 효율적이기 위해 배제시킨다. AMD의 프리젠테이션에 의하면, 작은 스윙 읽기 셀을 사용함으로써, 이들은 4.53 시그마 여유를 취할 수 있었다고 한다. 낱개 마감 설계를 고른 것은 더 큰 여유를 남겨 실제 제품 사용에 충분하다는 것이었다.

소프트웨어적으로 파생된 문제로 넘어가보자. ; Barcelona는 또한 새로운 다양한 명령어를 추가적으로 지원한다. 운이 좋게도, 이들은 Core 2에 Intel이 추가 보충하는 SSE 명령과 보완된다. 일반적으로, 이들 명령어들은 주어진 레지스터에서 0들이나 1들 숫자만을 세고 있는 정보국이 지속적으로 사랑하고 있는 POPCOUNT 를 제외하고는 그렇게 중요하지 않다. 이전에 언급 했던 것과 같이 AMD는 또한 정렬되지 않은 SSE 로드를 지원하는데, 이것은 Intel이 그들의 선두를 따라갈 것인지를 보는 것도 재밌을 것이다.

서버 유저에게 더욱 확실한 것은 nested 페이지 테이블로, 이것은 가상화 성능을 향상시킨다. 쉐도우 페이지 테이블의 한가지 약점이라면 페이지 실패에 대한 댓가가 아주 비싼데, VMM이 쉐도우 페이지 테이블의 변화 사항을 불러내어 관리하기 때문이다. 이에 대한 대책으로, Barcelona에 쓰이는 nested나 확장 페이지 테이블은 메모리 관리 유닛을 가상화 시킨다. Barcelona에서 각 게스트는 하드웨어 발자취 표를 관리하여 게스트의 물리 주소를 호스트의 물리 주소로 매핑 한다. 불행하게도, 이런 표를 만드는 것은 비정상적으로 댓가가 커서, 매핑의 부분은 캐싱되어야 한다. 이것이 가상화의 중첩으로 인해 성능을 떨어트리는 반면, 고객들은 I/O 가상화를 기다릴 것이며 2008년까지 기다리면 이 특이한 기능이 나올 것이다.

9페이지

Barcelona 요약

AMD의 현재 경쟁 상황은 더욱 어렵다. 고성능 MP 서버와 몇몇 HPC에서는, AMD는 여전히 왕좌를 꿰차고 있다. 그러나, 대부분 모든 부문에서 Intel은 성능과 가끔은 전력 효율까지 선두를 달리고 있다. 이것은 명확히 재정상의 문제로 AMD에게 해석되는데, 고성능 서버 시장에서는 여전히 작고 (그러나 유리하다) HPC는 일반적으로 가격대가 아주 경쟁적이다. 이 상황이 Opteron 발표 이전의 상황을 연상케 하는 상황인 반면, 많은 방면으로 AMD는 2003년에 처했던 것보다 더 좋은 위치에 가있다.

2003년 초에, AMD는 서버 시장에서 두각을 나타내지 못했으며, 기록 자체가 없기 때문에 특별히 신뢰할만한 사업체가 아니었다. 게다가, AMD는 심지어 서버 벤더들을 특히 끌어 들이는 특별한 힘도 없었다. 오늘날, AMD는 서버 세계에서 알려진 참가자이며, '2인자' 라는 인식도 없다. AMD는 또한 완고한 타협 거부자인 Dell 같은 주력 OEM 회사 에게도 명백히 판매와 광고 면에서 활로를 찾아가고 있다. 동시에, AMD는 그들의 채널 파트너들에게 아주 심한 실수를 하였다. - 몇몇 Opteron을 밀어준 얼리 어댑터들과 위험 감수자들에게 그랬으며, Intel은 최근 공격적으로 채널 파트너들을 고소하였다.

최근, AMD는 Barcelona에 대한 주파수와 예상 성능의 힌트를 아주 조금만 주고 있다. AMD는 공식적으로 (2.66Ghz 쿼드코어) Xeon 5355를 SPECfp_rate 2006에서 50%, SPECint_rate2006에서 20% 이상의 이점을 가질 것이라 예측 한다고 공표 하였다. 물론, AMD의 경쟁자 Intel은 Barcelona가 귀환하면 더 빠른 3Ghz 프로세서를 내놓을 것이며, 1.6Ghz 버스를 사용한 3.2Ghz의 Penryn 기반 설계가 후에 나올 것이다. 더욱 중요한 것은, SPECint와 SPECfp는 오직 Intel과 AMD에게 부하량에만 중점을 둔다는 것이다.

AMD가 아직 주파수나 TDP에 관한 것을 밝히지 않은 반면, 루머로써는 1.9~2.6Ghz 정도에 100Mhz 단위로 TDP는 68, 95, 그리고 120W를 가질 것이라 한다. 추가적으로, AMD는 프로세서의 수명이 지나갈수록 Barcelona의 주파수를 올릴 것인데 그들의 제조적 측면의 이유 때문이다. AMD는 계속적으로 그들의 공정을 향상시키려 하며, 이들 향상점은 그들 프로세서의 속도를 점진적으로 향상시키는 것으로 이어진다.

아래 K8, Core 2와 Barcelona 이렇게 세가지 마이크로 아키텍쳐를 비교해서 보면, 성능상의 힌틀르 볼 수 있게 된다. 가장 중요한 기능 들의 많은 것들이, AMD와 Intel이 마이크로 아키텍쳐 적으로 일치 하는데 AMD는 Intel이 Core 2에서 클럭당 효율을 늘리려고 사용했던 몇몇 기술들을 협력해서 사용 하였기 때문이다. Core 2가 Barcelona 보다 33% 더 폭이 넓어 보이는 반면, 현실적으로, 실 코드 상에서는 어떠한 프로세서들도 최고 능력에 가깝게 가지 못하는데, 그러므로 성능은 블럭 다이어그램이 암시하는 것에 가깝게 다다를 것이다. Barcelona의 3개 폭 전송, 실행과 완료 능력은 성능상의 문제가 되지 않는다.





Figure 7 - 마이크로 아키텍쳐 비교

주어진 모든 정보와, 현존하는 Intel과 AMD의 기술적인 강점과 약점을 모두 알고 있다면 올해 후반에 경쟁 국면이 어떻게 될지 예상할 수 있다. 고레벨에서 Barcelona는 멀티스레드 성능에서 바짝 따라갈 것이지만, 넘지는 못할 것이다. 클럭 속도에 의존하여, Intel은 싱글 스레드 성능에서는 성능상의 왕좌를 유지할 것이다. - 이것은 클라이언트 시스템에 꼭 필요하다.

[1] Moore, Chuck. Redefining Performance Through System Balance. Spring Processor Forum, 2006.
[2] Sander, Ben. Optimizing the Microprocessor for System-Level Performance. Fall Processor Forum, 2006.
[3] Dorsey, J. et al. An Integrated Quad-Core Opteron Processor. International Solid-State Circuits Conference Technical Digest, February 2007.
[4] Searles, S. An Integrated Quad-Core Opteron Processor. International Solid-State Circuits Conference, February 2007.
[5] Conway, P. et al. The Opteron CMP NorthBridge Architecture, Now and in the Future. Hot Chips XVIII, August 2006.
[6] Software Optimization Guide for AMD Family 10h Processors. May, 2007.
[7] de Vries, Hans. Understanding the Detailed Architecture of AMD’s 64 bit Core. Chip Architect, September, 2003.

http://www.realworldtech.com/page.cfm?ArticleID=RWT051607033728&p=1