5년 농사를 준비한다. 코어 아키텍쳐

5년 농사를 준비한다. 코어 아키텍쳐

인텔은 7월 23일 정식으로 컨로 프로세서를 발표하고 시장 공략에 나설 예정이다. 아울러 이를 지원하기 위한 965 칩셋도 발표한 상태인데, 이미 마더보드 업체들이 다수의 965 칩셋 마더보드 샘플을 내놓고 있는 것으로 보아 이미 준비는 완료된 상태로 보인다. 컨로의 예정 가격은 다음과 같다.

• E6700: 2.66 GHz / FSB 1066/ 4 MB 공유 L2 캐쉬, 가격 530달러
• E6600: 2.40 GHz / FSB 1066/ 4 MB 공유 L2 캐쉬, 가격 316달러
• E6400: 2.13 GHz / FSB 1066/ 2 MB 공유 L2 캐쉬, 가격 224달러
• E6300: 1.86 GHz / FSB 1066/ 2 MB 공유 L2 캐쉬, 가격 183달러
• E4200: 1.60 GHz / FSB 800/ 2 MB 공유 L2 캐쉬   
• Extreme Edition X6800 : 2.93GHz/ FSB 1066/ 4MB 공유 L2 캐쉬, 가격 999달러

인텔은 지난 인텔 개발자 포럼 이후부터 비공개를 조건으로 주요 리뷰어와 기자들을 불러 컨로를 시연해 보인 바 있다. 이 자리에는 2.66GHz의 컨로 시스템을 경쟁 업체인 AMD의 애슬론FX-60(2.8GHz로 오버클럭)과 직접 비교하도록 한 바 있는데, 그 성능은 이미 웹에서 다수 공개된 성능과 크게 다르지 않다. 물론 현재 대부분의 테스트 성능 측정을 위한 프로그램들, 일례로 벤치마크 프로그램이나 게임들,이 거의 싱글 쓰레드 애플리케이션임에도 불구하고 컨로는 인상적인 성능을 보여주고 있다. 코어는  멀티 코어를 지향한 아키텍쳐인만큼 인텔은 현재 사용되는 윈도우 XP가 이미 멀티 쓰레드를 지원하는 운영체제이기 때문에 그 혜택을 바로 컨로에서 얻을 수 있고, 앞으로 개발자들이 점점 더 멀티 쓰레드 애플리케이션을 개발할 경우 가면 갈수록 힘을 더 받을 수 있을 것으로 기대한다고 밝히고 있다.

그렇다면 하이퍼쓰레딩은 왜 빠졌을까? 인텔이 하이퍼쓰레딩의 펜티엄4가 최고 40%의 성능 향상을 낼 수 있다며 홍보하던 것과 달리 이번 컨로에서 하이퍼쓰레딩이 빠진 이유에 대한 인텔 엔지니어의 답변은 “가상 쓰레딩은 실제 물리적으로 2개의 쓰레드가 동작하는 것보다 우월하지 않기 때문”이라는 약간은 싱거운 답변을 들어야 만 했다.

그러나 업계에서는 하이퍼쓰레딩을 코어 아키텍쳐에 넣지 않은 이유는 바로 1개의 통합 아키텍쳐를 지향했기 때문이라는 설이 더 유력하다. 인텔은 코어 아키텍쳐로 데스크탑(코어 2듀오, 컨로), 서버(우드 크레스트), 모바일(메롬)의 모든 프로세서 라인업을 통일했다. 그러나 모바일 환경(노트북)에서 하이퍼쓰레딩은 사실상 사용 빈도를 볼때 서버 만큼의 혜택이 높지 않은 대신 전력 소모량은 증가하기 때문에 이를 빼버린 것으로 추정된다.

마지막으로 결론짓자면 현존하는 x86 마이크로프로세서 중 가장 비순차적 실행의 적용 점위가 넓고 에너지 효율도 높을뿐더러 싱글/멀티쓰레드 애플리케이션에서 모두 인상적인 성능을 낼 수 있는 기본기를 탄탄히 갖추고 있다고 평할 수 있겠다.  한 세대에서 다른 세대로 바뀌는 전이시기의 첫 제품은 사실 그다지 좋은 평을 듣지 못하는 것이 최첨단 정보기기의 되풀이되는 전통이다. 펜티엄 2에서 III로 넘어갈 때, 그리고 III에서 4로 넘어갈 때마다 인텔은 초기 성장통을 단단히 앓아야만 했다. 하지만 이번 코어 2 듀오 만큼은 내일 모레 장가가도 될 청년처럼 느껴진다.  

