x << 1 또는 x << 10 중 어느 것이 더 빠릅니까?

나는 아무것도 최적화하고 싶지 않습니다. 맹세합니다. 호기심에서이 질문을하고 싶습니다. 나는 대부분의 하드웨어에서 비트 변화 (예를 들면의 어셈블리 명령어가 있다는 것을 알고 shl, shr하나의 명령이다). 그러나 얼마나 많은 비트를 이동하는지가 중요합니까 (나노초 단위 또는 CPU 전술 단위). 즉, 다음 중 하나가 CPU에서 더 빠릅니까?

x << 1;

과

x << 10;

그리고이 질문에 대해 나를 미워하지 마십시오. :)

잠재적으로 CPU에 따라 다릅니다.

그러나 모든 최신 CPU (x86, ARM)는 "배럴 시프터"(일정한 시간에 임의의 시프트를 수행하도록 특별히 설계된 하드웨어 모듈)를 사용합니다.

그래서 결론은 ... 아뇨. 차이 없음.

일부 임베디드 프로세서에는 "하나로 이동"명령 만 있습니다. 같은 프로세서에서 컴파일러는 바꿀 것 x << 3으로 ((x << 1) << 1) << 1.

모토로라 MC68HCxx는 이러한 한계가있는 가장 인기있는 제품군 중 하나라고 생각합니다. 다행히도 이러한 아키텍처는 이제 매우 드물며 대부분은 가변 시프트 크기의 배럴 시프터를 포함합니다.

많은 최신 파생물이있는 Intel 8051은 또한 임의의 비트 수를 이동할 수 없습니다.

이것에 대한 많은 경우가 있습니다.

1. 많은 고속 MPU에는 배럴 시프터, 멀티플렉서와 ​​같은 전자 회로가있어 일정한 시간에 어떤 시프트도 수행합니다.

2. MPU에 1 비트 시프트 만있는 경우 x << 10일반적으로 10 시프트 또는 2 시프트로 바이트 복사로 수행되므로 일반적으로 더 느립니다.

3. 그러나 일반적인 경우가 알려져 x << 10도 될 것 빠른 이상을 x << 1. x가 16 비트 인 경우 하위 6 비트 만주의해야합니다 (다른 모든 비트는 시프트 됨). 따라서 MPU는 하위 바이트 만로드하면되므로 8 비트 메모리에 대한 단일 액세스 주기만 만들고 x << 102 개의 액세스주기가 필요합니다. 액세스주기가 시프트보다 느리면 (하위 바이트 지우기) x << 10더 빠릅니다. 이것은 느린 외부 데이터 RAM에 액세스하는 동안 빠른 온보드 프로그램 ROM이있는 마이크로 컨트롤러에 적용될 수 있습니다.

4. 경우 3 외에도 컴파일러는 x << 1016x16 곱셈을 16x8 1로 바꾸는 것과 같이 (하위 바이트는 항상 0이므로) 더 낮은 너비의 비트로 추가 작업을 최적화 할 수 있습니다.

일부 마이크로 컨트롤러에는 왼쪽 시프트 명령이 전혀 없으며 add x,x대신 사용 합니다.

ARM에서는 다른 명령어의 부작용으로이 작업을 수행 할 수 있습니다. 따라서 잠재적으로 둘 중 하나에 대해 대기 시간이 전혀 없습니다.

여기 내가 좋아하는 CPU 하는, x<<2만큼 배 걸립니다 x<<1:)

이는 CPU와 컴파일러에 따라 다릅니다. 기본 CPU에 배럴 시프터를 사용하여 임의의 비트 시프트가 있더라도 컴파일러가 해당 리소스를 활용하는 경우에만 발생합니다.

데이터의 비트 단위로 너비를 벗어난 모든 항목을 이동하는 것은 C 및 C ++에서 "정의되지 않은 동작"입니다. 서명 된 데이터의 오른쪽 시프트도 "구현 정의"입니다. 속도에 대해 너무 많은 관심을 갖기보다는 다른 구현에 대해 동일한 답을 얻고 있다는 점을 염두에 두십시오.

ANSI C 섹션 3.3.7에서 인용 :

3.3.7 비트 시프트 연산자

통사론

      shift-expression:
              additive-expression
              shift-expression <<  additive-expression
              shift-expression >>  additive-expression

제약

각 피연산자는 정수 유형을 가져야합니다.

의미론

적분 프로모션은 각 피연산자에서 수행됩니다. 결과 유형은 승격 된 왼쪽 피연산자의 유형입니다. 오른쪽 피연산자의 값이 음수이거나 승격 된 왼쪽 피연산자의 너비 (비트)보다 크거나 같으면 동작이 정의되지 않습니다.

