On Friday, 15 March 2024 at 00:00:01 UTC, Richard (Rikki) Andrew
Cattermole wrote:
On 15/03/2024 12:47 PM, Basile B. wrote:
On Thursday, 14 March 2024 at 23:39:33 UTC, Liam McGillivray
wrote:
On Thursday, 14 March 2024 at 01:58:46 UTC, Richard (Rikki)
Andrew Cattermole wrote:
[...]
I tried to rework the functions to use bitwise operations,
but it was difficult to figure out the correct logic. I
decided that it's not worth the hassle, so I just changed the
value storage from `bool[3]` to `ubyte`. Now it works much
more like your version.
https://github.com/LiamM32/Open_Emblem/blob/c2014ab3f77e89c0cedcd6dbf7f8362ebfac33a9/source/common.d
I did a little reading, so now I understand what it means
when you have `&= 7`. But I want to ask, is this faster than
`%= 8`? If not, I would like to change it to the latter for
readability.
`%=8` will be codegened using slower intructions w/o optimz
enabled but with `&=7` you directly get the right instruction,
which does not involves integer division. See
https://godbolt.org/z/74vbba5aG
Yes, it'll depend upon how smart the compiler is at optimizing
and it may not occur in non-optimizing builds.
Indeed GDC (so very likely GCC too, or whatever language uses it
as backend...) does it without optimz
(https://godbolt.org/z/Ke7c54Gqj).
That's not very surprising. If you look at LLVM bug tracker, for
the tag "missed optimisations", in the report body you'll see a
lot of "GDC does that but we dont", even if here it's a bit
different, as optimz are not enabled.
