PowerPC 970 Redux: Dialogue and Addendum

casaubon · 2003-07-22, 02:22 PM

PowerPC 970 Redux: Dialogue and Addendum

by Jon "Hannibal" Stokes

최근, PowerPC 970의 개발에 관계한 IBM의 엔지니어 두 명과 이야기를 나눌 기회가 있었다. 970의 수석 아키텍트 핏 산던(Pete Sandon)과 컴파일러, 970 최적화 작업을 담당한 데이빗 에델존(David Edelsohn)이 그들이다. 또한 여기에 IBM의 PR 매니저, 릭 보스(Rick Bause)도 있었다. 인터뷰는 필자의 예전 970 기사에 대한 보완과 수정, 확인, 기사에서 말했던 의문에 대한 답변 등에 대한 것이었다. 대부분 우리는 970의 마이크로아키텍쳐와 특히 970의 VMX(즉, 알티벡)에 대해 이야기를 나누었는데, 970의 VMX는 필자의 기사에서 묘사한 내용보다 훨씬 강력하고 융통성이 있었다.

이번 인터뷰에서 앞으로의 예상이라던지, 로드맵은 주제가 아니었다. 그런 질문을 던질 수도 있었지만 만족스러운 답변을 해주지는 못했을 것이다. 그래도 이번 인터뷰는 그런 문제와 관련된 몇 가지 적은 정보는 담고 있으며, 부분적으로 포함시켰다. 일단 주제가 필자의 970 기사에 대한 배경이기 때문에, 표준 Q&A 형식이 아니라, 두 개의 970 기사에 대한 업데이트 형식이라는 점을 양해해주기 바란다. 또한 대화는 시간순이 아니라 주제별로 되어있으며 주제별로 편집을 하였다.

필자는 970에 대한 시리즈 두 번째 기사의 리비전에 여기서 얻은 정보를 삽입할 예정이다(이번달 말쯤에 나오리라 예상한다). 지금으로서는 풀 인터뷰 기사를 온라인에 올릴 생각이 없다.

무슨 인터뷰였는 지를 말씀드리기에 앞서, 인터뷰를 만들어준 데이빗 에델존에게 감사한다. 공식 약속을 정해준 릭 보스와 필자의 질문에 답해준 피터 산던에게도 감사한다. 마지막으로 970에 대해 필자와 이야기를 나누기 위해 시간을 비워준 그들 세 명 모두에게 감사한다.

Answers to the questions in Appendix B: The mystery pipeline stages revealed

피터 산던에게 던진 첫 번째 질문은 970 파이프라인의 펫치/디코드 부분에 있는 수수께끼의 세 번째 파이프라인 단계에 대한 것이었다. 필자의 두 번째 970 분석 기사 "부록 B: The 970's pipeline in-depth"를 보면, 970의 펫치/디코드 파이프라인이 Power4보다 한 단계 더 길다는 사실을 알 수 있다. 아직까지 나온 970 표 그 어느 것도 이 단계를 명쾌하게 설명해주지 않고 있는데, 답변은 타이밍을 목적으로 삽입한 단계라는 이야기였다.

Peter Sandon: 타이밍용으로 집어 넣었기 때문에, 그다지 새로운 단계는 아닙니다. 그래도 캐시로부터 인스트럭션을 모아서 결국 디코드 단계로 내보내죠.

수수께끼의 추가 단계(벡터 파이프라인)에 대한 부록 B에서의 추측은 맞았지만, 이들 단계가 왜 포함되었는 지에 대한 추측은 틀렸다. 우리는 벡터 실행 유닛이 970 다이 레이아웃에서 다른 실행 유닛과 떨어져있지만, 벡터 레지스터 파일이 코어의 다른 레지스터 파일 바로 옆에 있다고 말했었다. 로드/스토어 대기 시간을 줄이기 위해서다. 따라서 우리는 VMX 파이프에 추가시킨 단계는 두 번째 레지스터 파일 읽기 단계라고 생각했다. 그래야 벡터 레지스터 파일에서 나온 연산 데이터를 벡터 실행 유닛으로 보낼 수 있으니 말이다.

문제의 단계는 실제로 두 번째 RF (register file read) 단계였지만, 우리가 생각한 이유때문에 추가시킨 것은 아니었다(그래도 근접했다).

Peter Sandon: 벡터 레지스터 파일이 다른 레지스터 파일 옆에 있는데요. 실제로는 나머지 벡터 유닛에 있는 겁니다. 다른 레지스터 파일보다 벡터가 크기 때문에 좀 다르게 설계했죠... VMX 실행유닛은 구석으로 넣었답니다.

"좀 다르게 설계했죠"의 의미는 바로 벡터 레지스터 파일(VRF)의 크기에 대한 이야기였다. (레지스터 파일의 크기는 좀더 큰 파일이나 좀더 커진 접근 대기 시간에 영향을 끼친다. VRF는 FP와 인티저 레지스터 파일의 엔트리와 같은 수치를 갖지만 너비가 두 배이다.) 하지만 차후에 받은 산던의 메일에 따르면, 투-사이클의 읽기 대기 시간은 크기 문제가 아니라 VMX 파이프라인 단계를 모두 맞추는 방식과 전체 파일 디자인때문이라고 한다.