캐쉬, 마침내 분단의 벽을 허물다

캐쉬, 마침내 분단의 벽을 허물다

앞서서 위에 언급한 내용들은 모두 코어 아키텍쳐의 하나의 코어에 해당되는 기술이다. 코어 아키텍쳐의 프로세서는 기본적으로 듀얼 코어로 구성되어 있으며 이후에 인텔이 보급형 프로세서 시장을 타겟으로 싱글 코어의 코어 아키텍쳐 프로세서도 내놓을 것으로 전망된 바 있지만 기본적으로 코어는 듀얼 코어 프로세서를 지향한다.

인텔이 최초로 발표했던 듀얼 코어 프로세서 펜티엄D의 경우 2개의 싱글 코어 프로세서 다이를 싱글 패키지로 묶은 것으로 사실상 2개의 프로세서 코어는 각기 고유의 캐쉬를 운용했으며 이 캐쉬 메모리는 상호 아무런 상관이 없었다. 그렇기 때문에 이 경우 각 코어의 캐쉬가 2MB이고 이것을 2x2MB=4MB라고 하는 것은 어불성설이나 다름 없으며 오히려  싱글 코어의 2MB 캐쉬보다 약간 더 나은 정도라고 보면 될 것이다.

이 경우 듀얼 코어에서 각 코어간의 캐쉬 정보가 공유되지 않으면 각 캐쉬는 같은 버스를 타고  각각 메모리에 접근해서 필요한 데이터를 가져 오려고 한다. 이 경우 FSB(Front Side Bus)는 당연히 트래픽이 늘어날 수 밖에 없다.

또한 캐쉬 효율성에서도  필요한 데이터가 다른 코어의 캐쉬에선 있는데 반대편 코어에서 없을 경우에는 같은 정보를 양쪽 캐쉬가 모두 보유하고 있어야 하는 낭비를 초래한다. 이는 비단 캐쉬 저장의 효율성을 떠나서도 어쨌든 양 회로가 모두 움직여야 한다는 기본적인 면에서 전력 소모량이 높을 수 밖에 없는 것이다.

인텔은 코어 듀오, 요나 프로세서에 최초로 양 코어가 하나의 L2 캐쉬를 공유하는 스마트 캐쉬를 도입한다. 양 코어는 하나의 대형 캐쉬를 공유해서 실질적으로 각 코어가 가용할 수 있는 캐쉬 용량도 커졌을 뿐만 아니라 캐쉬 데이터 중복의 낭비도 없애고 메모리 버스의 병목 현상도 줄였다. 인텔은 메모리 컨트롤러를 아직 프로세서 내부에 넣지 않아도 현재 FSB 구조가 충분하다고 보고 있는데, 아직까지는 메모리 버스가 성능을 가로막는 병목현상이 일어나는 곳이 아니라고 밝히고 있다. 즉 내장된 메모리 컨트롤러는 높은 대역폭을 제공하는 이점도 있지만 오히려 더 프로세서 내부의 캐쉬 알고리듬이 뛰어나면 병목 현상이 일어날 일이 없다고 주장했다.

코어 아키텍쳐에서는 이보다 개선된 "어드밴스드 스마트 캐쉬(Advanced Smart Cache)"를 도입했다. 이 것은 요나의 공유 캐쉬와 기본적으로 같지만 전력 관리 부분이 더 개선되었고 데이터를 필요 이전에 가져오기 위한 프리페치(Pre-Fetch) 알고리듬도 개선되었으며 데이터공유 효율도 높아졌다고 인텔은 밝혔다.  

안에서 새는 바가지부터 막자

코어 아키텍쳐가 모바일 프로세서인 요나에서 많은 부분을 승계했다는 것은 곧 전력 관리 기술도 아예 아키텍쳐 개발 초기부터 염두에 두고 개발되었다는 것과 일맥상통한다.

일반적으로 인텔의 전력 관리 기술은 프로세서에 부하가 적을 시에 클럭을 낮춰 전력 소모량을 줄이는 스피드스텝과 같은 프로세서 전체를 보는 거시적인 관점에서 기술로 시작했지만 코어 아키텍쳐에서는 전력 관리 기능이 이에서 미시적인 관점으로 더 확대하고 파고 들어 프로세서를 구성하는  유닛 하나하나에도 전력 관리 기술을 적용시켰다. 코어 아키텍쳐가 완전히 백지에서부터 다시 설계되었다는 것은 아마도 전력 관리 기술 부분에 있어 회로 하나하나에도 세심히 신경을 썼다는 의미로 보아도 좋을 것이다.

