4 ms·
With GCC, both those structs seem to have a size of 416 bytes. Can you elaborate on what you meant?
by eutectic 10y ago
With GCC, both those structs seem to have a size of 416 bytes. Can you elaborate on what you meant?
- shakna 10y ago32 or 64bit GCC? I was referring to Struct Padding[0]. Assuming a 32bit GCC, then the first would be padded with 24 bytes, the second with 16 bytes. This padding doesn't show up under size, but does affect speed in small ways, and available memory (yay for dealing with memory constrained systems!). [0] http://www.catb.org/esr/structure-packing/ http://www.catb.org/esr/structure-packing/
- eutectic 10y agoBut isn't each field a multiple of the word size on both 32 and 64-bit platforms?
- FreeFull 10y agoint will be smaller than double on x86_64 (edit: x86 too, and most other platforms), but since in both structs int comes after the double, that doesn't matter. 400 is a multiple of 8, so it doesn't matter if it's before or after the double either.
- userbinator 10y agoYou seem to be misunderstanding how padding is applied. As your link says regarding structure alignment: In general, a struct instance will have the alignment of its widest scalar member. ...which is d if we assume sizeof(double) == 8, so the total size will be rounded up to a multiple of 8. Both your structure examples will be exactly the same size: 0 msg 400 d 408 i 412 [+4 padding] 416 TOTAL 0 d 8 i 12 msg 412 [+4 padding] 416 TOTAL
- shakna 10y ago> On some processors, the addressing of a member is more efficient if its distance from the beginning of the structure is less than 128 bytes. > In the first example, to address the d and i fields using a pointer to the beginning of the structure, an offset of at least 400 bytes is required. > Instead, in the second example, containing the same fields in a different order, the offsets to address d and i are of few bytes, and this allows to use more compact instructions.