> On Sep 12, 2024, at 05:09, Charles Karney via PROJ <proj@lists.osgeo.org>
> wrote:
>
> I recommend against unrolling the loops. This makes the code longer and
> harder to read. You also lose the flexibility of adjusting the number
> of terms in the expansion at runtime.
>
> …But
> remember that compilers can do the loop unrolling for you. Also,
> doesn't the smaller code size with the loops result in fewer cache
> misses?
I think Charles is spot-on here. Any modern compiler will make these
optimizations, tuned to the target architecture. Different architectures will
prefer different amount of unrolling, so it’s best not to second-guess by
hard-coding. Loop overhead of a simple counter is zero, normally, because of
unrolling in the short cases and because the branch prediction will favor
continuation in the longer cases. Meanwhile the loop counting happens in
parallel in one of the ALUs while the FPUs do their thing.
— daan Strebe
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
