byte and short data types use cases

[Cecil Ward]

On Friday, 9 June 2023 at 15:07:54 UTC, Murloc wrote:
> On Friday, 9 June 2023 at 12:56:20 UTC, Cecil Ward wrote:
>> On Friday, 9 June 2023 at 11:24:38 UTC, Murloc wrote:
>>
>> If you have four ubyte variables in a struct and then
>> an array of them, then you are getting optimal memory usage.
>
> Is this some kind of property? Where can I read more about this?
>
> So you can optimize memory usage by using arrays of things 
> smaller than `int` if these are enough for your purposes, but 
> what about using these instead of single variables, for example 
> as an iterator in a loop, if range of such a data type is 
> enough for me? Is there any advantages on doing that?

Read up on ‘structs’ and the ‘align’ attribute in the main d 
docs, on this website. Using smaller fields in a struct that is 
in memory saves RAM if there is an array of such structs. Even in 
the case where there is only one struct, let’s say that you are 
returning a struct by value from some function. If the struct is 
fairly small in total, and the compiler is good (ldc or gdc, not 
dmd - see godbolt.org) then the returned struct can fit into a 
register sometimes, rather than being placed in RAM, when it is 
returned to the function’s caller. Yesterday I returned a struct 
containing four uint32_t fields from a function and it came back 
to the caller in two 64-bit registers, not in RAM. Clearly using 
smaller fields if possible might make it possible for the whole 
struct to be under the size limit for being returned in registers.

As for your question about single variables. The answer is very 
definitely no. Rather, the opposite: always use primary 
CPU-‘natural’ types, widths that are most natural to the 
processor in question. 64-bit cpus will sometimes favour 32-bit 
types an example being x86-64/AMD64, where code handling 32-bit 
ints generates less code (saves bytes in the code segment) but 
the speed and number of instructions is the same on such a 64-bit 
processor where you’re dealing with 32- or 64- bit types. Always 
use size_t for index variables into arrays or the size of 
anything in bytes, never int or uint. On a 64-bit machine such as 
x86-64, size_t is 64-bit, not 32. By using int/uint when you 
should have used size_t you could in theory get a very rare bug 
when dealing with eg file sizes or vast amounts of (virtual) 
memory, say bigger than 2GB (int limit) or 4GB (uint limit) when 
the 32-bit types overflow. There is also a ptrdiff_t which is 
64-bit on a 64-bit cpu, probably not worth bothering with as its 
raison d’être was historical (early 80s 80286 segmented 
architecture, before the 32-bit 386 blew it away).