On Saturday, 4 January 2014 at 03:14:35 UTC, Jake Thomas wrote:
So, short-term, it seems like one would want to use my "native/unative" technique. But long-term, hopefully not only does this get fixed, but the default behavior for the compiler be to pad things out to the native word size without having to specify alignment.
According to this (http://msdn.microsoft.com/en-us/library/windows/hardware/ff561499(v=vs.85).aspx) 32-bit registers are automatically zero extended on x64 architecture while 16-bit and 8-bit registers are not.
So 32-bit integers are fast. And since they are smaller then 64-bits they should benefit from higher cache-locality. So you might actually slow things down by using your (u)native sizes.
Andrei has a nice talk about optimizations that talks about this a bit (http://shelby.tv/video/vimeo/55639112/facebook-nyc-tech-talk-andrei-alexandrescu-three-optimization-tips-for-c)
How do you folks decide if a number should be an int, long, or even short?
It depends what the number is for. In general i stick to (u)int or size_t but when types have some special significance for example the red color channel or a network port i use the corresponding types to signal bound ranges on the values.
That being said i try to minimize the size of my structs as much as possible. (Keep in mind that when doing this you order the fields by alignment size)
I tend to use ushorts as indices when i know that an array will never be larger then ushort.max. But this is only if i use 2 of em. There is no point in having 1 short if the struct alignment is 4 since that will only be wasted space anyways.
I guess the exact type of variables should remain up in the air until the whole thing is implemented and tested using different types?
Yes very much so.