The real structure of the VMX (a.k.a. Altivec) unit

WWDC 기사에서 지적했듯, 알티벡 이슈 큐(Altivec issue queues)에 대해 필자가 원래 묘사했던 부분은 틀렸다. 다시 피터 산던이다.

Peter Sandon: 마이크로프로세서포럼(MPF)에서의 제 프리젠테이션에서 오해가 있었던 듯 합니다. 거기서 전 디스팻치를 어떻게 하는지에 대한 사례를 보여주려 했는데, 거기 나온 표가 전부라는 식이죠.

MPF의 표는 단순한 사레일 뿐이니 그대로 받아들이지 말자고 했던 사람이 포럼에 한 명 이상 잇었던 걸로 기억하지만, 이문제에 대해서 필자는 다소 완고하며 회의적이었다만, 이슈큐 구조는 필자 생각보다 디스팻치 그루핑에 대해 훨씬 융통성이 있었다. 이슈큐가 어떤 지는 다음의 그림을 보자.

필자가 970 분석기서 두 번째에서 말했던 바와는 정반대로, 모든 벡터 인스트럭션은 비-브랜치 디스팻치 슬롯 네 개 어디서도 디스팻치할 수 있다.

Peter Sandon: 그럼요. 디스팻치할 수 있죠. 가령 사이클당 치환(permute) 인스트럭션 네 개를 치환 이슈큐를 디스팻치할 수 있죠. 아니면 ALU 인스트럭션 네 개를 VALU 이슈큐로 디스팻치할 수도 있습니다. 그러니까 주어진 사이클에서 어떤 벡터 인스트럭션이라도 이슈큐로 디스팻치할 수 있다는 이야기죠.

무슨 의미일까? 바로 알티벡 코드가 "훨씬" 좋아졌다는 뜻이다. 970의 벡터 유닛은 필자 생각보다 더 좋았다. 그래도 G4e 벡터 유닛보다야 스펙면에서 좋지는 않다. 그래서 산던에게 왜 처음 G4처럼 보이는 디자인을 채택했는 지를 물어보았다. G4e가 아니라 G4다. 시간이나 마케팅, 뭐 다른 이유라도 있었을까?

Peter Sandon: 네. 벡터 코드를 사용해야할 때 이 구조는 실제로 정말 잘 돌아갑니다. 충분히 디스팻치할 수 있으니까요. 당신도 그렇고 애플리케이션 개발자들이면 모두 눈독들일만 하죠. 벡터코드를 잘 활용하려면 벡터 유닛과 고정 포인트 유닛으로의 디스팻치가 필요하게 마련입니다. 그래서, 정말 "예"에요. 시간-마케팅적인 측면이 있습니다. 사실 VMX 자체로의 보다 넓은 디스팻치에는 그리 대단한 득이 되진 않거든요.

Hannibal: 그렇다면, 차후 버전에서는 바꿀 수도 있다는 말씀이신가요? 그렇습니까?

Peter Sandon: 그럴 수도 있습니다. 고려하고 있는 일이죠. 바뀔 지는 모르겠지만 아뭏든 고려중입니다.

그다음에 필자는 벡터 스토어와같은 벡터 메모리 트래픽을 다루는 VMX 유닛의 가능성에 대해 물어보았다.

Peter Sandon: LSU(Load-Store units)은 모든 로드/스토어를 다룹니다. VMX로 디스팻치시킨 벡터 스토어는는 데이터로 움직이죠. 따라서 LSU에서 어드레스 조정이 이뤄지는데, 여기에 데이터를 벡터 유닛 안에 있는 벡터 레지스터 파일 바깥으로 움직이는 슬롯이 있습니다.

David Edelsohn: 스캐일러 인스트럭션에 대해서 LSU가 돌아가는 방식과 비슷하죠. 즉 인티저 스토어나 플로팅-포인트 스토어는 레지스터 파일 접근에 있어서, LSU와 개별 정수, 플로팅-포인트 유닛을 모두 사용합니다.

Miscellany: Bus ratios, compilers, power management

버스에 대해서도 질문해보았다. 970 버스는 단순히 2:1(core clock:bus clock) 비율만을 지원할까?

Peter Sandon: 프로세서 디자인 자체는 여러가지 비율의 버스를 지원하죠. 애플이 발표한 버스가 2:1 비율이었을 뿐입니다. 프로세서는 적어도 3,4, 6대 1의 비율이나 다른 비율도 지원합니다.

Hannibal: 버스 스누핑(snooping)에 대한 질문도 있었는데요. 질문이 정확히 뭔지 잘 모르겠더군요. 버스 스누핑이 어떻게 돌아가는 지에 대한 질문이었을까요...

Peter Sandon: 970 버스는 공유버스가 아니며, 포인트-투-포인트이기 때문에, 아마도 칩셋이 정보 송출을 프로세서로 돌릴 수 있으니 스누핑을 지원한다고 보면 되겠군요. 그게 질문이었다면 말이죠.

애플이 디자인한 칩셋에 대한 질문도 하였다. 원래 필자는 칩셋이 IBM 디자인인줄 알고 있었다.

Hannibal: 지원 로직(칩셋)에 대해서는 애플과 같이 작업하셨더군요. 맞습니까? 아니면 우선 당신들이 만든 다음에 애플로 보낸 건가요?

