[PATCH 0/8] Add sinf/cosf/sincosf CORE-MATH implementations

[Wilco Dijkstra]

Hi Adhemerval,

> Do you have a link how to run box2d?

No - this was 8 years ago... I'm not sure I have the full traces either, but I can
repost my old patches.

>> So improving the benchtests with traces would be a good idea, however it seems
>> the CORE-MATH sinf/cosf implementation is significantly slower on modern cores
>> even with random inputs.
>
> CCing Paul.  I used perf.sh from CORE-MATH and I am seeing the opposite, where
> CORE-MATH shows 'less' branch mispredictions than current glibc one.  But it
> also does not apply to the benchtests that I have added (where the performance
> is neutral).

It depends on the chosen range and the algorithm. The CORE-MATH variant does
a single step range reduction to 3*PI and always calculates sin(x) and cos(x) before
merging them. This is perfect if you test a randomized range between +-2PI as in
workload-random. The AOR version is hit badly by this since it needs extra
branches to decide whether to use the sin or cos poly. On Neoverse N1 it ends
up ~10% slower (box2d-small is still 50% faster using AOR). Neoverse V2
does far better due to a newer branch predictor.

Note that random-large and random-huge are pretty much identical on the
CORE-MATH version. However random-huge hits the full-range reducer on AOR -
not on CORE-MATH since it has an intermediate range reducer between 9.4
and 1p+26.

To do better you have to generate inputs based on frequency of use (not a basic
flat distribution) and also model the correlation between successive inputs.

> I will try to come up with a better trace from speccpu2017.

That would be good, though SPEC2017 is very old now. From what I remember,
it doesn't use sin(f)/cos(f) much.

Cheers,
Wilco