Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: Performance of unaligned memory-accesses Date: Wed, 07 Aug 2019 17:52:04 -0700 Organization: None to speak of Lines: 46 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="c2e3c649afb59b0d1215e9c099fa96fa"; logging-data="22146"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uoqHKuSgguzSLSjVmGoHf" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:BOzC8y6FZqTf+hVjx63+GkOId54= sha1:G+ayWTGTG/dWWSZDpoyOE+V8viY= Xref: csiph.com comp.lang.c++:67415 Bart writes: [...] > You have to keep an eye on what's going on, otherwise you may end up > with a struct that needs 65 bytes. Will the compiler say anything about > that, or just accept it, and try and create arrays with a stride of 65 > bytes, or pad them to 128 bytes? > > I doubt it will re-design the struct to keep it to a power-of-two. [...] If the target imposes alignment constraints and you don't use any compiler extensions to force packing, the compiler will do what it needs to do to prevent unaligned access. There's unlikely to be any need to pad a 65-byte structure to 128 bits. It would probably just be padded to 68 or perhaps 72 bytes, depending on the alignment requirements of its members. For example: #include #include int main(void) { struct foo { uint32_t arr[16]; char c; }; struct bar { uint64_t arr[8]; char c; }; printf("struct foo is %zu bytes\n", sizeof (struct foo)); printf("struct bar is %zu bytes\n", sizeof (struct bar)); } On my system: struct foo is 68 bytes struct bar is 72 bytes The stride of an array of FOO is always equal to sizeof (FOO); there is no padding between array elements. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */