On Wednesday, 1 January 2014 at 04:17:30 UTC, Jake Thomas wrote:
First, let me say that I am <i>extremely</i> enthused about D.
I did research on it last year for a project and absolutely
fell in love with it. But praise should go in another thread...
My question comes down to:
"Does dmd pack non-array primative variables in memory such
that they are touching, or are they zero-padded out to the
computer's native word size?"
I have a fun "little" project I work on when I have time (for
which D is redicuosly perfect, BTW), and right now I am
"merely" listing the prototypes of functions that will comprise
its API.
On my first go-through of the function protypes, I thoughtfully
figured out the smallest primatives I could safely use for
inputs and outputs. Obviously, when it comes to programming,
I'm a little OCD - who cares about memory to that degree
anymore when we have gigabytes of RAM? This might not even come
into play on the Raspberry Pi.
I also figured that choosing a safe minimum would make the code
more self-commented by queing the reader into what the expected
value range for the variable is.
Then I took Architecture & Assembly class. There I learned that
the load instruction grabs an entire native word size, every
time, regardless of how many bits your variable takes up.
When we programmed in assembly in that class, for both
performance and coding ease, we only worked with variables that
were the native code size.
I found out that it's actually extra work for the processor to
use values smaller than the native word size: it has to AND off
the unwanted bits and possibly shift them over.
So, if dmd packs variables together, I would want to always use
the native word size to avoid that extra work, and I would
never want to use shorts, ints, or longs. Instead, I'd want to
do this:
<code>
version (X86)
{
alias int native; //ints are 32-bit, the native size in this
case.
alias uint unative;
}
version (X86_64)
{
alias long native; //longs are 64-bit, the native size in
this case.
alias ulong unative;
}
</code>
And then only use natives, unatives, and booleans (can't avoid
them) for my primatives.
I really hope this isn't the case because it would make D's
entire primative system pointless. In acedamia, C is often
scolded for its ints always being the native word size, while
Java is praised for being consistent from platform to platform.
But if dmd packs its variables, D is the one that should be
scolded and C is the one that should be praised for the same
reason of the opposite.
If, however, dmd always zero-pads its variables so that each
load instruction only grabs the desired value with no need of
extra work, I would never have to worry about whether my
variable is the native word size.
However, this knowledge would still affect my programming:
If I know my code will only ever be compiled for 32-bit
machines and up, I should never use shorts. Doing so would
always waste at least 16-bits per short. Even if I think I will
never overflow a short, why not just take the whole 32 bits;
they're allocated for the variable anyways; not using those
bits would be wasteful.
Also, if I know I don't need anymore than 32 bits for a
variable, I should use an int, never a long. That way, the
processor does not have to do extra work on a 32-bit machine or
a 64-bit machine or any higher bitage. If I always default to
longs like a "good acedemically trained computer scientist
fighting crusades against hard caps", 32-bit machines (and
64-bit machines still running 32-bit OSes!!!) would have to do
extra work to work on 64-bit values split across two native
words.
And lastly, if I absolutely must have more than 32-bits for a
single value, I have no choice but to use a long.
So, I need to have this question answered to even get past the
function prototype stage - each answer would result in
different code.
Thank you very much,
I love D,
Jake
We have size_t defined as uint on 32bit and ulong on 64bit.
ptrdiff_t for int/long.
I don't know how dmd handles it, although you do have the ability
to align variables.
You may want to consider gdc or ldc more than dmd as they have
better optimization.