2022-03-24 00:08:42

by Paul Menzel

Subject: Don't do arithmetic on anything smaller than 'int' (was: [PATCH v2] ice: use min_t() to make code cleaner in ice_gnss)

Dear Linux folks,


Am 22.03.22 um 19:27 schrieb Jakub Kicinski:
> On Tue, 22 Mar 2022 18:12:08 +0000 David Laight wrote:
>>>> Oh FFS why is that u16?
>>>> Don't do arithmetic on anything smaller than 'int'
>>>
>>> Any reasoning? I don't say it's good or bad, just want to hear your
>>> arguments (disasms, perf and object code measurements) etc.
>>
>> Look at the object code on anything except x86.
>> The compiler has to add instruction to mask the value
>> (which is in a full sized register) down to 16 bits
>> after every arithmetic operation.
>
> Isn't it also slower on some modern x86 CPUs?
> I could have sworn someone mentioned that in the past.

I know of Scott’s article *Small Integers: Big Penalty* from 2012 [1].


Kind regards,

Paul


[1]: https://notabs.org/coding/smallIntsBigPenalty.htm
> _______________________________________________
> Intel-wired-lan mailing list
> [email protected]
> https://lists.osuosl.org/mailman/listinfo/intel-wired-lan

2022-03-24 20:53:19

by Alexander Lobakin

Subject: [Intel-wired-lan] Don't do arithmetic on anything smaller than 'int' (was: [PATCH v2] ice: use min_t() to make code cleaner in ice_gnss)

From: Paul Menzel <[email protected]>
Date: Tue, 22 Mar 2022 22:02:06 +0100

> Dear Linux folks,
>
>
> Am 22.03.22 um 19:27 schrieb Jakub Kicinski:
> > On Tue, 22 Mar 2022 18:12:08 +0000 David Laight wrote:
> >>>> Oh FFS why is that u16?
> >>>> Don't do arithmetic on anything smaller than 'int'
> >>>
> >>> Any reasoning? I don't say it's good or bad, just want to hear your
> >>> arguments (disasms, perf and object code measurements) etc.
> >>
> >> Look at the object code on anything except x86.
> >> The compiler has to add instruction to mask the value
> >> (which is in a full sized register) down to 16 bits
> >> after every arithmetic operation.
> >
> > Isn't it also slower on some modern x86 CPUs?
> > I could have sworn someone mentioned that in the past.
>
> I know of Scott's article *Small Integers: Big Penalty* from 2012 [1].

Thank you all guys, makes sense!

Apart from this article, I tested some stuff on MIPS32 yesterday.
Previously I was sure that it's okay to put u16 on stack to conserve
it and there will be no code difference. I remember even having some
bloat-o-meter data. Well, human memory tends to lie sometimes.
I have a bunch of networking stats on stack which I collect during
a NAPI cycle (receiving 64 packets), it's about 20 counters. I made
them as u16 initially as it is (sizeof(u32) - sizeof(u16)) * 20 = 40
bytes. So I converted them yesterday to u32 and instead of having
+40 bytes of .text, I got -36 in one function and even -88 in
another one!
So it really makes no sense to declare anything on stack smaller
than u32 or int unless it is something to be passed to some HW or
standardized structures, e.g. __be16 etc.

Another interesting observation, on x86_64, is that u32 = u64
assignments take more instructions as well. I converted some
structure field recently from u64 to u32, but forgot that I'm
assigning it in one function from an onstack variable, which was
still unconverted from u64 to u32. When I did the latter, the .text
size became smaller.

>
>
> Kind regards,
>
> Paul
>
>
> [1]: https://notabs.org/coding/smallIntsBigPenalty.htm

Thanks,
Al