VLIW라는 컨셉을 정말 제대로 설명해주는 한장입니다.

슈퍼스칼라가 게이트/전력 소요가 심하다 -> 컴파일러가 대신 사전에 컴파일 할때부터 코드를 병렬화시켜 넣어주면 되겠군! 이란 발상인데...

당연하지만 '계획'대로만 굴러가는 일만 있을거 같으면 애시당초 그렇게 성능향상이 힘겹지 않았겠죠.

일단 컴파일러가 '그럴싸한 계획'을 잡아주는 단계에서 부터 난이도가 하늘로 올라갑니다. 일단 적당히 던져주면 알아서 잘 재정렬해서 삼켜주는 슈퍼스칼라도 컴파일러 최적화가 빡센 판에, 아예 처음부터 코드를 최적의 순서로 병렬화까지 해서 먹여야 하는 VLIW는 그냥 난이도가 급이 다릅니다.

문제는 거기서 끝나지 않아서 컴파일러가 '그럴싸한 계획'을 만들어서 CPU에 건네주고 나서도 또 인실좆의 향연이 펼쳐집니다. 

첫째로 애시당초 '그럴싸한 계획' 같은걸 만드는게 불가능한 경우입니다. 예를 들어 앞에서 실행된 명령의 결과값을 받아서 뒤의 명령이 실행되어야 하는 연쇄가 이어지는 코드가 있어야 한다고 칩시다. 이 경우 우리의 이타늄에게 이 명령을 먹이면 그 널찍한 실행 파이프라인에서 꼴랑 1,2개만 명령을 실행하고 있게 됩니다.

둘째로 '그럴싸한 계획'에서 상정한 가정을 벗어나는 상황이 발생하는 경우입니다. 캐시 미스가 발생해서 메모리를 기다려야 하는 상황이라면 일반적인 OoOE 슈퍼스칼라 프로세서라면 적당히 실행순서를 자체적으로 가능한한 선 안에서 손을 봐서 다른 명령을 우선 실행한다던가 하는 유연성을 보여줄 수 있겠으나 VLIW에선 그게 안됩니다. 그렇게 되면 그 널찍한 파이프에 채워넣었던 많은 수의 명령을 다 집어치우고 다시 채워넣는다던가, 기약없이 억겁의 세월동안 늘어지는 램을 기다리던가 하는 뻘짓을 해야 합니다. 분기명령도 마찬가집니다. 싹 다 치우고 다시 해야하는데 성능저하가 치명적일 정도라 쥐약이죠.

결국 인텔의 '그럴싸한 계획' 아이태니엄은 그렇게 x86-64에게 죽빵을 맞고 다운되었습니다...