[PATCH] benchtests: Add sinf traces

[Adhemerval Zanella Netto]

On 02/04/26 14:57, Wilco Dijkstra wrote:
> Hi Paul,
> 
>>> I looked at the "small" trace. On 1000 inputs, there are lots of duplicates:
>>> 232 which are 0, 54 which are 0x1.848f56p-32, 42 which are 0x1.84729p-32,
>>> and more than 1/3 which are in [-1e-9,1e9], for which we could simply
>>> return x. In my opinion, this is not a good trace, since it would be quite
>>> easy to write some code that is very efficient on average for this trace.
>>>
>>> I will have a look at the other traces next week, unless someone else beats me.
> 
> The goal is to be good at real world uses, not on something random. And it
> doesn't really matter how many identical or similar values there are, it's
> about the distribution of the inputs across the quadrants and special cases.
> 
> Note there is little difference between the box2d traces for sinf. And while the
> speedup for box2d is 10% higher than the random input, they are not far off,
> so the random case shows the same issue.
> 
>              sinf       cosf
>      random  45.4%      45.2%
>       large  68.0%      53.4%
>        huge  19.4%      9.8%
> box2d-small  58.2%      100.2%
>  box2d-hard  56.7%       72.7%
> box2d-mixed  52.5%      54.4%
> 
>> It is on my backlog, my plan is to use the trace of 3 speccpu2007 benchmarks
>> (507.cactuBSSN_r, 526.blender_r, and 544.nab_r) to try create a better one.
>> They benchmarks calls the double version, but since the range is within
>> -2pi..2pi I think we can extrapolate to float.
> 
> The actual binary values matter very little unless they hit cornercases that are
> significantly slower. The range is never an issue, nobody ever does sin (DBL_MAX)!

Right, but I now really following your point here. Are you saying a possible binary64
traced rounded to binary32 from specpu2017 would *not* be a good benchmark?