Itanium 프로세서가 컴파일러를 작성하기 어려운 이유는 무엇입니까?

혁신적인 EPIC 명령어 세트 는 훌륭한 컴파일러를 작성하기가 매우 어려웠 기 때문에 인텔의 Itanium 64 비트 프로세서 아키텍처가 실패했다고 일반적으로 언급되어 있는데, 이는 IA64를위한 우수한 개발자 도구가 없기 때문에 개발자가 아키텍처를위한 프로그램을 만들지 못했음을 의미합니다. 그래서 많은 소프트웨어없이 하드웨어를 사용하기를 원하는 사람은 없었으며, 따라서 플랫폼은 실패했습니다.말굽 못 좋은 컴파일러.

그러나 왜 컴파일러가 어려운 기술적 문제였습니까? EPIC의 명시 적 병렬 처리가 컴파일러 공급 업체가 구현하기 어려웠다면 왜 그 부담을 맨 처음에 부과합니까? 이 문제에 대한 잘 이해 된 솔루션은 아직 존재하지 않았습니다. 대신 인텔에 부담을주고 컴파일러 작성자에게보다 간단한 목표를 부여하십시오.

Itanium은 1997 년에 출시되었습니다.이 시점에서 UCSD P-Code 바이트 코드 시스템은 거의 20 년이되었고 Z- 머신 은 약간 더 젊었 고 JVM은 프로그래밍 언어 세계에서 가장 새로운 떠오르는 별이었습니다. 인텔이 "간단한 Itanium 바이트 코드"언어를 지정하지 않은 이유가 있습니까?이 바이트 코드를 최적화 된 EPIC 코드로 변환하는 도구를 제공하여 시스템을 처음 설계 한 사람들의 전문성을 활용하십시오.

당시 기억했던 것처럼이 문제는 IA64의 특정 문제가 아니라 AMD의 x86-64 명령어 세트와의 경쟁이었습니다. AMD는 x86 명령어 세트와 호환되는 아키텍처를 제공함으로써 기존 도구와 개발자 기술 세트를 활용할 수있었습니다. AMD의 움직임은 인텔 (및 Via)이 본질적으로 x86-64 아키텍처를 채택하도록 강요되었습니다.

당시 가장 큰 장벽은 데스크톱 PC에서 4GB RAM이었습니다 (보다 사실적으로 Windows에서는 ~ 3.4GB 사용 가능). x86-64는 그 장벽을 깨뜨리고 모든 사람에게 더 높은 전력 컴퓨팅을 제공했습니다. AMD가 x86-64를 내놓지 않았다면, 인텔이 4GB + RAM으로 점프하려는 모든 사람들이 그 특권에 대해 몇 년 동안 엄청난 프리미엄을 지불하게되어 기뻤을 것입니다. 시장이 얼마나 느리게 움직이는 지 보여주기 위해 애플리케이션이 최대 64 비트, 멀티 스레드 프로그래밍을 잡는 데 몇 년이 걸렸으며 현재는 로우 엔드 PC에서 4GB RAM이 표준입니다.

요컨대, 인텔은 IA64 아키텍처로 혁신적인 도약을 시도했으며 AMD는 x86-64로 혁신적인 단계를 밟았습니다. 기존 시장에서 지식 근로자가 기존 기술을 활용할 수 있도록하는 혁신적인 단계는 모든 사람이 새로운 기술을 익히도록 요구하는 혁신적인 단계보다 우선합니다. 아키텍처 간의 질적 차이에 관계없이 IA64는 AMD가 x86-64 확장을 추가 한 후 자체 x86 플랫폼의 추진력을 극복 할 수 없었습니다.

나는 IA64가 프로그램하기가 너무 어렵다는 설명을 사지 않았다. 대안에 비해 어려웠습니다. 저수준 IR에 대한 @delnan의 요점은 부각됩니다. 나는 그것이 차이를 만들 것이라고 생각하지 않습니다.

인텔이 왜 그 부담을 스스로 해결하려하지 않았는가? 당시 시장의 힘이었습니다. AMD는 위협의 대상 이었지만 인텔은 언덕의 왕이었습니다. 아마도 그들은 IA64가 시장 전체를 움직일 수있는 다른 어떤 것보다 훨씬 나을 것이라고 생각했을 것입니다. 어쩌면 그들은 프리미엄 계층을 만들기 위해 노력하고 있었고, 인텔과 애플이 모두 성공적으로 채택한 전략 인 저수익 상품 하드웨어와 싸우는 두 번째 계층에서 AMD, VIA 등을 떠나려고했을 수도 있습니다.