코어 아키텍쳐에는 다이상에 디지털 온도 센서를 구비하고 있으며 이 센서는 물론 과도한 전력 소모와 발열을 감지하고 해당 부분의 동작 여부를 판단하는 잣대로 사용하도록 되어 있다. 이것에서 한가지 흥미로운 것은 만약 발열에 있어 여유가 있으면 오히려 역으로 프로세서의 클럭을 끌어올린다는 것. 쉽게 이야기하면 자동 오버클럭이라는 이야기인데, 물론 이것은 아직 인텔이 정식 확인한 바는 아니며 프로세서 업계에서 도는 이야기정도에 불과하다.

코어 아키텍쳐의 듀얼 코어 프로세서에서 각 코어는 각각 독립적으로 전력 관리 기능을 수행한다. 즉 하나의 코어만이 필요한 작업에서는 나머지 하나 코어의 전력 소모량을 떨어뜨리는 것. 여기서 끝나지 않고 인텔은 코어 내부의 대부분의 버스에도 전력 소모 통제를 위한 일종의 게이트를 설치해 놓았다. 즉 특정 유닛으로 통하는 버스가 일정 시간 동안 트래픽이 없거나 낮을 경우에는 이 버스를 슬립 모드로 동작시킨다. 일례로 128비트 연산이 가능한 부동 소수 연산 유닛에서 만약 대부분의 연산데이터가 64비트라면 이 버스의 절반을 꺼버리는 것이다. 인텔이 이번 프로세서 아키텍쳐 개발시 얼마나 전력 관리 소모량에 신경을 썼나 엿볼 수 있는 부분이며 동시에 이전 프로세서가 많은 두통을 인텔에게 주었다는 것을 반증하는 것이기도 하다.

레이턴시 줄이기 : 메모리 디스앰비규에이션

레이턴시 줄이기 : 메모리 디스앰비규에이션

펜티엄 프로 이후로 인텔은 명령어를 가져오고 실행하는데 있어 비순차적(Out Of Order) 실행을 도입했다. 메모리 재정렬 버퍼-MROB(Memory Reorder Buffer)에서도 비순차적 실행을 위한 명령어/데이터 재정렬시에 인텔은 이 부분에서도 캐쉬 메모리, 혹은 메인 메모리에서 찾는 데이터를 가져오는데 필요한 레이턴시를 줄일 수 있는 방법을 찾아냈는데 이것을 메모리 디스앰비규에이션(Memory Disambiguation) 이라 지칭하고 있다.

 일반적으로 메모리 그리고 캐쉬에서 데이터를 가져오고 저장하는 메모리 연산 유닛 기능은 가장 간단하게 Load(불러오기)와 Store(저장하기)로 정의된다. 비순차적 실행을 위한 재정렬에 있어 프로세서 입장에서 이 Load와 Store의 순서를 정하는 것은 매우 중요하다. 만약 한 데이터를 특정 저장소(캐쉬, 메모리 혹은 레지스터 파일)에서 저장(Store)해서 다시 불러오기(Load)를 시행하는 연산 과정이 있다고 가정하면, 이 시행 순서를 바꿀수가 없다. 만약 먼저 Load를 같은 장소에서 불러오고 다서 Store를 한다면 결국 데이터는 원하는 값대로 갱신되는 것이 아니기 때문이다. 데이터 저장소 입장에서 남아 있는 데이터 값의 입장에서 보면 이해하기 쉽다. 즉 Load를 시행하기 위해서는 Store가 진행되는 동안 기다려야 한다.

 위와 같은 이유로 인해서 비록 비순차적 실행을 도입했더라도 인텔은 넷버스트 아키텍쳐의 펜티엄4까지 반드시 Store와 Load에서 같은 메모리 주소를 참조하고 있는지 반드시 확인하도록 했다. 만약 섞인 메모리 명령어 중에서 Store가 저장 메모리 장소가 정확하지 않을 경우 이를 Load 이전에 실행하는 것을 엄격하게 막았다. 즉 만약 Store의 주소가 명확해지고 나서 Load와 같은 메모리 장소를 사용한다는 것이 알려지게 되면 결국 잘못된 연산 결과를 낼 수 있었기 때문이다.

