sizeof Mystery

[Baker]

[Baker]

[taniwha]

[Spike]

endian is another reason to load byte-by-byte.
also, bitfields are far far worse.

consider switching the shorts to something like unsigned char colormap_index_lo,colormap_index_hi; and you'll get the verbosity from decent names, as well as a fix for endian issues. If everything in the struct is a char then it'll not be padded to anything bigger than a byte.

[WickedShell]

Generally struct's should be organized from largest to smallest size of member elements to minimize the amount of trailing/wrapping.

Quake2World gets a ~5 fps boost for 64 bit clients (from 85 to 90 on my machine) by rearranging the order of elements in r_bsp_surface_t to save about 8 bytes total (I forget the before and after sizes, that infos on a different machine), But 32 bit clients see no difference. The FPS gain comes almost completely from reducing cache miss as far as I can tell. (Saved about 500KB of memory total on the worst case map I had on hand.) If someone has a better explanation for why saving 8 bytes created such a difference I'd love to hear it

Caveat: Be careful about rearranging all of your structs to minimize memory used. You can do dumb stuff and mess up the copying of common members between structs (node and leaf in the Q2 setting for example) Ofc if that screws up your code that badly it might be an indication that you have some really messy code that would benefit from some more love

@Spike: Any dislike for going all the way to uint32_t rather then just unsigned int for example? I've been going and using all the stdint.h types since it was pointed out to me that there is only a minimum size associated with unsigned int's and that implementation/platform/compiler specific they could easily be 64 or 128 bit's long on me. (Which would be very surprising in file formats ) Alternatively anyone played with the fast types and seen any noticeable differences? IE uint_fast32_t

[taniwha]

WickedShell: More than cache, overall memory bandwidth might be the explanation. IIRC, memory controllers always read whole cache lines, so wasted space in a struct will always be read from memory. No wasted space = no wasted reads = faster reading overall.

(u)int32_t etc: I've done a lot of such conversion in QF. Particularly, any new file-format stuff uses it (eg, I modified the iqm structs to use uint32_t etc when I implemented iqm in qf). I haven't played with the fast versions, and don't see much point: int is supposed to be the fastest size for integers, so if speed is needed, use (unsigned) int.

[Spike]

the fast stdint types are for machines which do not have 8-bit bytes etc. you won't see a difference on x86+amd64+arm.
there are also machines that only support 32bit bus access (alpha chips), in which case using a 32bit type and masking it to 16bits will often be faster.

stdint.h is a c99 feature, that does not exist on (freshly-installed) msvc, so you'd be making custom typedefs there anyway.
its a useful feature, but personally I'm generally not keen on adding dependancies purely for karma reasons.

tbh, the biggest win with int32_t is that its just a single letter to make it unsigned, instead of an entire extra word. otherwise its just 4 extra letters of verbosity.
I'll probably fix up fte's int specifiers when I try to port it to a machine where it makes a difference, otherwise I'm just gonna stay consistant with what its already using.