Itanium은 프리미엄 플랫폼을 만들고 AMD, VIA 등에서 깔개를 꺼내려는 의도적 인 시도였습니까? 물론 비즈니스가 작동하는 방식입니다.

EPIC에 위키 백과 문서는 이미 VLIW와 EPIC에 공통적으로 많은 위험을 설명했다.

누구든지 그 기사에서 운명주의를 느끼지 않는다면 이것을 강조하겠습니다.

CPU 캐시 및 DRAM을 포함하는 메모리 계층 구조의로드 응답에는 결정적인 지연이 없습니다.

다시 말해, 메모리 액세스의 비 결정적 대기 시간 (*)에 대처하지 못하는 하드웨어 설계는 엄청난 실패가 될 것입니다.

(*) "대응"함으로써 합리적으로 우수한 실행 성능 (즉, "비용 경쟁력")을 달성해야하므로 CPU가 수십에서 수백주기 동안 유휴 상태에 빠지지 않도록해야합니다.

EPIC에서 채택한 대처 전략 (위의 위키피디아 기사에서 언급)은 실제로이 문제를 해결하지는 않습니다. 단지 데이터 의존성을 나타내는 부담이 이제 컴파일러에 달려 있다고 말합니다. 괜찮아; 컴파일러에는 이미 해당 정보가 있으므로 컴파일러가 간단하게 준수 할 수 있습니다. 문제는 CPU가 여전히 메모리 액세스를 통해 수십에서 수백주기 동안 유휴 상태가된다는 것입니다. 다시 말해서, 그것은 여전히 ​​일차적 책임에 대처하지 못하는 이차적 책임을 외부화한다.

"실패로 예정된 하드웨어 플랫폼을 제공 한 이유는 무엇입니까? 왜 (1) 컴파일러 작성자가 그것을 사용하기 위해 영웅적인 노력을 기울일 수 없었습니까?"

나는 나의 표현이 그 질문에 대한 답을 분명히 할 수 있기를 바랍니다.

실패의 두 번째 측면도 있으며 치명적입니다.

동일한 전략에서 언급 한 대처 전략은 소프트웨어 기반 프리 페치를 사용하여 메모리 액세스의 비 결정적 대기 시간으로 인한 성능 손실의 적어도 일부를 복구 할 수 있다고 가정합니다.

실제로 프리 페치는 스트리밍 작업 (순차적 또는 예측 가능한 방식으로 메모리 읽기)을 수행하는 경우에만 수익성이 있습니다.

즉, 코드가 지역화 된 일부 메모리 영역에 자주 액세스하면 캐싱이 도움이됩니다.

그러나 대부분의 범용 소프트웨어는 많은 임의의 메모리 액세스를 수행해야합니다. 다음 단계를 고려하면 :

• 주소를 계산 한 다음
• 값을 읽은 다음
• 일부 계산에 사용

대부분의 범용 소프트웨어의 경우이 세 가지를 빠르게 연속적으로 실행해야합니다. 다시 말해, 항상 소프트웨어 로직 범위 내에서 주소를 계산하거나이 세 단계 사이의 스톨을 채우기 위해 충분한 작업을 찾는 것이 항상 가능한 것은 아닙니다.

마구간을 채우기 위해 충분한 작업을 찾는 것이 항상 가능한 이유를 설명하는 데 도움이되는 방법은 다음과 같습니다.

• 실속을 효과적으로 숨기려면 메모리에 의존하지 않는 100 개의 명령을 채워야하므로 추가 대기 시간이 발생하지 않습니다.
• 이제 프로그래머로서 원하는 소프트웨어를 디스어셈블러에로드하십시오. 분석 할 랜덤 함수를 선택하십시오.
• 독점적으로 메모리 액세스가없는 100 개의 명령 (*) 시퀀스를 어디에서나 식별 할 수 있습니까?

(*) 우리 NOP가 유용한 일을 할 수 있다면 ...

최신 CPU는 파이프 라인을 순환하면서 각 명령의 진행 상황을 동시에 추적하여 동적 정보를 사용하여 동일한 문제를 해결하려고합니다. 위에서 언급했듯이 동적 정보의 일부는 비 결정적 메모리 대기 시간으로 인한 것이므로 컴파일러에서 어느 정도의 정확도를 예측할 수 없습니다. 일반적으로 컴파일 타임에 이러한 스톨을 채울 수있는 결정을 내릴 수있는 정보가 충분하지 않습니다.

