OT (partially): about promotion of integers

[Andrei Alexandrescu]

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