uint_fast32_t는 무엇이며 일반 int 및 uint32_t 대신 사용해야하는 이유는 무엇입니까?

109

따라서 typedef: ed 원시 데이터 유형 의 이유는 저수준 표현을 추상화하고 이해하기 쉽게 만드는 것 uint64_t입니다 ( long long유형 대신 8 바이트).

그러나가 uint_fast32_t동일한 갖는 typedef등을 uint32_t. "빠른"버전을 사용하면 프로그램이 더 빨라 집니까?

c++ c types

— 아무 무
소스

long long은 8 바이트가 아닐 수 있으며, 1 바이트 (CHAR_BIT가 64 이상인 경우) 또는 3738383 바이트의 long long을 가질 수 있습니다. 또한 uint64_t는 1,2,4 또는 8 바이트가 될 수 있으며 CHAR_BIT는 64, 3, 16 또는 8이어야합니다.

— 12431234123412341234123

134

int일부 플랫폼에서는 16 비트만큼 작을 수 있습니다. 귀하의 응용 프로그램에 충분하지 않을 수 있습니다.
uint32_t존재를 보장하지 않습니다. typedef정확히 32 비트의 부호없는 정수 유형이있는 경우 구현에서 제공해야하는 것은 선택 사항 입니다. 예를 들어 일부는 9 비트 바이트를 가지고 있으므로 uint32_t.
uint_fast32_t의도를 명확하게 설명합니다. 성능 관점에서 가장 좋은 최소 32 비트 유형입니다 . uint_fast32_t실제로 64 비트 길이 일 수 있습니다. 구현에 달려 있습니다.

... uint_fast32_t와 동일한 typedef가 있습니다 uint32_t...

당신이보고있는 것은 표준이 아닙니다. 특정 구현 (BlackBerry)입니다. 그래서 당신은 거기에서 uint_fast32_t항상 같은 것을 추론 할 수 없습니다 uint32_t.

또한보십시오:

— 야 코브 갈카
소스

35

좋은 대답입니다. 완성도를 위해 다른 점도 지적 할 수 있는데 uint_least32_t, uint_fast32_t속도보다는 작은 상점을 선호한다는 점 을 제외 하면 동일 합니다.

— Damon

2

너비가 32 비트 이상인 가장 빠른 정수가 32 비트보다 큰 이유는 무엇입니까? 저는 항상 비트가 적 으면 CPU가 작업해야하는 비트가 적어 지므로 더 빠를 것이라고 생각했습니다. 내가 여기서 무엇을 놓치고 있습니까?

— Shane Hsu 2013 년

12

@ShaneHsu : 64 비트 CPU가 64 비트 여름을 가지게되며 이는 한주기에서 64 비트 숫자를 합산합니다. 32 비트 숫자로 작업하기 만하면되지만 한주기보다 빠르지는 않습니다. 이제 x86 / amd64에서는 그렇지 않지만 32 비트 정수는 주소 지정이 불가능할 수도 있습니다. 이러한 경우 작업을 수행하려면 64 비트 정렬 단위에서 32 비트를 추출하기위한 추가 작업이 필요합니다. 연결된 질문을 참조하십시오. C ++ 표준은 37 비트 단어가있는 시스템에서 작동 할 수 있도록 작성되었으므로 32 비트 유형이 전혀 없습니다.

— Yakov Galka 2013 년

42

차이점은 정확성과 가용성에 있습니다.

여기에 있는 문서 는 다음과 같이 말합니다.

너비가 각각 정확히 8, 16, 32 및 64 비트 인 부호없는 정수 유형 ( 구현이 유형을 직접 지원하는 경우에만 제공됨 ) :
uint8_t
uint16_t
uint32_t
uint64_t

과

너비가 각각 최소 8, 16, 32 및 64 비트 인 가장 빠른 부호없는 부호없는 정수 유형
uint_fast8_t
uint_fast16_t
uint_fast32_t
uint_fast64_t    

따라서 정확히 비트 uint32_t가있는 유형 이라는 차이점이 매우 분명 하며 구현시 정확히 32 비트 유형이있는 경우에만 이를 제공해야하며 해당 유형을 . 즉, 사용 가능 하거나 사용 가능 하지 않을 수 있습니다 . 32uint32_tuint32_t

한편, uint_fast32_t보유 일종 이상의 구현이 형식 정의를 수있는 경우에도 수단, 32 비트, uint32_t같은 uint_fast32_t 경우 는 제공한다 uint32_t. 가 제공하지 않는 경우 uint32_t, 다음 uint_fast32_t적어도이 모든 유형의 타입 정의 될 수있다 32비트.

— 나와 즈
소스

3

