CPU는 어떻게 사이클 당 하나 이상의 명령을 전달할 수 있습니까?


41

Wikipedia의 초당 지침 페이지에 따르면 i7 3630QM은 3.2GHz 주파수에서 ~ 110,000 MIPS를 제공합니다. (110 / 3.2 명령) / 4 코어 = 코어 당 사이클 당 ~ 8.6 명령입니까?! 단일 코어가 사이클 당 둘 이상의 명령어를 어떻게 제공 할 수 있습니까?

내 이해에 따르면 파이프 라인은 클럭 당 하나의 결과 만 제공 할 수 있어야합니다.

이것들은 내 생각입니다 :

  • 내부 주파수는 실제로 3.2GHz보다 높습니다
  • CPU의 일부는 나와 같은 겸손한 사람이 이해할 수없는 방식으로 비동기식입니다.
  • 코어 당 여러 개의 동시 파이프 라인이 있습니다
  • 파이프 라인은 클럭 당 결과 이상을 제공 할 수 있으며, 명령은 파이프 라인 단계를 건너 뛸 수 있으며 유지할 프리 페 처가 여러 개 있습니다.
  • 뭔가 빠졌습니다

1
110,000 Dhrystone MIPS를 제공 하므로 MIPS가 아닌 DMIPS는 내가 직접 볼 수있는 것입니다. 참조 en.wikipedia.org/wiki/Dhrystone

답변:


44

먼저, Keelan의 의견Turbo J의 답변에서 지적했듯이 측정은 네이티브 MIPS가 아닌 113,093 Dhrystone MIPS입니다.

i7 3630QM의 아이비 브릿지 (Ivy Bridge) 마이크로 아키텍처는 사이클 당 4 개의 융합 된 µops 만 커밋 할 수 있지만 사이클 당 6µops의 실행을 시작할 수 있습니다. (코드 트레이스에서 융합 된 µops 의 수는 명령어 수와 대략 동일합니다. 일부 복잡한 명령어는 융합되지 않은 여러 µops로 디코딩되며 일부 명령어 쌍은 단일 µop에 융합 될 수 있습니다 (예 : 즉시 비교) 조건부 점프가 뒤 따릅니다.)

단일 사이클에서 여러 명령을 실행하는 방법에 대한 두 가지 추측은 상당히 유효하며 실제 프로세서에서 사용되었습니다. 더 빠른 내부 시계가 사용된다는 첫 번째 추측은 원래 Pentium 4의 "fireball"ALU에 사용되었습니다. 이 ALU는 나머지 코어 주파수의 두 배로 클럭되었으며 이미 상대적으로 높았습니다.

(이것은 엇갈린 ALU를 사용하여 수행되었습니다. 추가의 절반이 한 사이클로 완료되었으므로 종속 작업이 다음 사이클에서 결과의 절반을 사용할 수 있습니다. add, xor 또는 left shift와 같은 조작의 경우 너비 파이프 라인이라고도하는 스 태거 링은 단일 사이클 결과 대기 시간 및 단일 사이클 처리량을 허용합니다.)

약간 관련된 기술인 계단식 ALU가 HyperSPARC에 의해 사용되었습니다. HyperSPARC는 두 ALU의 결과를 세 번째 ALU로 제공했습니다. 이를 통해 두 번의 독립 작업과 세 번째 종속 작업을 단일 주기로 실행할 수 있습니다.

"코어 당 여러 개의 동시 파이프 라인이있다"는 사용자의 추측은 다른 기법입니다. 이러한 유형의 설계를 슈퍼 스칼라라고하며 단일주기에서 실행되는 작업 수를 늘리는 가장 일반적인 방법입니다.

