This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2] Add sinf and cosf traces
> We should be modelling workloads.
> Please put these calls into a unique cosf-box2d-inputs and sinf-box2d-inputs.
I'm not sure what you mean here. These are simple sinf/cosf/sincosf traces.
While each trace is obviously different, the characteristics don't vary much.
We can label multiple traces within an input when deemed useful, so I don't
see a point in creating multiple trace files for each math function.
> In your other patch you used the generic name sincosf2 as "a second test",
> but in retrospect that should also be sincosf-box2d-inputs.
I only added sincosf2 because sincosf doesn't support traces due to it's
interface. It's just how the benchmark infrastructure works. If we can get rid
of the horrible Python hackery then it would be possible to clean this up easily.
> I want to avoid dumping the values in the main set of inputs because they are
> workload specific and I want to call that out.
There are not workload specific. The only reason I even use a workload name
is because you asked for that...
> If on the otherhand you think these are good for some kind of "average" cosf
> workload or sinf workload, then I think we should maintain that as a distinct
> workload with those criteria e.g. create cosf-master-inputs, and we discuss
> what it means to be a "master" set of values for a mean wokrload.
Yes there are simple traces that are suitable for all workloads. Ie. if you make
the sinf benchmark faster, it will improve all workloads that use sinf. And that
should be a key goal, we should not optimize math functions just for one
Would a cosf-master-inputs file mean we delete the cosf-inputs file? I can't
see why we should have both - the standard inputs are useless as they don't
benchmark a realistic scenario (and yes this is true for most of the string
benchmarks as well).