Peter Sandon: 칩셋은 애플 디자인입니다. 우리도 매우 좋아하는 디자인이죠.

Hannibal: 그러면 970 블레이드에서는 뭘 사용하시나요? IBM 칩셋입니까?

Peter Sandon: 아직 본사가 발표한 부분도 소화못했을 정도입니다. 저로선 모르겠군요.

그렇다면, IBM은 970에 최적화된 컴파일러라도 내놓을 것인 지에 대해 물어보았다.

David Edelsohn: 특히 이번 PowerPC 칩 컴파일러 개발에 있어서 IBM은 애플과 강력히 협력했어요. 애플과 같이 협력을 계속 해서 FSF 향상에 힘쓰고 있습니다.

970의 전력 관리 기능에 대해서도 물어보았다. 산던의 말이다.

Peter Sandon: 네. 970에는 doze/nap/sleep 모드가 있습니다. 예전의 PowerPC에도 있었어요. OS의 조절에 따라 부분별로 멈출 수 있죠. 칩 상의 다이오드로 열 관리도 합니다. 이 다이오드는 온도를 측정하고, 통솔은 외부에서 하는 식이죠.

L1 and L2 cache latencies revealed, and a bit about gcc

필자의 두 번째 970 분석 기사에서 제일 커다란 의문 중 하나는 970의 캐시 대기 시간에 대한 것이었다. 필자처럼 궁금해여기는 독자들은 이제 더이상 궁금해여기지 않아도 된다. (이 인터뷰는 풀-인터뷰가 아니라 필자가 편집했음을 기억하라. 인터뷰를 다 올리지 않았으며 주제별로 순서를 바꾸기도 하였다.)

Peter Sandon: L1의 load-use는 2 사이클을 소요합니다. L2는 11 사이클이죠.

Peter Sandon: 이슈-투-이슈는 3 사이클을 소요합니다. 로드를 이슈시키면, 나중에 세 사이클로 종속 데이터를 사용하죠. 즉 종속성에 두 사이클을 소요한다 그말이죠.

David Edelsohn: L1 로드 대기 시간은 이미 GCC 목록에 나와있지만 L2는 나와있지 않습니다...

이부분에서, 에델존은 GCC가 Power4와 970 최적화에 사용하는 머신 묘사 파일, (power4.md)에 대해 이야기하였다. 목록에 나와있는 벡터 대기 시간이 틀린 것 같아서 그와 필자는 이전에도 이메일로 대화를 나눈 적이 있었다. 사실 WWDC 이전에 이 목록은 틀렸지만, 애플이 WWDC에서 사용한 GCC는 올바른 값을 사용하고 있었다. (WWDC 이전의 970 벡터 소요시간을 둘러싼 혼란이 이때문에 일어나잖았을까라는 생각이 들었지만 깜빡 잊고 질문하지 못했다.) GCC에서 배운 흥미로운 사실도 있다. Power4와 970의 독특한 그룹 디스팻치 스킴과 이슈큐 구조는, 프로세서를 그려내는 GCC의 내부 모델과 잘 들어맞지 않는다. 결과적으로 머신 묘사 파일에 나와있는 L1 캐시 소요 시간 수치(다른 수치도 해당된다고 생각한다)은 GCC에서 최고의 퍼포먼스를 내기 위해서 실제값을 변경시켜야했다.

David Edelsohn: ...그리고 GCC는 사이클 하나를 더 추가시켜서 모델화[즉, L1 캐시 소요시간]시킵니다. 득이 되니까 그런 거죠... GCC 스케쥴러는 970이나 Power4 등과 같은 프로세서를 위한 이상적인 디자인이 아니에요. 그때문에 본사와 애플이 상당히 노력을 기울였습니다. 디스패치 그룹이나 그를 다루는 방식, in-order와 out-order의 부품들, 코드 정렬을 어떻게 할 지 컴파일러를 다루는 방식 등등 프로세서 고유의 특성 때문이죠. 따라서 프로세서를 정확히 묘사하기보다는 좀더 바꾸면 좋을 정보를 줄 여지가 몇 군데 있었습니다. 정말 본사랑 애플이랑 엄청난 연구를 했죠. 이 프로세서로 최고의 퍼포먼스를 내기 위한 노력 중 하나였습니다. 지금도 계속 하고 있고요.

Group dispatch

필자는 산던에게 970의 그룹 디스팻치 스킴의 효율성과 그 배경에 대해서도 물어보았다.

Hannibal: 그룹 디스패치 전체가 흥미로운데요. 이전에도 이랬나요, 아니면 Power4를 위해서 했던 건가요? 이전에는 이런 스킴을 본 적이 없어서요. 970을 본 사람 대부분 정말 새로울 겁니다.

Peter Sandon: 개별 트랙킹이 아니라 그룹 트랙킹 말씀이죠?

Hannibal: 예.

Peter Sandon: 좋은 질문입니다. Power4에 처음 나타났는 지는 잘 모르겠는데, 어느 정도 분명하죠. 인스트럭션 16 개 트랙킹은 되어도 100개 트랙킹은 좀 심하죠.

