On 12/11/12 11:29 AM, eles wrote:
There's a lot to be discussed on the issue. A few quick thoughts:
* 32-bit integers are a sweet spot for CPU architectures. There's
rarely a provision for 16- or 8-bit operations; the action is at 32-
or 64-bit.
Speed can be still optimized by the compiler, behind the scenes. The
approach does not asks the compiler to promote everything to
widest-integral, but to do the job "as if". Currently, the choice of
int-C as the fastest-integral instead of widest-integral move the burden
from the compiler to the user.
Agreed. But then that's one of them "sufficiently smart compiler"
arguments. http://c2.com/cgi/wiki?SufficientlySmartCompiler
* Then, although most 64-bit operations are as fast as 32-bit ones,
transporting operands takes twice as much internal bus real estate and
sometimes twice as much core real estate (i.e. there are units that do
either two 32-bit ops or one 64-bit op).
* The whole reserving a bit and halving the range means extra costs of
operating with a basic type.
Yes, there is a cost. But, as always, there is a balance between
advantages and drawbacks. What is favourable? Simplicity of promotion or
a supplimentary bit?
A direct and natural mapping between language constructs and machine
execution is very highly appreciated in the market D is in. I don't see
that changing in the foreseeable future.
Besides, at the end of the day, a half-approach would be to have a
widest-signed-integral and a widest-unsigned-integral type and only play
with those two.
D has terrific abstraction capabilities. Lave primitive types alone and
define a UDT that implements your desired behavior. You can always
implement safe on top of fast but not the other way around.
Andrei