AProgrammer의 답변에 대한 답변으로

「컴파일러 ・ ・ ・ 병렬의 추출은 어렵다」가 아닙니다.

최신 컴파일러의 메모리 순서 및 산술 명령 순서는 독립적으로 동시에 실행 가능한 작업을 식별하는 데 아무런 문제가 없다는 증거입니다.

주요 문제는 비 결정적 메모리 대기 시간은 VLIW / EPIC 프로세서 용으로 인코딩 된 "명령 쌍"이 메모리 액세스에 의해 중단 될 수 있다는 것을 의미합니다.

정지되지 않는 명령어 (레지스터 전용, 산술)를 최적화해도 정지 될 가능성이있는 명령어 (메모리 액세스)로 인한 성능 문제에는 도움이되지 않습니다.

80-20 최적화 규칙을 적용하지 못한 예입니다. 이미 빠른 것을 최적화하는 것은 느린 것들도 최적화되지 않는 한 전체 성능을 의미있게 향상시키지 않습니다.

Basile Starynkevitch 님의 답변에 답변

"... (어쨌든) 어려운"것은 아니지만, EPIC은 대기 시간의 높은 역 동성을 처리해야하는 모든 플랫폼에 적합하지 않습니다.

예를 들어, 프로세서에 다음이 모두있는 경우 :

• 직접 메모리 액세스가 없습니다.
  • 모든 메모리 액세스 (읽기 또는 쓰기)는 DMA 전송으로 예약해야합니다.
• 모든 명령어는 동일한 실행 대기 시간을 갖습니다.
• 순서대로 실행;
• 넓은 / 벡터화 된 실행 단위;

그러면 VLIW / EPIC이 적합 할 것입니다.

그러한 프로세서는 어디에서 찾을 수 있습니까? DSP. 그리고 이것이 VLIW가 번창 한 곳입니다.

뒤늦게 살펴보면, Itanium의 실패 (그리고 명백한 증거에도 불구하고 R & D 노력이 실패에 계속 부어지고 있음)는 조직적 실패의 한 예이며 깊이 연구 할 가치가 있습니다.

물론 하이퍼 스레딩, SIMD 등과 같은 벤더의 다른 벤처 기업은 큰 성공을 거둔 것으로 보입니다. Itanium에 대한 투자가 엔지니어의 기술에 풍부한 영향을 미쳤을 수 있으며,이를 통해 차세대 성공적인 기술을 만들 수있었습니다.

TL; DR : 1 / Itanium의 실패에는 컴파일러 문제 이외의 다른 측면이 있으며이를 설명하기에 충분할 수 있습니다. 2 / 바이트 코드는 컴파일러 문제를 해결하지 못했을 것입니다.

획기적인 EPIC 명령어 세트는 훌륭한 컴파일러를 작성하기가 매우 어려웠 기 때문에 인텔의 Itanium 64 비트 프로세서 아키텍처가 실패했다고 일반적으로 언급됩니다

