대충 추정컨데 두가지 입니다.

그리고 두 가지가 결국은 명령어셋의 우열로 귀결됩니다.

우선 ARM64는 범용 레지스터가 31개로 15개인 x86의 두배에요.  거기에 3오퍼랜드 연산, 즉 c=a+b가 기본지원됩니다.  x86은 2오퍼랜드 연산만 되죠. 즉 b=a+b만 할 수 있고 c=a+b는 할 수 없습니다...  아직도요....

ARM64의 컴파일러는 소스코드에서 바이너리를 생성하는 과정에서 병렬실행 가능한 부분들을 충분한 시간을 들여(CPU 관점에서는 사실상 거의 무한정의 시간입니다) 찾아내서 한 번에 31개의 레지스터에 끌어올려서 단 1클럭에 ALU에서 실행할 수 있는 실행 바이너리를 만들어 내는 게 가능합니다. 병렬실행 가능한 코드를 명시적으로 컴파일러가 생성하기 매우 쉽죠.

반면 x86은 레지스터 숫자가 절반에 불과하다 보니 컴파일러가 병렬실행이 가능한 부분을 소스코드에서 찾아내도 레지스터에 모두 배치하지를 못합니다. 레지스터로 배치 못하는 명령어들은 메모리(주로 L1캐시)상에서 로드 된 후에 나중에  ALU로 가야 하니 결국 1클럭당 병렬실행을 할 수 있도록 바이너리 생성을 제대로 못해내는 거죠.

물론 그런 문제점들을 완화하기 위해 CPU에는 내부 히든레지스터가 있어서(아키텍처 설명에서 주로 나오는 레지스터 파일 100여개 등등이 그겁니다.) CPU 스스로도 런타임에 병렬성을 찾아내도록 되어 있습니다만...

컴파일러가 충분한 시간을 들여서 찾아낸 바이너리의 병렬성과 CPU가 런타임에 불과 몇클럭 사이에 바이너리에서 추가로 찾을 수 있는 병렬성의 숫자는 격차가 날 수 밖에 없습니다.  게다가 히든레지스터 설계는 ARM이든 x86이든 현대 CPU설계들은 기본적으로 들어가 있는 거라서 x86만 이득을 보는 것도 아닙니다.

즉 IPC 관점에서는 명령어셋의 우열에 의해  말 그대로 격차가 발생할 수 밖이 없는 조건입니다. 

두번째는 x86특유의 지저분한 폐기물급 명령어 구조입니다.  예를 들어 버거킹에서 햄버거용 재료가 본사에서 들어오는걸 생각해 보면 되는데 재료박스 사이즈는 제각각인데다가 거기 들어있는 빵, 패티, 야채, 소스 등등이 정리되지 않고 마구 섞여 들어오는 식입니다. 그러니 뒤섞인 식자재를 수령하는 것도 박스사이즈가 제각각이라 힘들고 정리해서 분리하는  것도 안의 내용물이 개판으로 섞여 있어서 힘들고...  뭘 해도 힘드니까 결국 결과물인 uOP를 한 번에 뽑아내는 숫자를 늘리기 어렵죠.   AMD의 언급도 딱 그거고요. 디코더 성능을 올리려고 했더니 설계가 복잡해지면서 오히려 전반적인 성능이 떨어질 정도라고.   

반면 ARM64는 재료박스 사이즈가 정확히 규격화 되어 있어서 실어나르기도 편하고 박스 내의 파티션도 고정되어 있어서 디코딩부가 일하기 훨씬 쉽습니다.  그러니 필요하면 한 번에 뽑아내는 uOP의 숫자를 확 늘릴 수도 있는 것이고...  

물론 x86도 그 문제를 완화하기 위해서 uOP캐시 등의 구조를 일찌감치 도입 했지만...  그래봤자 캐시라는 존재는 미스 나면 결국 디코더가 다시 출동해야만 하는 물건이고  그 uOP캐시는 요즘은 ARM64에도 달려나오는 거에요...   x86이 uOP공급 대역폭을 uOP캐시만 철썩같이 믿고 가야하는 동안  ARM64는 디코더와 uOP캐시 둘 다를 원활하게 활용할 수 있으니  그 유연성은 상대가 안되는 겁니다. 

한놈은 칼이 형편없고 방패가 좋은데 상대놈은 칼도 방패도 다 좋으면 상대놈이 훨씬 유리할 수 밖에 없죠.

세줄요약.

1. x86은 명령어셋의 한계로 인해 레지스터가 절반에 불과해서 컴파일러가 못찾는 병렬성을 CPU가 감당해야 한다.  반면 ARM64는 컴파일러도 충분한 시간을 들여 병렬성을 찾아내고 CPU도 또한번 병렬성을 찾아서 실행한다.

2. x86 디코더는 개판인 명령어셋을 한땀한땀 풀어내서 uOP로 변환하는 빡센 작업을 수행해야 한다. ARM64는 그런 거 없다. 하도 빡세서 x86이 uOP캐시를 도입했더니 정작 ARM64도 그걸 도입했다.

3. 뭘 해도 x86은 나쁜칼과 좋은방패를 싸우는 상황인데 ARM64는 좋은칼과 좋은방패로 싸우는 상황이다. IPC싸움에서 근본적으로 밀릴 수 밖에 없다.