문제는 이와 같은 Load, Store간의 관계에서 실질적으로 같은 메모리 장소를 사용하고 반드시 순차적으로 실행되어야 하는 것 (이것을 Memory Alias라고 인텔은 부른다)이 실질적으로 ROB에서 시행되는 전체 명령어 중에서 단 3% 정도 밖에 되지 않았다는 것. 나머지 97%는 같은 주소를 참조하지 않는 False Aliasing이었다고.

 이 경우에는 Load, Store의 순서를 변경할 수 있다. 위에서 언급했듯이 메모리 디스앰비규에이션은 데이터를 불러오고 저장하는데 있어 레이턴시를 줄이는 것이 목표라고 했다. 그렇다면 이 순서를 바꾸는 것으로 어떻게 레이턴시를 줄일 수 있을까? 아래 그림을 참조하도록 하자.

 

먼저 STORE와 LOAD가 같은 메모리 값을 참조하는 경우를 보자. 이 경우 X에 먼저 10이란 값을 저장한다. 그렇다면 다음 LOAD는 같은 메모리 장소X에 저장된값을 불러와서 레지스터 A에 저장해야 하기 때문에 STORE가 실행되는 1클럭 동안 전까지 기다려야 한다. 이는 STORE가 완료되고 LOAD를 시행하기 이전에 1 클럭의 레이턴시가 발생한다는 것을 의미한다. 이후에 A, B 레지스터에 적힌 값을 더해서 레지스터 Y에 저장하게 되는 과정에서도 역시 X에서 값을 불러와서 A에 넣기 위해서 1클럭을 소요하고 이는 이만큼 기다려야 한다는 것을 의미한다.  이 경우에는 STORE, LOAD의 순서를 바꿀수 없으며 이것이 바로 위에서 언급한 Memory Alias이다.

그러나 만약 STORE와 LOAD가 같은 메모리 값을 참조하지 않는다면 어떻게 될까?(이 경우를 False Aliasing이라고 한다) 그림에서 2번째 경우를 보면 STORE의 경우 메모리 X를 참조하고 LOAD의 경우 메모리 Y를 참조한다. 이 경우 LOAD가 STORE가 완료될때까지 기다릴 필요가 없기 때문에 레이턴시가 발생하지 않는다. 그러나 여전히 ADD에서 필요한 값을 구하기 위해서는 LOAD가 완료될 때까지 기다려야 한다. 이것이 현제 넷버스트까지 할 수 있던 최선의 방법이었다.

 

그러나 만약 같은 메모리를 참조하지 않는다면 이 과정에서는 아예 레이턴시를 없애 버릴 수도 있는데 이는 실행 순서를 바꿈으로써 가능하게 된다. 메모리 디스앰비규에이션이 적용될 경우 STORE와 같은 메모리 참조값을 사용하지 않는 LOAD를 STORE보다 실행한다. 이로 인해서 뒤에 ADD 연산은 물론 LOAD가 완료될때까지 기다려야 하지만 이 기다리는 시간을 허비 하지 않고 바로 STORE 작업을 시행할 수 있으며 낭비되는 레이턴시를 없앨 수 있다.

인텔은 메모리 디스앰비규에이션, 즉 LOAD와 STORE의 순서를 바꾸어 레이턴시를 낮추는 것만으로도 최고 40%의 성능향상이 있다고 밝혔다.  

진정한 128비트 SSE 구현

진정한 128비트 SSE 구현

그렇다면 RS, 그리고 스케쥴러를 지나 이제 연산 유닛을 비교해보자.

코어 아키텍쳐의 경우 RS를 지나 본격적으로 벡터(Vector ALU), 스칼라(Scalar ALU), 그리고 메모리 연산(Store와 Load를 실행) 유닛으로 접속하는 포트를 6개를 제공한다. 코어를 있게 한 P6의 경우(펜티엄3)의 경우에는 5개의 포트를 제공하고 있으며 넷버스트의 경우에는 4개를 가지고 있다.

코어의 경우 포트 수가 액면상 늘어난 것을 제외하더라도 일단 가장 눈에 띄는 것은 연산 유닛으로 에 할당된 포트 수가 3개라는 것이다. P6의 경우에는 2개가 할당되었었으며 넷버스트의 경우에도 2개만이 ALU에 할당되었고 나머지는 메모리 연산 부분으로 할당되었었다. 코어의 경우에는 3개의 포트로 인해서 사이클당 3개의 연산을 지속적으로 처리가 가능하다.