글쎄, 그들은 또한 늦었고 (98 년에 예정되어 있으며, 2001 년에 첫 출하 예정), 마침내 하드웨어를 제공했을 때, 그것이 이전 날짜에 약속 된 것을 전달했는지 확실하지 않습니다 (IIRC, 그들은 적어도 x86 에뮬레이션은 처음에 계획되었으므로 컴파일 문제가 해결되었지만 (아마 AFAIK는 아직 해결되지 않았다고해도) 성공했을지 확실하지 않습니다. 컴파일러 측면 만 지나치게 야심 찬 측면은 아니었다.

인텔이 "간단한 Itanium 바이트 코드"언어를 지정하지 않은 이유와이 바이트 코드를 최적화 된 EPIC 코드로 변환하는 툴을 제공하여 시스템을 처음 설계 한 사람들의 전문성을 활용하고 있습니까?

도구를 어디에 놓을 지 잘 모르겠습니다.

프로세서에 있으면 다른 마이크로 아키텍처 만 있고 x86을 공개 ISA로 사용하지 않을 이유가 없습니다 (적어도 인텔의 경우 비 호환성에 더 깨끗한 공개 ISA를 가져올 수있는 것보다 비용이 많이 듭니다).

외부에서 바이트 코드로 시작하면 고급 언어에서 시작하는 것보다 훨씬 어렵습니다. EPIC의 문제점은 컴파일러가 찾을 수있는 병렬 처리 만 사용할 수 있고 병렬 처리를 추출하는 것이 어렵다는 것입니다. 언어 규칙을 아는 것은 이미 예약 된 것에 제약을받는 것보다 더 많은 가능성을 제공합니다. 저의 (신뢰할 수 없으며, 멀리서 그 뒤를 따랐던 사람으로부터) 인정한 것은 HP (*)와 인텔이 컴파일러에서 달성하지 못한 것은 언어 수준의 병렬 처리 (병렬로 표현 된 낮은 수준이 아니라)입니다. 암호.

현재 프로세서가 성능을 달성하는 데 드는 비용을 과소 평가했을 수 있습니다. OOO는 다른 가능성보다 더 효과적이지만 확실히 비효율적입니다. EPIC은 더 많은 원시 컴퓨팅을 제공하기 위해 OOO의 구현에 사용 된 영역 예산을 사용하기를 원했으며, 컴파일러가이를 사용할 수 있기를 희망했습니다. 위에서 언급했듯이 AFAIK, 심지어 이론적으로도 그 기능을 가진 컴파일러를 작성할 수는 없지만 Itanium은 늦었고 구현하기 어려운 다른 기능을 충분히 갖추고 있었기 때문에 원시 전력은 그렇지 않았습니다. 팹에서 나왔을 때 다른 고급 프로세서와 경쟁 할 수도 있습니다 (FP 계산이 많은 일부 틈새 시장에서 제외).

(*) 또한 EPIC에서 HP의 역할을 과소 평가하는 것 같습니다.

몇 가지.

IPF는 순서대로 진행되었습니다. 이는 캐시 미스 또는 기타 장기 실행 이벤트가 발생했을 때 다시 저장하지 않아도된다는 의미입니다. 결과적으로 추론 적 기능, 즉 추론 적 하중 (실패한 하중-하중 결과가 필요한지 알지 못하는 경우 유용) 및 고급 하중 (불가능한 하중에 의존해야 함) 위험이 발생한 경우 복구 코드를 사용하여 다시 실행하십시오.) 이러한 권한을 얻는 것이 특히 고급로드였습니다! 또한 일반적으로 기존 컴파일러가 아닌 어셈블리 프로그래머 나 프로파일 가이드 최적화를 사용하여 지능적으로 만 사용할 수있는 분기 및 캐시 프리 페치 힌트도있었습니다.

당시의 다른 시스템, 즉 UltraSPARC은 순서가 있었지만 IPF도 다른 고려 사항이있었습니다. 하나는 인코딩 공간이었습니다. Itanium 명령어는 본질적으로 특히 밀도가 높지 않았습니다. 128 비트 번들에는 3 개의 작업과 5 비트 템플릿 필드가 포함되어 있으며 번들의 작업을 설명하고 모두 함께 발행 할 수 있는지 여부를 설명합니다. 이는 효과적인 42.6 비트 작업 크기를 위해 만들어졌으며 당시 대부분의 상용 RISC 작업에서 32 비트와 비교되었습니다. (이것은 Thumb2 이전이었습니다. RISC는 여전히 고정 길이 강성을 의미했습니다.) 더 나쁜 것은, 사용하는 템플릿에 맞는 ILP가 항상 충분하지는 않았기 때문에 NOP- 패드를 작성해야합니다. 템플릿 또는 번들. 이것은 기존의 상대적 저밀도와 결합하여 적절한 i- 캐시 적중률을 얻는 것이 매우 중요하다는 것을 의미했습니다.

나는 항상 "컴파일러가 유일한 문제"라는 주장이 과장되었다고 느꼈지만, 범용 코드에 대해 I2를 선호하지 않는 합법적 인 마이크로 아키텍처 문제가 있었다-비교할 코드를 생성하는 것은 특히 재미 있지 않았다 더 좁고 높은 클럭의 OoO 머신에. 실제로 PGO 또는 수동 코딩과 관련된 내용을 제대로 채울 수 있었을 때 훌륭했습니다. 그러나 많은 시간을 할애 해 컴파일러의 성능은 정말 고무적이지 않았습니다. IPF는 훌륭한 코드를 쉽게 생성 할 수 없었으며 코드가 좋지 않을 때는 용서할 수 없었습니다.