그러나 예를 들어 uint_fast32_t가 uint32_t보다 빠른 이유는 무엇입니까? 왜 더 빠릅니까?

— 소멸자

2

@PravasiMeet : 모든 정수가 동일한 방식으로 액세스되는 것은 아닙니다. 일부는 다른 것보다 액세스하기 쉽습니다. 더 쉬움은 더 적은 계산, 더 직접적이며 더 빠른 액세스를 의미합니다. 이제 uint32_t모든 시스템 (존재하는 경우)에서 정확히 32 비트이므로 64 비트와 비교하면 빠르지 않을 수 있습니다. uint_fast32_t반면 에 최소 32 비트는 64 비트 일 수도 있습니다.

— Nawaz

10

@Destructor : 일부 프로세서에서 변수가 더 긴 레지스터에 저장되면 컴파일러는 추가 비트를 잘라 내기 위해 추가 코드를 추가해야 할 수 있습니다. 예를 들어 uint16_t x;ARM7-TDMI의 32 비트 레지스터에 저장되는 경우 코드 x++;를 x=((x+1)<<16)>>16);. 해당 플랫폼의 컴파일러에서는이 를 피하기 위해 uint_fast16_t와 동의어로 정의 될 가능성이 큽니다 uint32_t.

— supercat

왜 [u]int_(fast|least)N_t선택 사항이 아닌가? 표준에서 64 비트 이상의 기본 유형을 지원하기 위해 모든 아키텍처가 반드시 필요한 것은 아닙니다. 그러나에 대한 문구는 stdint.h반드시해야 함 을 의미합니다. 64 비트 컴퓨팅이 주류가되기 몇 년 전인 1999 년 이후 (많은 경우 여전히 현재의) 임베디드 아키텍처에 뒤쳐진 지연은 말할 것도없이 우리가 시행해 온 것이 이상해 보입니다. 이것은 나에게 큰 감독처럼 보입니다.

— underscore_d

1

@underscore_d : 예를 들어 표준이 16 바이트의 데이터 RAM과 256 개의 명령어를위한 공간이있는 PIC12 구현에 적용 할 수없는 특별한 이유가 없습니다. 그러한 구현은 많은 프로그램을 거부해야하지만, 그것이 만족할 수있는 프로그램에 대해 정의 된 방식으로 작동하는 것을 막아서는 안됩니다.

— supercat

4

당신은 할 때 #include inttypes.h프로그램에서, 당신은 정수를 표현하기위한 다른 방법의 무리에 액세스 할 수 있습니다.

uint_fast * _t 유형은 주어진 비트 수를 나타내는 가장 빠른 유형을 정의합니다.

다음과 같이 생각해보십시오. 유형의 변수를 정의 short하고 프로그램에서 여러 번 사용하면 완전히 유효합니다. 그러나 작업중인 시스템은 유형 값으로 더 빠르게 작동 할 수 있습니다 int. 변수를 type으로 정의함으로써 uint_fast*t컴퓨터는 작업 할 수있는 가장 효율적인 표현을 선택합니다.

이러한 표현 사이에 차이가 없으면 시스템은 원하는 것을 선택하고 전체적으로 일관되게 사용합니다.

— 할리 슈가 맨
소스

9

왜 stdint.h가 아닌 inttypes.h입니까? inttypes.h에는 약간의 유용한 보풀과 stdint.h가 포함되어있는 것 같습니다.

— Lundin

@underscore_d 차이점을 알고 있습니다. 그러나 응용 분야에 관계없이 전문 프로그램에서 stdio.h를 사용하는 사람은 누구입니까?

— Lundin

@Lundin 나는 그들이 누구인지 또는 그들이 존재하는지 전혀 모른다! 그냥 "약간 유용한 보풀"이 무엇인지 설명하는 링크를 제공하는 것이 유용 할 것이라고 생각했습니다. ;-) 아마도 사람들이 당신이 옳고 필요 하지 않다는 것을 깨닫는 데 도움이 될 것입니다.

— underscore_d

-1

빠른 버전은 32 비트보다 클 수 있습니다. fast int는 레지스터에 잘 맞고 정렬됩니다. 그러나 더 많은 메모리를 사용합니다. 이러한 배열이 많은 경우 더 많은 메모리 캐시 적중 및 대역폭으로 인해 프로그램 속도가 느려집니다.

일반적으로로드 명령 중에 32 비트에서 64 비트로 확장되는 부호가 발생할 수 있고 더 빠른 '네이티브'정수 형식이 있다는 생각이 구식이기 때문에 최신 CPUS가 fast_int32의 이점을 누릴 수 있다고 생각하지 않습니다.

— 길 콜 게이트
소스