정확성과 코딩의 용이성의 관점 에서, 위의 많은 사용자가 지적했듯이 더 정확하게 정의 된 크기와 산술 의미로 인해 특히 uint32_t많은 이점 uint_fast32_t이 있습니다.

아마도 놓친 것은 하나의 장점 은 더 빠를uint_fast32_t 수 있고 의미있는 방식으로 결코 구체화되지 않았다는 것입니다. 64 비트 시대를 장악 한 대부분의 64 비트 프로세서 (대부분 x86-64 및 Aarch64)는 32 비트 아키텍처에서 발전 했으며 64 비트 모드에서도 빠른 32 비트 기본 작업을 수행합니다. 따라서 해당 플랫폼 에서와 동일 합니다.uint_fast32_tuint32_t

POWER, MIPS64, SPARC와 같은 “또한 실행되는”플랫폼 중 일부가 64 비트 ALU 작업 만 제공하더라도 대부분 의 흥미로운 32 비트 작업은 64 비트 레지스터에서 잘 수행 할 수 있습니다. 하위 32 비트는 원하는 결과를 얻을 수 있습니다 (그리고 모든 주류 플랫폼은 적어도 32 비트를로드 / 저장할 수 있습니다). 왼쪽 시프트가 주요 문제이지만 컴파일러의 값 / 범위 추적 최적화를 통해 많은 경우에 최적화 될 수 있습니다.

나는 때때로 약간 느린 왼쪽 시프트 또는 32×32-> 64 곱셈이 그러한 값에 대한 메모리 사용의 두 배 를 능가 할 것이라고 의심합니다 .

마지막으로, 트레이드 오프는 대체로 “메모리 사용 및 벡터화 잠재력”(에 찬성 uint32_t) 대 명령 수 / 속도 (에 찬성 uint_fast32_t) 로 특징 지워졌지만 나에게 분명하지 않습니다. 예, 일부 플랫폼에서는 일부 32 비트 작업에 대한 추가 지침이 필요 하지만 다음과 같은 이유로 몇 가지 지침 도 저장 해야합니다.

• 더 작은 유형을 사용하면 컴파일러가 하나의 64 비트 연산을 사용하여 두 개의 32 비트 연산을 수행함으로써 인접한 연산을 영리하게 결합 할 수 있습니다. 이러한 유형의 “가난한 사람의 벡터화”의 예는 드물지 않습니다. 예를 들어 상수 struct two32{ uint32_t a, b; }를 raxlike 로 생성 하는 것은 단일 two32{1, 2} 로 최적화 할 수 있지만mov rax, 0x20001 64 비트 버전은 두 가지 명령이 필요합니다. 원칙적으로 이것은 인접한 산술 연산 (동일한 연산, 다른 피연산자)에도 가능해야하지만 실제로는 보지 못했습니다.
• “메모리 사용”이 낮 으면 메모리 또는 캐시 풋 프린트가 문제가되지 않더라도 이러한 유형의 구조 또는 배열이 복사되기 때문에 레지스터 복사 당 비용이 두 배가됩니다.

• 더 작은 데이터 유형은 종종 데이터 구조 데이터를 레지스터에 효율적으로 압축하는 SysV ABI와 같은 더 나은 최신 호출 규칙을 활용합니다. 예를 들어 registers에서 최대 16 바이트 구조를 반환 할 수 있습니다 rdx:rax. 4 개의 uint32_t값 (상수에서 초기화 됨)을 가진 구조를 반환하는 함수의 경우 다음과 같이 변환됩니다.

  ret_constant32():
      movabs  rax, 8589934593
      movabs  rdx, 17179869187
      ret
  

  64 비트 uint_fast32_t가 4 개인 동일한 구조 는 동일한 작업을 수행하기 위해 레지스터 이동과 메모리에 4 개의 저장소 가 필요합니다 (호출자는 반환 후 메모리에서 값을 다시 읽어야합니다).

  ret_constant64():
      mov     rax, rdi
      mov     QWORD PTR [rdi], 1
      mov     QWORD PTR [rdi+8], 2
      mov     QWORD PTR [rdi+16], 3
      mov     QWORD PTR [rdi+24], 4
      ret
  

  마찬가지로 구조 인수를 전달할 때 32 비트 값은 매개 변수에 사용할 수있는 레지스터에 약 2 배 조밀하게 압축되므로 레지스터 인수가 부족하여 스택 ¹ 로 넘쳐 야 할 가능성이 줄어 듭니다 .

• uint_fast32_t“속도가 중요한”장소에서 사용 하기로 선택하더라도 고정 크기 유형이 필요한 장소도 종종 있습니다. 예를 들어 외부 출력, 외부 입력, ABI의 일부로, 특정 레이아웃이 필요한 구조의 일부로 또는 uint32_t메모리 공간을 절약하기 위해 값의 대규모 집계에 현명하게 사용 하기 때문에 값을 전달할 때 . 사용자 uint_fast32_t와“uint32_t` 유형이 인터페이스해야하는 곳에서 (개발 복잡성 외에도) 불필요한 부호 확장 또는 기타 크기 불일치 관련 코드를 찾을 수 있습니다. 컴파일러는 많은 경우에 이것을 최적화하는 데 OK 작업을 수행하지만 다른 크기의 유형을 혼합 할 때 최적화 된 출력에서 ​​이것을 보는 것은 여전히 ​​드문 일이 아닙니다.

위의 일부 예제와 godbolt에서 더 많은 것을 재생할 수 있습니다 .

¹ 명확하게 말하면, 구조를 레지스터에 단단히 묶는 규칙이 작은 값에 대해 항상 확실한 승리는 아닙니다. 이는 더 작은 값을 사용하기 전에 “추출”해야 할 수도 있음을 의미합니다. 예를 들어 두 구조체 멤버의 합을 함께 반환하는 간단한 함수 mov rax, rdi; shr rax, 32; add edi, eax는 64 비트 버전의 경우 각 인수가 자체 레지스터를 가져오고 하나의 add또는 lea. 그래도 “통과하는 동안 구조를 단단히 묶는”디자인이 전체적으로 합리적이라는 점을 받아 들인다면 값이 작을수록이 기능을 더 많이 활용할 수 있습니다.