그러나 왜 컴파일러가 어려운 기술적 문제였습니까? EPIC의 명시 적 병렬 처리가 컴파일러 공급 업체가 구현하기 어려웠다면 왜 그 부담을 맨 처음에 부과합니까? 그것은 이미 존재하지 않는이 문제에 대한 잘 이해 된 좋은 해결책은 아닙니다. 대신에 인텔에게 그 부담을두고 컴파일러 작성자에게 더 간단한 목표를 부여하십시오.

당신이 설명하는 것은 Transmeta 가 코드 모핑 소프트웨어 (x86 "바이트 코드"를 Transmeta 내부 기계 코드로 동적으로 변환하는)로 수행하려고 한 것입니다.

인텔은 IA64에 대한 충분한 컴파일러를 만들기 위해 실패 않은 이유에 ... 나는 그들이하지 않았 음을 추측 충분히 컴파일러 전문 지식을 집에서 그들이 가지고있는 않은 경우에도 물론 경우 ( 일부 내부 아주 좋은 컴파일러 전문가 만하는 것만으로는 충분하지 아마 임계 질량을 만듭니다). 그들의 경영진이 컴파일러를 만드는 데 필요한 노력을 과소 평가했다고 생각합니다.

AFAIK, Intel EPIC은 EPIC에 대한 컴파일이 매우 어렵고, 컴파일러 기술이 서서히 점진적으로 개선 될 때 컴파일러 (예 : AMD64)를 개선하여 일부 컴파일러 노하우를 공유 할 수있는 다른 경쟁 업체 때문에 실패했습니다.

BTW, 저는 AMD64가 RISCy 명령어 세트가되기를 바랍니다. 그것은 일부 POWERPC64 일 수 있습니다 (그러나 아마도 특허 문제, 그 당시의 Microsoft 요구 등 때문이 아님). x86-64 명령어 세트 아키텍처는 실제로 컴파일러 작성기의 "아주 좋은"아키텍처가 아니지만 "어떻게"충분한 "것입니다.

또한 IA64 아키텍처에는 몇 가지 강력한 제한 사항이 있습니다. 예를 들어 프로세서에 3 개의 기능 단위가있어 처리 할 수있는 한 3 개의 명령어 / 단어가 좋았지 만, 인텔이 새로운 IA64 칩에 들어가면 더 많은 기능 단위가 추가되었습니다. 레벨 병렬 처리는 다시 한 번 달성하기 어려웠다.

아마도 RISC-V (오픈 소스 ISA)는 다른 프로세서와 경쟁하기에 점차적으로 성공할 것입니다.

Robert Munn이 지적한 것처럼 Itanium (및 다른 많은 "새로운"기술)을 죽인 것은 이전 버전과의 호환성이 부족했습니다.

새 컴파일러를 작성하는 것이 어려웠지만 몇 개만 있으면됩니다. 최적화 된 코드를 생성하는 AC 컴파일러는 필수입니다. 그렇지 않으면 사용 가능한 운영 체제가 없습니다. C ++ 컴파일러 인 Java가 필요하며 기본 사용자 기반은 Windows 일종의 Visual Basic 일 것입니다. 따라서 이것은 실제로 문제가되지 않았습니다. 괜찮은 운영 체제 (NT)와 좋은 C 컴파일러가있었습니다.

소프트웨어 제품을 제공하는 회사에게는 사소한 노력처럼 보일 것입니다. C 코드베이스를 다시 컴파일하고 다시 테스트하십시오. 32 비트 정수를 가정하고 32 비트 어드레싱을 네이티브 64 비트 아키텍처로 변환하는 큰 C 프로그램 세트를 변환하는 것은 함정으로 가득 차있었습니다. IA64가 지배적 인 칩 (또는 인기있는 칩)이 되었기 때문에 대부분의 소프트웨어 회사는 총알을 물고 노력했을 것입니다.

합리적인 OS를 갖춘 매우 빠른 칩이지만 사용 가능한 소프트웨어는 매우 제한적이므로 많은 사람들이이 소프트웨어를 구입하지 않았기 때문에 많은 소프트웨어 회사가 해당 제품을 제공하지 않았습니다.

Itanium을 죽인 것은 소프트웨어 공급 업체가 64 비트 앱을 위해 IA64로 마이그레이션하기 전에 AMD64가 개입하기 시작한 선적 지연 때문이었습니다.

