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).