애초에 펜티엄 프로로 시작하고 이후에 펜티엄 III로 진화하면서 벡터 연산 유닛, 즉 MMX와 SSE를 연산 유닛 부분에 추가하면서 문제는 RS에서 ALU로 오는 포트수가 작아서 이 부분에서 병목 현상이 발생할 수 있다는 것이었다. (특히 2 사이클을 필요로 하는 SSE 명령어의 처리 경우에는 포트의 대역폭이 부족했을 것이다.) 이 문제는 여전히 ALU에 2개 포트만을 가지고 있는 넷버스트에서도 잔존했다. 넷버스트의 ALU(Fast ALU 유닛)는 다른 부분에 비해서 2배속도의 클럭으로 동작한다. 즉 이론상으로는 클럭당 처리할 수 있는 최대 명령어는 넷버스트에서는 4개이다. 그러나 4개가 되어야할 경우에는 반드시 이 ALU에서 처리할 수 있는 단순(Simple) 연산일 경우에만 클럭 사이클당 4개를 처리할 수 있다. 즉 지속적으로 처리가 가능하다는 면에서는 코어가 더 균형잡힌 구조를 가지고 있다.

코어의 연산 유닛중 가장 뛰어난 부분은 바로 SSE 유닛이다. 인텔의 SSE(Streaming SIMD Extension)는 128비트 벡터의 지원이라는 것으로 호평을 듣기도 했지만 반면 P6 코어, 그리고 최근의 넷버스트까지도 64비트의 내부 데이터경로로 인해서 완전하지 못하다는 평을 들어야 했다. 코어의 3개의 SSE 유닛은 128 비트로 동작한다. 즉 128비트의 SSE 명령어를연산하는데 있어 유닛당 당 1개의 클럭 사이클만을 필요로 한다는 것이다. 이와 비교해서 넷버스트의 SSE 유닛은 64비트로 동작하는 것 2개를 가지고 있으며 128비트 연산시에 2개의 클럭 사이클을 필요로 한다. 코어의 전신인 요나도 64비트 SSE 유닛을 가지고 있다.

이와 비교해서 코어는 최대  4개의 배정밀도(DP, Double Precision, 64비트) 부동 소수 연산을 한 사이클에 처리할 수 있다. 인텔은 이를 어드밴스드 디지털 미디어 부스트(Advanced Digital Media Boost)라는 이름으로 코어 아키텍쳐의 핵심 기능으로 내세우고 있다.

이 역시 처리되는 Micro-Op의 단위수를 줄여서 더욱 빠른 성능을 도모함과 동시에 연산 유닛 입장에서는 해당 연산부하에 대해서 전력 소모량을 줄일 수 있는 것이다.

* SSE4

한편 인텔은 이번 코어 아키텍쳐에서 새로운 SSE 명령어를 추가하였으나 이를 적극적으로 홍보하고 있지는 않다. 아직까지 SSE4라고 알려진 이 명령어는 기존 SSE/SSE2/SSE3에 16개의 새로운 명령어가 추가된 것이며 필자의 질문에 인텔 엔지니어는 이것이 꼭 필요한 사람에게만 유용한 것이라고 그다지 부각되는 기능은 아니라는 식으로만 답했다. 이 명령어들은 원래 4GHz의 장벽을 넘을 기대주였지만 좌초된 테자스(Tejas)에서 적용할 예정이었던 것으로 추정된다.

이에 대한 구체적인 내용은 코어2 듀오가 정식 발표되는 시점에서 인텔이 공개할 것으로 전망된다. SSE4 명령어에 대한 추측 사항이 이미 인터넷을 통해서 공개된 바 있는데 이것은 어디까지나 추측이고 정확한 것은 아니다. 관심있는 사람은 방문해보기 바란다(일본어)

http://dango.kousaku.in/hiki/SSE4.html 

코어 아키텍쳐, P6, 그리고 넷버스트의 연산 유닛을 표로 정리해 보았다.

	P6(요나)	넷버스트(펜티엄4)	코어
포트(연산유닛할당 포트)	5(2)	4(2)	6(3)
정수(Int) 유닛	2개	3개	3개
부동소수(FP) 유닛	2개 (64bit)	1개 (64bit)	2개(128bit)
SSE 유닛	2개(64bit)	1개 (64bit)	3개 (128bit)

와이드 와이드 와이드 : 무엇이 넓어졌나?

와이드 와이드 와이드 : 무엇이 넓어졌나?