Hannibal: 네. 디스패치 그루핑에 대해서, "VLIW"같다는 의견들이 있죠. 하지만 물론, Power4 백서만 읽어보면 그게 아니라는 점을 알 수 있지만요.

Peter Sandon: 그렇죠.

Hannibal: 설계자로서, 다소 다른 형태인 그룹 디스패치 자체가 어느정도나 성공했다고 보십니까? 결과에 만족하시는지요?

Peter Sandon: 네. 만족하는 편입니다. 다시 말씀드리는데, 한 번에 인스트럭션 모두를 유지한다면, 개별 트랙킹의 오버헤드는 안될 일입니다. 그래서 그루핑이죠. 그러면 파이프를 완전히 채우고 실행 유닛을 유지시키면서도 많은 일을 한 번에 처리하면서도 트래킹을 벌일 수 있습니다.

David Edelsohn: Power4 프로세서상의 서버 작업 쪽에서 실제로 어떻게 돌아가는 지 알게되면 정말 좋아할 겁니다.

The future

미래 계획에 대한 짤막한 대화도 실어 놓았다. 스스로 판단해보라.

Hannibal: (포럼 멤버들로부터 받은)대부분의 질문이 앞으로의 계획에 대한 것이었는데요. 말하자면 여러분들이 말할 수 없을 로드맵이나 향후 계획입니다. 그래도 어느정도 얘기하실 수 있는 부분은 있겠죠.

Peter Sandon: 나무가 아닌 숲이 있다고만 말씀드릴 수 있겠는데요. 970만이 아닙니다. 로드맵의 나머지 부분에 대해서는 말씀드릴 수 없습니다.

David Edelsohn: 어찌 IBM이라고 해서 감히 현실 왜곡의 장, 애플과 경쟁할 수 있겠습니까?

Hannibal: 하하. 누구도 애플과 경쟁할 순 없죠. 그러려고 했다간, 룩앤 필이나 뭐 다른 걸 갖고 고소당할 겁니다.

Hannibal: SMT에 대해서는 어떤가요?

Peter Sandon: 우린 거기에 대해서는 알아볼 권한이 없습니다. 뭐, 나타나기야 한다면야... 아뇨. 말씀드릴 수 없습니다.

Hannibal: on-die DDR 컨트롤러는 어때요? 여기에 대해서는 말씀하실 수 있습니까?

Peter Sandon: 거기에 대해서도 마찬가지입니다. 하지만 그런 의문들이 생길 법 합니다. 좋은 질문이에요.

Hannibal: 이 칩과 LinuxPPC를 갖고 리눅스 화이트박스 시장을 IBM이 정말 육성시키나요? 즉, 970 블레이드를 발표하셨는데, 애플도 970을 사용하고 있잖습니까? 970이 일반적인 프로세서로 변모한다는 이야기입니까? 이를테면 제가 IBM이나 애플의 허락을 받지 않고 970 기반의 머신을 조립할 수는 있을까요?

Peter Sandon: 유감스럽지만 여기에 대해서도 말씀드릴 수 없습니다. 칩 디자이너로서 저는 이 칩이 널리 퍼졌으면 좋겠지만, 말씀드릴만한 때가 되기 전에는 어떠한 부분도 말씀드릴 수 없습니다.

Hannibal: 일반적으로, 어떤 시장을 노리는 지에 대한 답변도 하실 수 있을 지 모르겠습니다. 즉 IBM 블레이드와 애플 제품 말고도 970이나 970의 하위 버전을 갖고 진출할 시장이 어디가 있을까요?

Peter Sandon: 맞아요. 그부분도 말씀드릴 수 없습니다.

Conclusions

IBM과 대화를 나눌 기회를 가져서 굉장히 기쁘다. 말그대로 필자가 970 디자인에 대해 가졌던 의문과 우려를 말그대로 해소시켜주는 유익한 대화였기 때문이다. VMX/알티벡 유닛은 필자워 원래 생각보다 훨씬 융통성이 있었고 강력했다. 맥 플랫폼에게는 좋은 소식이 되겠다. 하지만 모토로라 G4e와 같은 식으로 벡터 유닛을 디자인했더라면 더 좋았을 것이다(물론 어떻게 응용했는 지에 따라서 그 개선의 정도가 달라진다). 또한 IBM이 그런 방식으로 움직일 가능성도 알아보고 있다는 시사도 역시 좋은 소식이다.

마지막으로, WWDC의 SPEC 벤치마크를 둘러싼 피곤한 논쟁에 휘말려들지 않기 위해서 말하건데, 이 인터뷰는 전체 하드웨어/소프트웨어 공존 시스템에서 컴파일러의 중추적인 역할을 매우 매혹적으로 드러냈다. 보다 정확히 말해서, 970과 같은 디자인은 GCC와 같은 크로스-플랫폼 컴파일러가 상정한 표준 프로세서 모델에서 상당히 벗어나있다. 즉 보다 컴파일러를 튜닝하지 않으면 잠재적인 퍼포먼스에 완전히 도달할 수가 없다. 애플과 IBM이 모두 이문제에 매달려있다는 것 또한 좋은 소식이며, 첫 번째 G5 타워가 시장에 출시될 때면 좀더 진전을 이룰 수 있기 바라겠다.

http://www.arstechnica.com/cpu/03q2/...terview-1.html