주목할만한 몇 가지 다른 확률과 명령 실행 끝이 있습니다. 일부 작업은 일반 실행 장치 외부에서보다 효율적으로 수행 할 수 있습니다. 이동 제거 기술은 비 순차적 프로세서에서 레지스터 이름 바꾸기를 사용하여 레지스터 이름을 바꾸는 동안 이동 작업을 수행합니다. 이동은 단순히 이름 바꾸기 테이블의 한 위치 (레지스터 별명 테이블)에서 다른 위치로 실제 레지스터 번호 를 복사합니다 . 이를 통해 실행 너비가 효과적으로 증가 할뿐만 아니라 종속성도 제거됩니다. 이 기술은 스택 기반 x87에서 초기에 사용되었지만 이제는 인텔의 고성능 x86 프로세서에서 널리 사용됩니다. (x86에서 파괴적인 2 연산 명령어를 사용하면 일반적인 RISC보다 이동 제거가 더 유용합니다.)

이동 제거와 유사한 기술은 이름을 바꾸는 동안 레지스터 제로화 명령을 처리하는 것입니다. 0 값을 제공하는 레지스터 이름을 제공하면 레지스터 지우기 명령 (xor 또는 같은 두 피연산자가 같은 레지스터 인 빼기 등)만으로 해당 이름을 이름 바꾸기 테이블 (RAT)에 삽입 할 수 있습니다.

일부 x86 프로세서에서 사용되는 다른 기술은 푸시 및 팝 작업 비용을 줄입니다. 일반적으로 스택 포인터를 사용하는 명령은 스택 포인터의 값을 업데이트하기 위해 이전 푸시 또는 팝을 위해 전체주기를 기다려야합니다. 푸시 앤 팝은 스택 포인터에 작은 값을 더하거나 뺄뿐임을 인식함으로써 여러 가산 / 감산 결과를 병렬로 계산할 수 있습니다. 추가를위한 주요 지연은 캐리 전파이지만 작은 값을 사용하면 기본 값의 더 중요한 비트 (이 경우 스택 포인터)는 최대 하나의 캐리 인을 갖습니다. 이는 캐리 선택 가산기와 유사한 최적화가 작은 값의 여러 추가에 적용될 수 있도록합니다. 또한 스택 포인터는 일반적으로 상수에 의해서만 업데이트되므로

명령을보다 복잡한 단일 작업으로 병합 할 수도 있습니다. 명령어를 여러 개의 더 간단한 작업으로 분리하는 역 프로세스는 오래된 기술이지만, 명령어를 병합하면 (인텔이라는 매크로-옵 퓨전) 구현에서 명령어 집합에 노출 된 것보다 복잡한 작업을 지원할 수 있습니다.

이론적 인 측면에서 다른 기술이 제안되었습니다. RAT에서는 0 이외의 작은 상수가 지원 될 수 있으며 이러한 작은 값을 사용하거나 안정적으로 생성하는 일부 간단한 작업은 조기에 처리 될 수 있습니다. Mikko H. Lipasti 등 (2004)은 "물리적 레지스터 인라이닝"을 통해 레지스터 수를 줄이는 수단으로 RAT를 사용할 것을 제안했지만이 아이디어는 적은 수의 즉각적인 작업과 간단한 작업로드를 지원하도록 확장 될 수 있습니다.

추적 캐시 (제어 흐름의 특정 가정하에 명령 시퀀스를 저장)의 경우 분기로 분리 된 작업을 병합하고 추적에서 사용되지 않은 결과를 생성하는 작업을 제거 할 수 있습니다. 추적 캐시에서 최적화 캐싱을 수행하면 명령 스트림을 가져올 때마다 수행해야 할 경우 가치가없는 명령 병합과 같은 최적화를 수행 할 수 있습니다.