E1 << E2의 결과는 E1 왼쪽으로 이동 한 E2 비트 위치입니다. 비워진 비트는 0으로 채워집니다. E1에 부호없는 유형이있는 경우 결과 값은 E1에 수량을 곱하고 2를 E2 거듭 제곱하고 E1에 부호없는 long 유형이있는 경우 모듈로 ULONG_MAX + 1을 줄이고 그렇지 않으면 UINT_MAX + 1입니다. (상수 ULONG_MAX 및 UINT_MAX는 헤더에 정의되어 있습니다.)

E1 >> E2의 결과는 E1 오른쪽으로 이동 한 E2 비트 위치입니다. E1에 부호없는 유형이 있거나 E1에 부호있는 유형과 음이 아닌 값이있는 경우 결과 값은 E1 몫의 정수 부분을 수량으로 나눈 값 2를 E2 제곱합니다. E1에 부호있는 유형과 음수 값이있는 경우 결과 값은 구현에서 정의됩니다.

그래서:

x = y << z;

"<<": y × 2 ^z ( 오버플로가 발생하면 정의되지 않음 );

x = y >> z;

">>": 서명에 대한 구현 정의 (대부분 산술 시프트의 결과 : y / 2 ^z ).

8 비트 프로세서에서는 x<<1실제로 16 비트 값 보다 훨씬 느릴 수 있습니다 x<<10.

예를 들어 합리적인 번역 x<<1은 다음과 같습니다.

byte1 = (byte1 << 1) | (byte2 >> 7)
byte2 = (byte2 << 1)

반면 x<<10더 간단합니다.

byte1 = (byte2 << 2)
byte2 = 0

x<<1보다 자주 그리고 더 멀리 이동하는 것을 주목하십시오 x<<10. 또한의 결과 x<<10는 byte1의 내용에 의존하지 않습니다. 이것은 추가적으로 작업 속도를 높일 수 있습니다.

일부 세대의 Intel CPU (P2 또는 P3? AMD가 아님)에서는 비트 시프트 작업이 엄청나게 느립니다. 1 비트 씩 비트 시프트는 덧셈 만 사용할 수 있기 때문에 항상 빠릅니다. 고려해야 할 또 다른 질문은 일정한 비트 수에 의한 비트 시프트가 가변 길이 시프트보다 빠른지 여부입니다. opcode가 같은 속도 인 경우에도 x86에서 비트 시프트의 상수가 아닌 오른쪽 피연산자는 CL 레지스터를 차지해야하므로 레지스터 할당에 추가 제약이 부과되고 프로그램 속도도 느려질 수 있습니다.

항상 그렇듯이 주변 코드 컨텍스트에 따라 다릅니다 . 예를 들어 x<<1배열 인덱스로 사용 하고 있습니까? 아니면 다른 것에 추가 하시겠습니까? 두 경우 모두 작은 시프트 카운트 (1 또는 2)는 컴파일러가 시프트 만하면되는 경우보다 더 많이 최적화 할 수 있습니다 . 전체 처리량 대 대기 시간 대 프런트 엔드 병목 현상의 절충은 말할 것도 없습니다. 작은 조각의 성능은 1 차원이 아닙니다.

하드웨어 시프트 명령어는 컴파일을위한 컴파일러의 유일한 옵션이 x<<1아니지만 다른 답변은 대부분이를 가정합니다.

x << 1x+x부호없는 정수와 2의 보수 부호있는 정수와 정확히 동일합니다 . 컴파일러는 컴파일하는 동안 대상 하드웨어를 항상 알고 있으므로 이와 같은 트릭을 활용할 수 있습니다.