코어 아키텍쳐는 기본적으로 이전 세대의 프로세서 대비 실행 유닛과 스케쥴링 부분에 있어 이전 세대의 프로세서를 압도한다. 여기에는 각 연산 단계(파이프라인)에서 더 많은 디코딩 로직, 더 많은 재정렬 버퍼 공간, 더 큰 명령어 대기소(Reservation Station), 그리고 더 많은 포트를 가지고 있다는 것을 의미한다.

사실 연산(Execution) 유닛에 해당 Micro-Op을 모든 연산 유닛에 지속적으로 보급을 위한 비순차적 실행 부분은 넷버스트와 코어 아키텍쳐와 직접적인 비교가 불가능하며 바로 이것이 코어 아키텍쳐가 왜 넷버스트가 아닌 P6의 후손에 가깝다는 평을 듣는 이유이다.

코어 아키텍쳐는 P6에서와 같이 통합적인 보관 장소(RS, Reserve Station)을 통해서 최종적으로 연산 유닛에 명령어/데이터를 공급하게 되지만 넷버스트는 이와 달리 정수, 소수 연산과 벡터유닛(SSE), 그리고 메모리에 대해서 각각 독립적인 분배형 (Distributed) 스케쥴러를 가지고 있기 때문이다. 직접적인 비교는 불가능하나 코어의 경우 RS 엔트리(분해된 Micro Op의 연산 유닛으로 재정렬을 위한 공간)가 32개, 요나의 경우 24개이고 분배형 스케쥴러를 사용하는 넷버스트의 경우 46개(연산 유닛 38개, 8개 메모리)를 사용하고 있다. 엔트리만 보자면 넷버스트에 비해서 코어가 작아 보이지만, 결국 파이프라인 단계가 현저하게 낮아서 스케쥴링에 넷버스트같이 많은 공간이 오히려 코어에서는 필요하지 않아 보인다.

일단 이 스케쥴러, 혹은 RS를 기준으로 디코딩되고 난 Micro Op의 연산 유닛까지의 흐름을 따라가보자.

펜티엄4 넷버스트의 경우 디코딩 되고 이후에 트래이스 캐쉬에 저장된 Micro Op은 사이클당 3개를 재정렬 버퍼(Reorder Buffer, ROB)로 보낼 수 있으며 여기서 연산 유닛(벡터(SSE/SMID), 스칼라(정수, 부동소수), 메모리(로드-스토어)의 3종으로 보통 구분된다)의 데이터/명령어 공급을 위한 스케쥴러 및 메모리 스케쥴러로 사이클당 3개의 Micro Op의 속도로 전송하게 된다.

요나(코어 듀오)의 경우에는 위에서 언급했듯이 디코딩 유닛(심플 디코딩 유닛)의 개수가 코어 보다 하나 작으며 사이클당 최대 6개의 Micro Op을 디코딩 해서 ROB로 보내고 최종적으로 RS에서도 연산 유닛으로 사이클당 3개의 Micro OP을 RS에서 연산 유닛으로 보낼 수 있다.

즉 시동이 걸려 있고 달릴 준비를 하는 연산 유닛 입장에서 보자면 들어오는 연산 데이터/명령어의 공급 속도는 같이 사이클당 3개의 Micro Op이다. 그러나 위에 언급했듯이 요나의 경우에는 Micro Op Fusion을 지원하기 때문에 마이크로 퓨전의 효용성에 따라서 실제 각 연산 유닛의 효용성을 떠나 전체 프로세서 생태계에서 처리하는 명령어의 수는 요나가 훨신 많을 것으로 추정된다.

코어 아키텍쳐는 요나보다도 1개 더 많은 심플 디코더를 가지고 있어 사이클당 최대 7개의 Micro Op을 디코딩 할 수 있고 이후에 ROB, RS그리고 연산 유닛까지도 사이클당 4개의 Micro Op을 전송시킬 수 있다. 이는 단순히 요나에 대비해서도 33% 더 많은 것인데, 비록 사이클당 1개의 차이라고 해도 엄청난 클럭 속도에서 데이터/명령어의 이동을 생각한다면 작은 차이라고 볼수 없을 것이다. 여기에 위에 매크로 퓨전, 마이크로 퓨전까지의 혜택을 더한다면 상대적으로 넷버스트의 펜티엄 4 프로세서 대비, 낮은 클럭이라도 실제로 연산 유닛으로 데이터/명령어를 재정렬하고 공급하는 처리량은 단순 33% 수치 이상일 것으로 관측된다.

이것을 인텔은 “와이드 다이내믹 익스큐션(Wide Dynamic Execution)”이라 칭한다.