2003-07-22, 02:22 PM	#8
casaubon Moderator Registered: Sep 2001 My Mac: iMac 24" 3.06GHz, Macbook Air 13", iPhone 4, iPad 1G Posts: 2,909 오프라인	PowerPC 970 Redux: Dialogue and Addendum by Jon "Hannibal" Stokes 최근, PowerPC 970의 개발에 관계한 IBM의 엔지니어 두 명과 이야기를 나눌 기회가 있었다. 970의 수석 아키텍트 핏 산던(Pete Sandon)과 컴파일러, 970 최적화 작업을 담당한 데이빗 에델존(David Edelsohn)이 그들이다. 또한 여기에 IBM의 PR 매니저, 릭 보스(Rick Bause)도 있었다. 인터뷰는 필자의 예전 970 기사에 대한 보완과 수정, 확인, 기사에서 말했던 의문에 대한 답변 등에 대한 것이었다. 대부분 우리는 970의 마이크로아키텍쳐와 특히 970의 VMX(즉, 알티벡)에 대해 이야기를 나누었는데, 970의 VMX는 필자의 기사에서 묘사한 내용보다 훨씬 강력하고 융통성이 있었다. 이번 인터뷰에서 앞으로의 예상이라던지, 로드맵은 주제가 아니었다. 그런 질문을 던질 수도 있었지만 만족스러운 답변을 해주지는 못했을 것이다. 그래도 이번 인터뷰는 그런 문제와 관련된 몇 가지 적은 정보는 담고 있으며, 부분적으로 포함시켰다. 일단 주제가 필자의 970 기사에 대한 배경이기 때문에, 표준 Q&A 형식이 아니라, 두 개의 970 기사에 대한 업데이트 형식이라는 점을 양해해주기 바란다. 또한 대화는 시간순이 아니라 주제별로 되어있으며 주제별로 편집을 하였다. 필자는 970에 대한 시리즈 두 번째 기사의 리비전에 여기서 얻은 정보를 삽입할 예정이다(이번달 말쯤에 나오리라 예상한다). 지금으로서는 풀 인터뷰 기사를 온라인에 올릴 생각이 없다. 무슨 인터뷰였는 지를 말씀드리기에 앞서, 인터뷰를 만들어준 데이빗 에델존에게 감사한다. 공식 약속을 정해준 릭 보스와 필자의 질문에 답해준 피터 산던에게도 감사한다. 마지막으로 970에 대해 필자와 이야기를 나누기 위해 시간을 비워준 그들 세 명 모두에게 감사한다. Answers to the questions in Appendix B: The mystery pipeline stages revealed 피터 산던에게 던진 첫 번째 질문은 970 파이프라인의 펫치/디코드 부분에 있는 수수께끼의 세 번째 파이프라인 단계에 대한 것이었다. 필자의 두 번째 970 분석 기사 "부록 B: The 970's pipeline in-depth"를 보면, 970의 펫치/디코드 파이프라인이 Power4보다 한 단계 더 길다는 사실을 알 수 있다. 아직까지 나온 970 표 그 어느 것도 이 단계를 명쾌하게 설명해주지 않고 있는데, 답변은 타이밍을 목적으로 삽입한 단계라는 이야기였다. Peter Sandon: 타이밍용으로 집어 넣었기 때문에, 그다지 새로운 단계는 아닙니다. 그래도 캐시로부터 인스트럭션을 모아서 결국 디코드 단계로 내보내죠. 수수께끼의 추가 단계(벡터 파이프라인)에 대한 부록 B에서의 추측은 맞았지만, 이들 단계가 왜 포함되었는 지에 대한 추측은 틀렸다. 우리는 벡터 실행 유닛이 970 다이 레이아웃에서 다른 실행 유닛과 떨어져있지만, 벡터 레지스터 파일이 코어의 다른 레지스터 파일 바로 옆에 있다고 말했었다. 로드/스토어 대기 시간을 줄이기 위해서다. 따라서 우리는 VMX 파이프에 추가시킨 단계는 두 번째 레지스터 파일 읽기 단계라고 생각했다. 그래야 벡터 레지스터 파일에서 나온 연산 데이터를 벡터 실행 유닛으로 보낼 수 있으니 말이다. 문제의 단계는 실제로 두 번째 RF (register file read) 단계였지만, 우리가 생각한 이유때문에 추가시킨 것은 아니었다(그래도 근접했다). Peter Sandon: 벡터 레지스터 파일이 다른 레지스터 파일 옆에 있는데요. 실제로는 나머지 벡터 유닛에 있는 겁니다. 다른 레지스터 파일보다 벡터가 크기 때문에 좀 다르게 설계했죠... VMX 실행유닛은 구석으로 넣었답니다. "좀 다르게 설계했죠"의 의미는 바로 벡터 레지스터 파일(VRF)의 크기에 대한 이야기였다. (레지스터 파일의 크기는 좀더 큰 파일이나 좀더 커진 접근 대기 시간에 영향을 끼친다. VRF는 FP와 인티저 레지스터 파일의 엔트리와 같은 수치를 갖지만 너비가 두 배이다.) 하지만 차후에 받은 산던의 메일에 따르면, 투-사이클의 읽기 대기 시간은 크기 문제가 아니라 VMX 파이프라인 단계를 모두 맞추는 방식과 전체 파일 디자인때문이라고 한다. The real structure of the VMX (a.k.a. Altivec) unit WWDC 기사에서 지적했듯, 알티벡 이슈 큐(Altivec issue queues)에 대해 필자가 원래 묘사했던 부분은 틀렸다. 다시 피터 산던이다. Peter Sandon: 마이크로프로세서포럼(MPF)에서의 제 프리젠테이션에서 오해가 있었던 듯 합니다. 거기서 전 디스팻치를 어떻게 하는지에 대한 사례를 보여주려 했는데, 거기 나온 표가 전부라는 식이죠. MPF의 표는 단순한 사레일 뿐이니 그대로 받아들이지 말자고 했던 사람이 포럼에 한 명 이상 잇었던 걸로 기억하지만, 이문제에 대해서 필자는 다소 완고하며 회의적이었다만, 이슈큐 구조는 필자 생각보다 디스팻치 그루핑에 대해 훨씬 융통성이 있었다. 이슈큐가 어떤 지는 다음의 그림을 보자. 필자가 970 분석기서 두 번째에서 말했던 바와는 정반대로, 모든 벡터 인스트럭션은 비-브랜치 디스팻치 슬롯 네 개 어디서도 디스팻치할 수 있다. Peter Sandon: 그럼요. 디스팻치할 수 있죠. 가령 사이클당 치환(permute) 인스트럭션 네 개를 치환 이슈큐를 디스팻치할 수 있죠. 아니면 ALU 인스트럭션 네 개를 VALU 이슈큐로 디스팻치할 수도 있습니다. 그러니까 주어진 사이클에서 어떤 벡터 인스트럭션이라도 이슈큐로 디스팻치할 수 있다는 이야기죠. 무슨 의미일까? 바로 알티벡 코드가 "훨씬" 좋아졌다는 뜻이다. 970의 벡터 유닛은 필자 생각보다 더 좋았다. 그래도 G4e 벡터 유닛보다야 스펙면에서 좋지는 않다. 그래서 산던에게 왜 처음 G4처럼 보이는 디자인을 채택했는 지를 물어보았다. G4e가 아니라 G4다. 시간이나 마케팅, 뭐 다른 이유라도 있었을까? Peter Sandon: 네. 벡터 코드를 사용해야할 때 이 구조는 실제로 정말 잘 돌아갑니다. 충분히 디스팻치할 수 있으니까요. 당신도 그렇고 애플리케이션 개발자들이면 모두 눈독들일만 하죠. 벡터코드를 잘 활용하려면 벡터 유닛과 고정 포인트 유닛으로의 디스팻치가 필요하게 마련입니다. 그래서, 정말 "예"에요. 시간-마케팅적인 측면이 있습니다. 사실 VMX 자체로의 보다 넓은 디스팻치에는 그리 대단한 득이 되진 않거든요. Hannibal: 그렇다면, 차후 버전에서는 바꿀 수도 있다는 말씀이신가요? 그렇습니까? Peter Sandon: 그럴 수도 있습니다. 고려하고 있는 일이죠. 바뀔 지는 모르겠지만 아뭏든 고려중입니다. 그다음에 필자는 벡터 스토어와같은 벡터 메모리 트래픽을 다루는 VMX 유닛의 가능성에 대해 물어보았다. Peter Sandon: LSU(Load-Store units)은 모든 로드/스토어를 다룹니다. VMX로 디스팻치시킨 벡터 스토어는는 데이터로 움직이죠. 따라서 LSU에서 어드레스 조정이 이뤄지는데, 여기에 데이터를 벡터 유닛 안에 있는 벡터 레지스터 파일 바깥으로 움직이는 슬롯이 있습니다. David Edelsohn: 스캐일러 인스트럭션에 대해서 LSU가 돌아가는 방식과 비슷하죠. 즉 인티저 스토어나 플로팅-포인트 스토어는 레지스터 파일 접근에 있어서, LSU와 개별 정수, 플로팅-포인트 유닛을 모두 사용합니다. Miscellany: Bus ratios, compilers, power management 버스에 대해서도 질문해보았다. 970 버스는 단순히 2:1(core clock:bus clock) 비율만을 지원할까? Peter Sandon: 프로세서 디자인 자체는 여러가지 비율의 버스를 지원하죠. 애플이 발표한 버스가 2:1 비율이었을 뿐입니다. 프로세서는 적어도 3,4, 6대 1의 비율이나 다른 비율도 지원합니다. Hannibal: 버스 스누핑(snooping)에 대한 질문도 있었는데요. 질문이 정확히 뭔지 잘 모르겠더군요. 버스 스누핑이 어떻게 돌아가는 지에 대한 질문이었을까요... Peter Sandon: 970 버스는 공유버스가 아니며, 포인트-투-포인트이기 때문에, 아마도 칩셋이 정보 송출을 프로세서로 돌릴 수 있으니 스누핑을 지원한다고 보면 되겠군요. 그게 질문이었다면 말이죠. 애플이 디자인한 칩셋에 대한 질문도 하였다. 원래 필자는 칩셋이 IBM 디자인인줄 알고 있었다. Hannibal: 지원 로직(칩셋)에 대해서는 애플과 같이 작업하셨더군요. 맞습니까? 아니면 우선 당신들이 만든 다음에 애플로 보낸 건가요? Peter Sandon: 칩셋은 애플 디자인입니다. 우리도 매우 좋아하는 디자인이죠. Hannibal: 그러면 970 블레이드에서는 뭘 사용하시나요? IBM 칩셋입니까? Peter Sandon: 아직 본사가 발표한 부분도 소화못했을 정도입니다. 저로선 모르겠군요. 그렇다면, IBM은 970에 최적화된 컴파일러라도 내놓을 것인 지에 대해 물어보았다. David Edelsohn: 특히 이번 PowerPC 칩 컴파일러 개발에 있어서 IBM은 애플과 강력히 협력했어요. 애플과 같이 협력을 계속 해서 FSF 향상에 힘쓰고 있습니다. 970의 전력 관리 기능에 대해서도 물어보았다. 산던의 말이다. Peter Sandon: 네. 970에는 doze/nap/sleep 모드가 있습니다. 예전의 PowerPC에도 있었어요. OS의 조절에 따라 부분별로 멈출 수 있죠. 칩 상의 다이오드로 열 관리도 합니다. 이 다이오드는 온도를 측정하고, 통솔은 외부에서 하는 식이죠. L1 and L2 cache latencies revealed, and a bit about gcc 필자의 두 번째 970 분석 기사에서 제일 커다란 의문 중 하나는 970의 캐시 대기 시간에 대한 것이었다. 필자처럼 궁금해여기는 독자들은 이제 더이상 궁금해여기지 않아도 된다. (이 인터뷰는 풀-인터뷰가 아니라 필자가 편집했음을 기억하라. 인터뷰를 다 올리지 않았으며 주제별로 순서를 바꾸기도 하였다.) Peter Sandon: L1의 load-use는 2 사이클을 소요합니다. L2는 11 사이클이죠. Peter Sandon: 이슈-투-이슈는 3 사이클을 소요합니다. 로드를 이슈시키면, 나중에 세 사이클로 종속 데이터를 사용하죠. 즉 종속성에 두 사이클을 소요한다 그말이죠. David Edelsohn: L1 로드 대기 시간은 이미 GCC 목록에 나와있지만 L2는 나와있지 않습니다... 이부분에서, 에델존은 GCC가 Power4와 970 최적화에 사용하는 머신 묘사 파일, (power4.md)에 대해 이야기하였다. 목록에 나와있는 벡터 대기 시간이 틀린 것 같아서 그와 필자는 이전에도 이메일로 대화를 나눈 적이 있었다. 사실 WWDC 이전에 이 목록은 틀렸지만, 애플이 WWDC에서 사용한 GCC는 올바른 값을 사용하고 있었다. (WWDC 이전의 970 벡터 소요시간을 둘러싼 혼란이 이때문에 일어나잖았을까라는 생각이 들었지만 깜빡 잊고 질문하지 못했다.) GCC에서 배운 흥미로운 사실도 있다. Power4와 970의 독특한 그룹 디스팻치 스킴과 이슈큐 구조는, 프로세서를 그려내는 GCC의 내부 모델과 잘 들어맞지 않는다. 결과적으로 머신 묘사 파일에 나와있는 L1 캐시 소요 시간 수치(다른 수치도 해당된다고 생각한다)은 GCC에서 최고의 퍼포먼스를 내기 위해서 실제값을 변경시켜야했다. David Edelsohn: ...그리고 GCC는 사이클 하나를 더 추가시켜서 모델화[즉, L1 캐시 소요시간]시킵니다. 득이 되니까 그런 거죠... GCC 스케쥴러는 970이나 Power4 등과 같은 프로세서를 위한 이상적인 디자인이 아니에요. 그때문에 본사와 애플이 상당히 노력을 기울였습니다. 디스패치 그룹이나 그를 다루는 방식, in-order와 out-order의 부품들, 코드 정렬을 어떻게 할 지 컴파일러를 다루는 방식 등등 프로세서 고유의 특성 때문이죠. 따라서 프로세서를 정확히 묘사하기보다는 좀더 바꾸면 좋을 정보를 줄 여지가 몇 군데 있었습니다. 정말 본사랑 애플이랑 엄청난 연구를 했죠. 이 프로세서로 최고의 퍼포먼스를 내기 위한 노력 중 하나였습니다. 지금도 계속 하고 있고요. Group dispatch 필자는 산던에게 970의 그룹 디스팻치 스킴의 효율성과 그 배경에 대해서도 물어보았다. Hannibal: 그룹 디스패치 전체가 흥미로운데요. 이전에도 이랬나요, 아니면 Power4를 위해서 했던 건가요? 이전에는 이런 스킴을 본 적이 없어서요. 970을 본 사람 대부분 정말 새로울 겁니다. Peter Sandon: 개별 트랙킹이 아니라 그룹 트랙킹 말씀이죠? Hannibal: 예. Peter Sandon: 좋은 질문입니다. Power4에 처음 나타났는 지는 잘 모르겠는데, 어느 정도 분명하죠. 인스트럭션 16 개 트랙킹은 되어도 100개 트랙킹은 좀 심하죠. Hannibal: 네. 디스패치 그루핑에 대해서, "VLIW"같다는 의견들이 있죠. 하지만 물론, Power4 백서만 읽어보면 그게 아니라는 점을 알 수 있지만요. Peter Sandon: 그렇죠. Hannibal: 설계자로서, 다소 다른 형태인 그룹 디스패치 자체가 어느정도나 성공했다고 보십니까? 결과에 만족하시는지요? Peter Sandon: 네. 만족하는 편입니다. 다시 말씀드리는데, 한 번에 인스트럭션 모두를 유지한다면, 개별 트랙킹의 오버헤드는 안될 일입니다. 그래서 그루핑이죠. 그러면 파이프를 완전히 채우고 실행 유닛을 유지시키면서도 많은 일을 한 번에 처리하면서도 트래킹을 벌일 수 있습니다. David Edelsohn: Power4 프로세서상의 서버 작업 쪽에서 실제로 어떻게 돌아가는 지 알게되면 정말 좋아할 겁니다. The future 미래 계획에 대한 짤막한 대화도 실어 놓았다. 스스로 판단해보라. Hannibal: (포럼 멤버들로부터 받은)대부분의 질문이 앞으로의 계획에 대한 것이었는데요. 말하자면 여러분들이 말할 수 없을 로드맵이나 향후 계획입니다. 그래도 어느정도 얘기하실 수 있는 부분은 있겠죠. Peter Sandon: 나무가 아닌 숲이 있다고만 말씀드릴 수 있겠는데요. 970만이 아닙니다. 로드맵의 나머지 부분에 대해서는 말씀드릴 수 없습니다. David Edelsohn: 어찌 IBM이라고 해서 감히 현실 왜곡의 장, 애플과 경쟁할 수 있겠습니까? Hannibal: 하하. 누구도 애플과 경쟁할 순 없죠. 그러려고 했다간, 룩앤 필이나 뭐 다른 걸 갖고 고소당할 겁니다. Hannibal: SMT에 대해서는 어떤가요? Peter Sandon: 우린 거기에 대해서는 알아볼 권한이 없습니다. 뭐, 나타나기야 한다면야... 아뇨. 말씀드릴 수 없습니다. Hannibal: on-die DDR 컨트롤러는 어때요? 여기에 대해서는 말씀하실 수 있습니까? Peter Sandon: 거기에 대해서도 마찬가지입니다. 하지만 그런 의문들이 생길 법 합니다. 좋은 질문이에요. Hannibal: 이 칩과 LinuxPPC를 갖고 리눅스 화이트박스 시장을 IBM이 정말 육성시키나요? 즉, 970 블레이드를 발표하셨는데, 애플도 970을 사용하고 있잖습니까? 970이 일반적인 프로세서로 변모한다는 이야기입니까? 이를테면 제가 IBM이나 애플의 허락을 받지 않고 970 기반의 머신을 조립할 수는 있을까요? Peter Sandon: 유감스럽지만 여기에 대해서도 말씀드릴 수 없습니다. 칩 디자이너로서 저는 이 칩이 널리 퍼졌으면 좋겠지만, 말씀드릴만한 때가 되기 전에는 어떠한 부분도 말씀드릴 수 없습니다. Hannibal: 일반적으로, 어떤 시장을 노리는 지에 대한 답변도 하실 수 있을 지 모르겠습니다. 즉 IBM 블레이드와 애플 제품 말고도 970이나 970의 하위 버전을 갖고 진출할 시장이 어디가 있을까요? Peter Sandon: 맞아요. 그부분도 말씀드릴 수 없습니다. Conclusions IBM과 대화를 나눌 기회를 가져서 굉장히 기쁘다. 말그대로 필자가 970 디자인에 대해 가졌던 의문과 우려를 말그대로 해소시켜주는 유익한 대화였기 때문이다. VMX/알티벡 유닛은 필자워 원래 생각보다 훨씬 융통성이 있었고 강력했다. 맥 플랫폼에게는 좋은 소식이 되겠다. 하지만 모토로라 G4e와 같은 식으로 벡터 유닛을 디자인했더라면 더 좋았을 것이다(물론 어떻게 응용했는 지에 따라서 그 개선의 정도가 달라진다). 또한 IBM이 그런 방식으로 움직일 가능성도 알아보고 있다는 시사도 역시 좋은 소식이다. 마지막으로, WWDC의 SPEC 벤치마크를 둘러싼 피곤한 논쟁에 휘말려들지 않기 위해서 말하건데, 이 인터뷰는 전체 하드웨어/소프트웨어 공존 시스템에서 컴파일러의 중추적인 역할을 매우 매혹적으로 드러냈다. 보다 정확히 말해서, 970과 같은 디자인은 GCC와 같은 크로스-플랫폼 컴파일러가 상정한 표준 프로세서 모델에서 상당히 벗어나있다. 즉 보다 컴파일러를 튜닝하지 않으면 잠재적인 퍼포먼스에 완전히 도달할 수가 없다. 애플과 IBM이 모두 이문제에 매달려있다는 것 또한 좋은 소식이며, 첫 번째 G5 타워가 시장에 출시될 때면 좀더 진전을 이룰 수 있기 바라겠다. http://www.arstechnica.com/cpu/03q2/...terview-1.html __________________