에 인텔 하 스웰 , add시계 처리량 당 4를 가지고 있지만 shl즉각적인 카운트 만 2 클럭 처리량 당이있다. ( http://agner.org/optimize/ 참조 지침 표 및 기타 링크는 를 .x86태그 위키). SIMD 벡터 시프트는 클럭 당 1 (Skylake에서 2)이지만 SIMD 벡터 정수 추가는 클럭 당 2 (Skylake에서 3)입니다. 대기 시간은 동일하지만 1주기입니다.

또한 shlopcode에서 카운트가 암시되는 위치 에 대한 특별한 시프트 바이 1 인코딩이 있습니다. 8086에는 즉시 카운트 시프트가 없었으며 cl레지스터 별로 하나씩 만 있습니다. 메모리 피연산자를 시프트하지 않는 한 왼쪽 시프트 만 추가 할 수 있기 때문에 이는 대부분 오른쪽 시프트와 관련이 있습니다. 그러나 나중에 값이 필요하면 레지스터에 먼저로드하는 것이 좋습니다. 그러나 어쨌든 shl eax,1또는 add eax,eax보다 1 바이트 더 짧으며 shl eax,10코드 크기는 직접 (디코딩 / 프런트 엔드 병목 현상) 또는 간접적으로 (L1I 코드 캐시 누락) 성능에 영향을 미칠 수 있습니다.

보다 일반적으로, 작은 시프트 카운트는 x86의 주소 지정 모드에서 스케일링 된 인덱스로 최적화 될 수 있습니다. 요즘 일반적으로 사용되는 대부분의 다른 아키텍처는 RISC이며 확장 인덱스 주소 지정 모드가 없지만 x86은 언급 할 가치가있는 일반적인 아키텍처입니다. (예를 들어 4 바이트 요소의 배열을 인덱싱하는 경우)에 대한 배율 인수를 1 씩 늘릴 여지가 있습니다 int arr[]; arr[x<<1].

의 원래 값 x이 여전히 필요한 상황에서는 복사 + 이동이 필요합니다. 그러나 대부분의 x86 정수 명령어는 제자리에서 작동합니다. (대상은 add또는 같은 명령어의 소스 중 하나입니다 shl.) x86-64 System V 호출 규칙은 레지스터에 인수를 전달합니다. 첫 번째 인수는에 edi있고 반환 값은 eax에 있습니다. 따라서 반환하는 함수 x<<10는 컴파일러가 복사 + 시프트를 방출 하도록합니다 암호.

이 LEA명령어를 사용하면 시프트 및 추가를 수행 할 수 있습니다 (어드레싱 모드 머신 인코딩을 사용하기 때문에 시프트 카운트 0에서 3). 결과를 별도의 레지스터에 넣습니다.

gcc와 clang은 모두 Godbolt 컴파일러 탐색기에서 볼 수 있듯이 동일한 방식으로 이러한 함수를 최적화합니다 .

int shl1(int x) { return x<<1; }
    lea     eax, [rdi+rdi]   # 1 cycle latency, 1 uop
    ret

int shl2(int x) { return x<<2; }
    lea     eax, [4*rdi]    # longer encoding: needs a disp32 of 0 because there's no base register, only scaled-index.
    ret

int times5(int x) { return x * 5; }
    lea     eax, [rdi + 4*rdi]
    ret

int shl10(int x) { return x<<10; }
    mov     eax, edi         # 1 uop, 0 or 1 cycle latency
    shl     eax, 10          # 1 uop, 1 cycle latency
    ret

구성 요소가 2 개인 LEA는 최신 Intel 및 AMD CPU에서 1주기 지연 시간과 클럭 당 2 개의 처리량을 제공합니다. (Sandybridge 가족 및 Bulldozer / Ryzen). Intel에서는 클럭 처리량 당 1 개이며 lea eax, [rdi + rsi + 123]. (관련 : 왜이 C ++ 코드가 Collatz 추측을 테스트하기 위해 손으로 작성한 어셈블리보다 빠른가요? 자세히 설명합니다.)

어쨌든 10 씩 복사 + 시프트는 별도의 mov명령이 필요합니다 . 최근 많은 CPU에서 지연 시간이 0 일 수 있지만 여전히 프런트 엔드 대역폭과 코드 크기가 필요합니다. ( x86의 MOV가 정말 "무료"일 수 있습니까? 왜 이것을 전혀 재현 할 수 없습니까? )

또한 관련이 있습니다. x86에서 2 개의 연속적인 leal 명령어 만 사용하여 레지스터에 37을 곱하는 방법은 무엇입니까? .

컴파일러는 또한 주변 코드를 자유롭게 변환 할 수 있으므로 실제 이동이 발생하지 않거나 다른 작업과 결합됩니다 .

예를 들어 if(x<<1) { }를 사용하여 and상위 비트를 제외한 모든 비트를 확인할 수 있습니다 . x86에서는 . 대신 / test와 같은 명령어를 사용합니다 . 이 최적화는 모든 시프트 수에 대해 작동하며, 많은 수의 시프트가 느리거나 (예 : Pentium 4) 존재하지 않는 (일부 마이크로 컨트롤러) 머신에서도 작동합니다.test eax, 0x7fffffffjz .falseshl eax,1 / jz

많은 ISA에는 단순한 이동 이상의 비트 조작 명령이 있습니다. 예를 들어 PowerPC에는 많은 비트 필드 추출 / 삽입 명령이 있습니다. 또는 ARM에는 다른 명령어의 일부로 소스 피연산자의 시프트가 있습니다. (따라서 이동 / 회전 명령은 move이동 된 소스를 사용하는 의 특수한 형태 일뿐 입니다.)

기억 C 어셈블리 언어가 아닙니다 . 효율적으로 컴파일하기 위해 소스 코드를 조정할 때는 항상 최적화 된 컴파일러 출력을 확인하십시오.