메이저
MAJC디자이너 | Sun Microsystems |
---|---|
소개했다 | 1990년대 |
설계. | VLIW |
MAJC(Microprocessor Architecture for Java Computing)는 Sun Microsystems의 멀티코어, 멀티스레드, 매우 긴 명령어(VLIW) 마이크로프로세서 설계입니다.원래 UltraJava 프로세서라고 불렸던 MAJC 프로세서는 Java 프로그램을 실행하는 것을 목표로 하고 있었으며, 그 "늦은 컴파일"을 통해 Sun은 몇 가지 유리한 설계 결정을 내릴 수 있었습니다.이 프로세서는 Sun의 2개의 상용 그래픽 카드로 출시되었습니다.멀티코어 프로세서의 멀티스레드에 대해 학습한 교훈은 UltraSPARC T1 등의 향후 OpenSPARC 구현의 기반이 되었습니다.
설계 요소
명령 스케줄링을 컴파일러로 이동
다른 VLIW 설계, 특히 인텔의 IA-64(Itanium)와 마찬가지로 MAJC는 고가의 작업을 프로세서에서 벗어나 관련 컴파일러로 이행함으로써 성능을 향상시키려고 했습니다.일반적으로 VLIW 설계에서는 명령 스케줄러를 배제하려고 합니다.이것은 프로세서 전체의 트랜지스터 버젯의 비교적 많은 양을 차지합니다.CPU의 이 부분을 소프트웨어로 제거하면 트랜지스터는 다른 용도로 사용할 수 있습니다.또한 더 많은 명령을 한 번에 처리하기 위해 기능 유닛을 추가하거나 캐시 메모리의 양을 늘려 훨씬 느린 메인 메모리에서 데이터가 도착할 때까지 기다리는 시간을 줄일 수 있습니다.MAJC는 이러한 일반적인 개념을 공유하지만, 여러 가지 구체적인 세부 사항에서 다른 VLIW 설계 및 프로세서와는 달랐다.
범용 기능 단위
대부분의 프로세서에는 특정 유형의 데이터에 대해 작동하도록 조정된 기능 단위로 알려진 여러 개의 "하위 프로세서"가 포함되어 있습니다.예를 들어, 현대의 CPU에는 일반적으로 ALU라고 불리는 정수 데이터와 논리 명령을 처리하는 전용 기능 장치가 2개 또는 3개 있지만, 다른 장치는 부동 소수점 번호, FPU 또는 멀티미디어 데이터를 처리하는 대신 SIMD.MAJC는 모든 종류의 데이터를 처리할 수 있는 단일 다목적 기능 장치를 사용합니다.이론적으로 이 접근방식은 한 유형의 데이터를 처리하는 것이 해당 유형의 데이터 전용 유닛에서 동일한 데이터를 처리하는 것보다 더 오래, 어쩌면 훨씬 더 오래 걸린다는 것을 의미합니다.한편, 이러한 범용 유닛은, 프로그램이 특정의 시점에서 부동 소수점 계산을 다수 실시하고 있기 때문에, CPU의 대부분을 사용하지 않게 되는 일도 없습니다.
가변 길이 명령 패킷
또 다른 차이점은 MAJC가 가변 길이의 "명령 패킷"을 허용한다는 것입니다. VLIW에서는 컴파일러가 동시에 실행할 수 있다고 판단된 많은 명령이 포함되어 있습니다.대부분의 VLIW 아키텍처는 고정 길이 패킷을 사용하며 실행 명령을 찾을 수 없는 경우 대신 이 패킷을NOP
단순히 공간을 차지합니다.가변장 명령 패킷은 CPU의 복잡성을 증가시켰지만, 한 번에 캐시 내의 코드 양을 늘림으로써 코드 크기를 줄이고 값비싼 캐시 누락 횟수를 줄였습니다.
인터락 및 스톨 방지
주요 차이점은 MAJC 설계에서는 컴파일러가 인터락, 실행 중 일시정지 및 다음 명령의 실행 결과를 처리하지 않도록 해야 한다는 것입니다.예를 들어 프로세서에 명령어가 입력되어 있는 경우C = A + B, E = C + D
두 번째 명령은 첫 번째 명령이 완료된 후에만 실행할 수 있습니다.대부분의 프로세서에는 이러한 종류의 인터락된 명령어를 정지하고 스케줄을 변경할 수 있도록 설계에 잠금이 포함되어 있기 때문에 C 값을 계산하는 동안 다른 명령어를 실행할 수 있습니다.그러나 이러한 인터락은 칩의 실재성 측면에서 매우 비싸며 명령 스케줄러의 논리의 대부분을 나타냅니다.
컴파일러가 이러한 인터락을 회피하기 위해서는 각 명령어가 완료되기까지 걸리는 시간을 정확하게 파악해야 합니다.예를 들어 특정 구현이 부동소수점 곱셈을 완료하는 데 3주기가 걸렸을 경우 MAJC 컴파일러는 완료에 3주기가 걸리고 현재 정지되어 있지 않은 다른 명령으로 스케줄을 설정하려고 합니다.그러나 실제 구현이 변경되면 이 지연이 2개의 명령으로 줄어들 수 있으며 컴파일러는 이 변경에 대해 알아야 합니다.
즉, 컴파일러는 MAJC 전체를 MAJC와 연계한 것이 아니라 MAJC 설계에 근거한 각 CPU의 특정 실장입니다.이것은 통상, 심각한 로지스틱상의 문제가 됩니다.예를 들어 인텔 IA-32 설계의 다양한 바리에이션을 생각할 수 있습니다.각각 전용 컴파일러가 필요하기 때문에 개발자는 각각 다른 바이너리를 작성해야 합니다.그러나 Java 시장을 주도하는 것은 바로 이 개념입니다. 각 ISA에는 실제로 다른 컴파일러가 있으며 개발자가 아닌 클라이언트의 머신에 설치됩니다.개발자는 프로그램의 단일 바이트 코드 버전만 제공하고 사용자의 기계는 이를 기본 플랫폼으로 컴파일합니다.
실제로 이런 식으로 일정을 짜는 것은 매우 어려운 문제로 판명되었습니다.실제 사용에서는 실행 시 이 스케줄링을 시도하는 프로세서는 필요한 데이터가 캐시 외부에 있을 때 수많은 이벤트를 경험하며, 이러한 데이터에 의존하지 않는 다른 명령은 프로그램 내에 없습니다.이 경우 메인 메모리를 대기하면서 프로세서가 장시간 정지할 수 있습니다.VLIW 어프로치는, 이 점에 있어서 큰 도움이 되지 않습니다.컴파일러가 실행 순서를 찾는 데 더 많은 시간을 할애할 수 있을지는 모르지만, 그렇다고 해서 실제로 명령어를 찾을 수 있는 것은 아닙니다.
MAJC는 현재 스레드가 메모리에서 정지되어 있는 경우 다른 스레드에서 코드를 실행하는 기능을 통해 이 문제를 해결하려고 했습니다.스레드 전환은 일반적으로 컨텍스트스위치로 알려진 매우 고가의 프로세스로, 일반 프로세서에서는 스위치로 인해 절약되는 비용이 초과되어 일반적으로 머신의 속도가 느려집니다.MAJC에서는 시스템은 동시에 최대 4개의 스레드 상태를 메모리에 유지할 수 있으며 컨텍스트스위치를 몇 개의 명령으로 줄일 수 있습니다.이 기능은 그 후 다른 프로세서에서 사용되고 있습니다.인텔에서는 하이퍼라고 부릅니다.스레드화
MAJC는 이 아이디어를 한 걸음 더 나아가 스레드가 정지되어 있는 동안 스레드에 필요한 데이터와 명령어를 프리페치하려고 했습니다.대부분의 프로세서는 명령 스트림의 일부에 대해 유사한 기능을 포함하며, 여기서 프로세서는 결정 변수가 계산되기를 기다리면서 분기의 가능한 두 결과를 모두 실행합니다.대신 MAJC는 정지되지 않은 것처럼 스레드를 계속 실행하며 이 실행을 사용하여 스레드가 정지하지 않을 때 필요한 데이터 또는 명령을 찾아 로드합니다.Sun은 이를 STC(Space-Time Computing)라고 부르며 추측성 멀티스레딩 설계라고 합니다.
지금까지 프로세서는 단일 스레드에서 병렬 처리를 추출하려고 했습니다.이 기술은 수익 감소라는 측면에서 한계에 도달하고 있었습니다.일반적인 의미에서 MAJC 설계는 단일 스레드에서 병렬 처리를 찾는 것이 아니라 스레드(및 프로그램)를 통해 실행함으로써 정지되는 것을 피하려고 했던 것 같습니다.컴파일 시 런타임 동작을 이해하기 어렵기 때문에 VLIW는 일반적으로 스톨 측면에서 다소 악화될 것으로 예상되며, 이 문제에 대한 MAJC 접근법이 특히 흥미롭다.
실장
Sun은 MAJC의 단일 모델인 2코어 MAJC 5200을 구축하여 Sun의 XVR-1000 및 XVR-4000 워크스테이션 그래픽 보드의 핵심이었습니다.그러나 멀티코어 및 멀티스레딩 설계 아이디어의 대부분은 특히 여러 스레드를 사용하여 지연을 줄인다는 점에서 Sun SPARC 프로세서 라인뿐만 아니라 다른 회사의 설계에도 적용되었습니다.또, 순서와는 달리, 가능한 한 많은 스레드를 실행하도록 프로세서를 설계하는 MAJC의 생각은, 최신의 UltraSPARC T1(Niagara 코드명) 설계의 기초가 되는 것 같습니다.
「 」를 참조해 주세요.
추가 정보
- 사례, 브라이언(1999년 10월 25일).'미러로 MAJC를 만드는 태양'마이크로프로세서 리포트
- 린리주 구엔납(1999년 9월 13일)."MAJC는 VLIW에게 새로운 반전을 준다"마이크로프로세서 리포트
- 하프힐 톰(1999년 8월 24일)."태양은 '매직'의 비밀을 폭로한다"마이크로프로세서 리포트