값 예측은 종속성을 제거하여 병렬로 실행할 수있는 작업 수를 늘리는 데 사용될 수 있습니다. 보폭 기반 값 예측기는 앞서 언급 한 특수 스택 엔진의 팝 / 푸시 최적화 와 유사 합니다. 직렬화를 제거하여 대부분 병렬로 여러 개의 덧셈을 계산할 수 있습니다. 값 예측의 일반적인 아이디어는 예측 된 값으로 종속 작업이 지연없이 진행될 수 있다는 것입니다. (지점 방향 및 목표 예측은 사실상 매우 제한된 값 예측 형식으로, 분기의 "값"(취득 여부에 따라)과 다음 명령 주소, 또 다른 값에 따라 다음 명령을 페치 할 수 있습니다.


대박! 소중한 정보 감사합니다. 이 모든 건축 기법을 읽을 수있는 책을 제안 해 주시겠습니까?
직장에서

@workless 파이프 라이닝 및 비 순차 슈퍼 스칼라 실행의 기본 사항 (대부분의 컴퓨터 아키텍처 교과서에서 다룰 것)을 넘어 서면 정보의 가장 좋은 출처는 특정 프로세서 마이크로 아키텍처에 대한 설명 일 것입니다 (예 : Haswell 링크에있는 기사). 에 gnasher729의 대답 ) HPCA, PACT, ASPLOS을, 그리고 아마도 몇 가지 다른도 좋은 평판을 가지고)과 학술 논문 (ISCA 및 MICRO [컨퍼런스] 일반적으로 좋은 논문이있다. 앤디 Glew (펜티엄 프로에 그의 작품에 대한 아마도 가장 유명한) ...
폴 A. 클레이튼

1
...보다 고급 개념을 제시하는 CompArch Wiki에서 작업하고 있었지만 진행 속도가 느리고 얼마 전에 해킹되었으므로 오류 메시지 ( semipublic.comp-arch.net/wiki ) 만 제공합니다 . 그는 다른 위키 소프트웨어를 사용하여 위키 (원본 텍스트는 보존 됨)를 복원하려고합니다 (그는 사용중인 소프트웨어에 문제가있어서이를 개선 할 수있는 기회로 삼고 있습니다).
Paul A. Clayton

슈퍼 스칼라 아키텍처의 성공에 대한 좋은 예는 인텔의 하이퍼 스레딩 (Intel 's HyperThreading)입니다. 모든 최적화를 통해 인텔 엔지니어들은 메모리가 충분히 빨리 흐를 수 없거나 파이프 라인을 효율적으로 채울 수 없습니다. HyperThreading을 사용하면 이상적인 시나리오에서 많은 작업을 무료로 얻을 수 있습니다. 별도의 새 코어를 사용하는 것보다 훨씬 저렴하지만 훨씬 저렴합니다 (멀티 코어와 결합 할 수도 있음).
Luaan

@ PaulA.Clayton-해당 페이지의 두 가지 캡처가 Wayback에 있습니다. 2013 년 12 월 20 일 및 2014 년 2 월 14 일 . 해당 캡처가 페이지의 문제보다 먼저 발생하는지 모르겠습니다. 불행히도, Wayback에서 해당 페이지를 방문하려고 할 때 " Bummer. 이 파일을 제공하는 시스템이 다운되었습니다. 작업 중입니다. "라는 메시지가 표시됩니다. 따라서 해당 페이지에서 볼 수있는 것이 확실하지 않습니다. .
Kevin Fegan

10

현대의 프로세서 내부에서 약간의 어두운 마법이 발생하지만, 당신의 생각은 분명히 올바른 방향을 따릅니다.

최신 프로세서의 효율성을 이해하는 열쇠는 슈퍼 스칼라 라는 사실을 깨닫는 것입니다 . Wikipedia (강조 광산)에서 :

슈퍼 스칼라 CPU 아키텍처 는 단일 프로세서 내에서 명령 수준 병렬 처리라는 병렬 처리 형식을 구현합니다 . 따라서 주어진 클럭 속도에서 가능한 것보다 더 빠른 CPU 처리량을 허용 합니다.

이 최신 프로세서에는 코어 당 여러 개의 실행 단위가 있습니다. 하이퍼 스레딩 은 흥미로울 것입니다. 파이프 라인의 일부는 복제되었지만 일부는 그렇지 않습니다.

비 순차적 실행 은 읽는 것도 흥미롭지 만 질문에 직접 대답하지는 않습니다. "폐기 된"CPU주기 수를 줄입니다.

효율성은 또한 프로세서 내부에서 스톨을 일으킬 수있는 다른 많은 것들의 영향을받습니다.

  • 이전 지침의 결과를 사용할 수 없습니다.
  • 캐시 미스.
  • 이미 가져온 명령어를 무효화하는 코드 분기 ( 여기여기에서 분기 예측에 대해 읽음 )

최신 컴파일러는 위의 많은 항목을 처리하려고 시도하고 프로세서가 대신합니다. 좋은 예를 보려면 Stackexchange의 다른 곳 에서이 질문을 참조하십시오. 이 질문 은 동일한 상황에서 (일부 상황에서) 동일한 작업을 수행 할 수있는 두 명령의 중요한 차이점을 강조합니다. 그러나 사용중인 실행 단위로 인해 일부 프로세서에서는 하나가 다른 프로세서보다 "빠르다".

최신 CPU 파이프 라인에 대한 사람이 읽을 수있는 설명은 CPU 파이프 라인을 통한 여정을 참조하십시오 . 다소 기술적 인 설명은 Agner Fog의 Microarchitecture 논문을 참조하십시오 .


설명과 매우 흥미로운 링크에 감사드립니다. 참고로 Cell은 매우 흥미로워 서 CPU 아키텍처 ^ _ ^에 대해 더 많이 연구하기를 기대합니다. ""x86은 위에서 설명한 "슈퍼 파이프 라인"을 사용합니다. Cell 제품군은 9 개의 미니 CPU가 포함 된 "시너지 효과"접근 방식을 사용합니다. 각 미니 CPU는 대부분 순서대로 파이프 라인을 따르는 것이 사실이며, 미니 CPU에는 단일 파이프 라인이 아닌 여러 개의 병렬 슈퍼 스칼라 파이프 라인이 있습니다. "" "
실력이없는

3

어떻게 생각하십니까? 인텔, AMD 및 IBM의 모든 엔지니어는 파이프 라인이 사이클 당 하나의 결과 만 제공 할 수 있다는 것을 읽었으며 "그러면 프로세서를 더 빠르게 만들 수 없습니다"라고 말했습니다. 또는 그들은 이것을 읽고 "주기마다 하나 이상의 결과를 전달할 수 없습니까? 우리는 그것에 대해 알게 될 것입니다!"라고 말했습니다.

예를 들어 Haswell 아키텍처에 대한 좋은 소개를 위해이 링크 http://www.realworldtech.com/haswell-cpu/를 방문 하거나 Intel 웹 사이트로 이동하면 약간의 문서를 찾을 수 있습니다.

Haswell 프로세서의 각 코어에는 수많은 실행 단위가있어 서로 독립적으로 작업을 수행 할 수 있으므로 여러 작업을 병렬로 수행 할 수 있습니다. 다음으로 Haswell 프로세서에는 최대 256 비트 크기의 벡터 연산을 처리하는 여러 실행 장치가 있습니다. 벡터 연산은 예를 들어 하나의 벡터 연산에서 4 개의 배정도 부동 소수점 연산 또는 8 개의 단 정밀도 부동 소수점 연산을 수행 할 수 있습니다. 마지막으로 Haswell 프로세서는 "융합 곱셈-추가"를 지원합니다. 즉, 곱하기 b 더하기 c는 한 번의 연산 일뿐입니다.

이론적 최대 값은 Haswell에 곱하기 곱하기 융합 할 수있는 두 개의 단위가 있고주기 당 두 번의 곱하기 곱하기 곱하기 연산입니다. 각 연산에는 8 개의 단 정밀도 곱셈과 더하기 또는 32 개의 단 정밀도 부동 소수점 연산이 있습니다.

3630 프로세서는 인텔의 최신 가격 목록에 없지만 4 개의 코어가있는 3740QM과 같은 모델이 있습니다. 따라서 32 대신 클럭주기 당 128 개의 부동 소수점 연산을 얻을 수 있습니다. 이론상 최대 값입니다. 실제 생활에서 절반을 달성하는 것은 어려운 일이지만 적절한 작업에는 불가능하지 않습니다. 최대 15 개의 코어를 사용할 수있는 다른 프로세서가 있습니다 (가장 광신적 인 게임 광신자조차도 지불하지 않는 가격).

따라서 여러 곱셈기의 조합이 있습니다.

  1. 프로세서 당 여러 코어.
  2. (이전에 언급되지 않은 하이퍼 스레딩을 사용하면 이론적 한계에 더 근접 할 수 있습니다)
  3. 융합 곱셈 연산은 두 개의 산술 연산을 하나만 계산합니다.
  4. 8 개의 연산을 수행하는 256 비트 벡터는 하나만 계산합니다.
  5. 융합 곱셈 추가를 처리 할 수있는 2 개의 벡터 실행 유닛.

사이클 당 8.6 작업은 너무 어렵지 않습니다. 코어 당 사이클 당 8.6 작업조차 그렇게 어렵지 않습니다.


x86을 실행하는 일부 코어와 수퍼 스칼라 동작에 최적화 된 명령 세트를 실행하는 일부 코어를 사용하여 CPU를 설계하는 것이 실용적이든 유리한지 궁금합니다. 나는 Intel과 AMD가 x86 명령어 세트의 한계를 해결하기 위해 놀라운 일을한다는 것을 알고 있지만, 현재 명령어 세트로 표현할 수없는 것들을 아는 것이 도움이 될 것이라고 생각합니다. 예를 들어, ADD오버플로가 영향을받지 않아야하는지 또는 오버플로가 발생할 때 설정되어야하는지 (그리고 그렇지 않은 경우 왼쪽으로 설정) 여부에 따라 고유 버전의 명령어가 사용됩니다.
supercat

1
나는 요즘 시대에 많은 언어가 오버플로를 확인하지 않는 것이 슬프다는 것을 알게되었습니다. Java는 의미 요구 사항에 거의 붙어 있지만 C #과 같은 언어에서 트래핑 및 비 트래핑 산술 연산자를 모두 포함하는 언어에서 오버플로를 트랩하지 않는 유일한 이유는 랩핑 동작이 필요하기 때문입니다. 현재 오버 플로우 검사는 상당한 속도
저하를 초래할

... 특정 임계점에 도달하면 오버 플로우 트래핑 오버 헤드를 거의 0으로 줄일 수 있어야합니다. 코드가 계산을 수행 한 다음 첫 번째 계산이 오버플로되면 포기할 위치에 값을 저장하면 프로세서가 첫 번째 계산의 성공 여부를 알 때까지 저장을 지연 할 필요는 없지만 프로세서는 현재 방법이 없습니다 그것을 아는 것. 만약 코드가 오버플로가 발생했는지 여부에 관계없이 안전하게 수행 할 수있는 모든 작업을 수행 할 수 있다면 부적절한 오버플로가 발생했는지 확인하십시오.
supercat

... 실행 종속성을 줄이는 데 도움이되는 것처럼 보입니다.
supercat

2

Drystone 벤치 마크는 1984 년이며, 해당 공칭 1 MIPS VAX 시스템은 현대적인 측면에서 그다지 효율적이지 않습니다. Cortex M3조차도 1,25 DMPIS / MHz를 제공합니다.

인텔 코어 아키텍처 프로세서는 실제로 여러 컴퓨팅 장치가 있기 때문에 단일 코어에서 여러 명령을 병렬로 실행할 수 있습니다.


1

Ars Technica의 Jon "Hannibal"Stokes에서 마이크로 프로세서 아키텍처의 주제에 관한 우수하고 광범위한 기사를 통해 많은 것을 배웠습니다. 이 기사는 약간 날짜가 있지만 (2004 년경), 여전히 관련이 있습니다.

기사의 다음 부분에 대한 링크 중 일부가 끊어졌지만 첫 번째 부분의 URL과 다음 페이지의 끊어진 URL을 신중하게 비교하여 직접 수정할 수 있습니다 (예 : m-URL에 somwehere 추가 ).

(예, 이것은 영광스러운 링크 전용 답변입니다. 죄송합니다. 기사는 언급 할 수 없습니다.)

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.