[OT] The Usual Arithmetic Confusions

[Walter Bright]

On 2/4/2022 2:15 PM, Elronnd wrote:
> On Friday, 4 February 2022 at 21:13:10 UTC, Walter Bright wrote:
>> It's slower, too.
> 
> Not anymore.  And div can be faster on smaller integers.

The code size penalty is still there.


>> You're paying a 3 size byte penalty for using short arithmetic rather than int 
>> arithmetic.
> 
> 1. You are very careful to demonstrate short arithmetic, not byte arithmetic, 
> which is the same size as int arithmetic on x86.

The penalty for byte arithmetic is the shortage of registers. Even so, if you're 
talking about a general solution, not treating bytes differently from shorts, 
then I only need mention the shorts.

Also, Implying I have nefarious motives here is not called for.


> 2. Cycle-counting (or byte-counting) is not a sensible approach to language 
> design.  It is relevant to language implementation, maybe; and whole-program 
> performance may be relevant to language design; but these sorts of changes are 
> marginal and should not get in the way of correct semantics.

That's fine unless you're using a systems programming language, where the 
customers expect performance.

Remember the the recent deal with the x87 where dmd would keep the extra 
precision around, to avoid the double rounding problem? I propagated this to 
dmc, and it cost me a design win. The customer benchmarked it on 'float' 
arithmetic, and pronounced dmc 10% slower. The double rounding issue did not 
interest him.


> 3. Your code example actually does exactly what you suggest--using short 
> arithmetic for storage.

The load instructions still use the extra operand size override bytes.


> It just happens that in this case using short 
> calculations rather than int calculations yields the same result and smaller code.

It's not "just happens". Every short load will incur an extra byte. I compiled 
it with gcc -O, too, just so nobody will accuse me of sabotaging the result with 
dmd.


> 4. (continued from 3) in a larger, more interesting expression, regardless of 
> language semantics, the compiler will generally be free to use ints for 
> intermediates.

If it does, then you'll have other truncation problems depending on how the 
optimization of the expression plays out. Unless you went the x87 route and 
slowed everything down by truncating every subexpression to short.

Seriously, I've been around the block with this for 40 years. There are no magic 
solutions. The obvious solutions all simply have other problems. The integral 
promotion rules really are the most practical solution. It's best to simply 
spend a few moments learning them, and you'll be fine.