std :: tuple sizeof, 놓친 최적화입니까?

std :: tuple sizeof, 놓친 최적화입니까?

---

모든 주요 컴파일러를 확인 sizeof(std::tuple<int, char, int, char>)했으며 모두 16 세입니다. 아마도 그들은 요소를 튜플에 순서대로 넣었을 것이므로 정렬 때문에 약간의 공간이 낭비됩니다.

튜플이 내부적으로 int, int, char, char다음 과 같은 요소를 저장하면 크기 는 12가 될 수 있습니다.

구현이이를 수행 할 수 있습니까? 아니면 표준의 일부 규칙에 의해 금지되어 있습니까?

---

std :: tuple sizeof, 놓친 최적화입니까?

네.

구현이이 작업을 수행 할 수 있습니까 [?]

네.

표준의 일부 규칙에 의해 금지되어 있습니까?

아니!

를 읽어 [tuple]보면 템플릿 인수 순서로 멤버를 저장하는 구현에 대한 제약이 없습니다.

사실, 내가 찾을 수있는 모든 구절은 멤버 선언 순서에 대한 참조를 전혀 피하기 위해 길이가 긴 것 같습니다 : get<N>()작동 의미론의 설명에 사용됩니다. 다른 표현은 "구성원"이 아닌 "요소"라는 용어로 표현되는데, 이는 상당히 고의적 인 추상화처럼 보입니다.

사실, 일부 구현은 멤버를 역순으로 저장합니다 . 최소한 상속을 재귀 적으로 사용하여 템플릿 인수를 압축 해제하는 방식 때문일 수 있습니다 (위와 같이 허용되기 때문일 수 있음).

가상의 최적화에 대해 구체적으로 말하면 사용자가 지정한 순서의 [일부 사소한 기능]에 요소를 저장하지 않는 구현을 알지 못합니다. 나는 std::get적어도 당신이 그렇게함으로써 얻을 수있는 이득의 양에 비해 그러한 명령을 내고 기계를 제공하는 것이 "어렵다" 고 생각하고 있습니다. 패딩에 대해 정말로 염려한다면 클래스에서 하듯이 ( "패킹 된"속성의 세계를 탐구하지 않고) 요소 순서를 신중하게 선택하여 피할 수 있습니다 (특정 플랫폼에서). ( "packed"튜플은 흥미로운 제안이 될 수 있습니다…)

---

예, 가능하며 R. Martinho Fernandes에 의해 (대부분) 수행되었습니다 . 그는 Flaming Danger Zone 이라는 블로그를 가지고 있었는데 현재는 어떤 이유로 다운되었지만 소스는 여전히 github에서 사용할 수 있습니다 .

이 정확한 주제에 대한 Size Matters 시리즈 의 4 개 파트 인 1 , 2 , 3 , 4는 다음과 같습니다 .

github는 사용 된 C ++ 하이라이트 마크 업을 이해하지 못하고 코드 스 니펫을 읽을 수없는 oneliner로 렌더링하므로 원시 상태로 볼 수 있습니다.

그는 본질적으로 C ++ 11 템플릿 메타 프로그램을 통해 튜플 인덱스에 대한 순열을 계산합니다. C ++ 11 템플릿 메타 프로그램은 오름차순이 아닌 순서로 정렬하여 요소를 정렬하고 그에 따라 요소를 저장 한 다음 액세스 할 때마다 인덱스에 적용합니다.

---

그렇지 않은 또 다른 이유 : x86을 포함한 일부 아키텍처 에는 단일 명령어에서 주소 기반 + 크기 × 색인 을 처리 할 수있는 색인 모드가 있지만 크기 가 2의 제곱 일 때만 가능합니다 . 또는로드를 수행하는 것이 약간 더 빠를 수 있습니다. 또는 16 바이트 경계에 맞춰 저장합니다. 이렇게 std::tuple하면 4 개의 패딩 바이트를 추가하면 배열을 좀 더 빠르고 간결하게 처리하는 코드를 만들 수 있습니다.

참고 URL : https://stackoverflow.com/questions/57771869/stdtuple-sizeof-is-it-a-missed-optimization