Prev: Converting from 0 and 1 to -1 and 1
Next: My Parallel Sort Library and Benchmarks ...
From: Jonathan de Boyne Pollard on 6 May 2010 09:19

>
> I find for most applications the same is true of 32 bit. Fortunately
> x86 maintains multiple widths of working registers from 8 bits up,
> which can be taken good advantage of in some cases. For my work,
> probably half of my variable can be held in 8 bits. Probably 40%
> require 16 bits and less than 10% require more. The down side is when
> everything, including Boolean
> values default to 32 or 64 bits because that is the "natural" size of
> the registers. That is insanity!
>
No, it isn't. It's often forgotten that beneath the high-level language
abstractions there is a real processor executing machine instructions,
and this is possibly a case in point. Treating 8-bit data as 32-bit is
not insanity once one looks at how the CPUs actually work. For example,
in the Intel Atom, there's a thing called load-to-store forwarding,
which forwards the data from a store operation to a subsequent load
operation, short-circuiting the cache, as long as they both have the
same address and data size. If a program stores a boolean as a 32-bit
word but then loads it as an 8-bit word, load-to-store forwarding won't
trigger, and the program executes more slowly. This is far from the
only consideration involving how the processor actually works when
deciding what the object representation of a high-level language's
boolean type should be. There are non-trivial issues of word tearing,
misaligned access, and false sharing, as well.

 | 
Pages: 1
Prev: Converting from 0 and 1 to -1 and 1
Next: My Parallel Sort Library and Benchmarks ...