컴파일러에 최적화를 두는 것이 좋습니다. 그렇지 않으면 하드웨어에서 비효율적 인 많은 것들이 정적으로 수행 될 수 있습니다. 컴파일러는 특히 PGO 프로파일 링을 사용할 때 상당히 능숙 해졌습니다 (저는 HP에서 근무했으며 HP의 컴파일러는 인텔의 성능을 능가하는 경향이있었습니다). PGO는 판매량이 많았지 만 생산 코드를 처리하기가 어렵습니다.

IPF는 이전 버전과 호환 될 수 있었지만 일단 AMD64가 출시되면 전투가 중단되고 CPU의 X86 하드웨어가 서버 CPU로 리 타게팅하기 위해 제거되었습니다. 아키텍처로서의 Itanium은 나쁘지 않았으며, 단어 당 3 개의 명령은 문제가되지 않았습니다. 문제는 메모리 IO 동안 스택을 스왑하여 하이퍼 스레딩 구현이 Montecito 등으로 인해 순서가 잘못된 PowerPC CPU와 경쟁하지 못하게 할 때까지 너무 느립니다 (파이프를 비우고 파이프 라인을 다시로드하기 위해). 컴파일러는 CPU 구현의 늦게 탐지 된 결함을 패치해야했으며 일부 성능상의 이점은 실수를 예측하기가 어려웠습니다.

아키텍처는 Itanium이 비교적 단순하면서도 컴파일러가 성능을 발휘할 수있는 도구를 제공했습니다. 플랫폼이 작동했다면 CPU가 더 복잡해지고 결국 x86과 같이 순서가 맞지 않게 스레드됩니다. 그러나 첫 번째 세대는 컴파일러가 많은 어려운 작업을 처리했기 때문에 다른 성능 체계에 트랜지스터 수를 집중 시켰습니다.

IPF 플랫폼은 컴파일러와 툴에 내기를 걸 었으며, 매우 완벽하고 강력한 PMU (Performance Monitoring Unit) 설계를 공개 한 최초의 아키텍쳐였으며, 나중에 Intel x86으로 이식되었습니다. 따라서 강력한 도구 개발자는 여전히 코드를 프로파일 링 할 수있는 능력을 발휘하지 못합니다.

ISA의 성공을 살펴보면 주사위를 굴리는 것은 기술적 인 측면이 아닙니다. 그것은 시간과 시장의 힘에 자리 잡고 있습니다. SGI Mips, DEC Alpha ...를 살펴보십시오. Itanium은 전략적 비즈니스 실수로 쌓여있는 경영진이있는 느슨한 SGI 및 HP 서버에 의해 지원되었습니다. 마이크로 소프트는 AMD와 함께 박스형이되지 않기 위해 AMD64를 완전히 수용하지 못했으며, AMD와 함께 스너프 (snuff)를하기 ​​위해 AMD와 협력하여 생태계에서 살 수있는 방법을 제공하지 않았습니다.

우리가 현재 어디에 있는지 살펴보면, X86의 복잡한 하드웨어는 지금까지 진화의 막 다른 골목으로 이끌었습니다. 우리는 3 + GHz에 갇혀 있으며 코어를 충분히 사용하지 못합니다. Itanium의 더 단순한 설계는 더 얇고 빠른 파이프 라인을 구축 할 수 있도록 컴파일러에 더 많은 자료를 제공 할 것입니다 (성장의 여지). 같은 세대와 팹 기술에서 무어의 법칙을 강요하기 위해 다른 문이 열리면서 더 빨리 달리고 조금 더 높았을 것입니다.

글쎄, 적어도 위의 신념입니다 :)

메모리가 모호 해지고 있습니다. Itanium에는 훌륭한 컴파일러 지원이 필요한 훌륭한 아이디어가있었습니다. 문제는 하나의 기능이 아니라 많은 것이 었습니다. 각각 큰 문제는 아니었고 모두 함께있었습니다.

예를 들어 루프의 한 반복이 다른 반복의 레지스터에서 작동하는 반복 기능이있었습니다. x86은 대규모 비 순차 기능을 통해 동일한 문제를 처리합니다.

당시에는 Java와 JVM이 유행했습니다. IBM이 말한 바에 따르면 PowerPC를 사용하면 바이트 코드를 빠르게 컴파일 할 수 있으며 CPU가이를 빠르게 만들 수 있습니다. Itanium에는 없습니다.