This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] New numbers in the benchtests.
On 12/15/2017 10:19 AM, Ben Woodard wrote:
> I think that this actually kind of gets at the nature of what these
> benchtests currently show as opposed to what they could ultimately be
> used for.
> Right now, they demonstrate specific numbers that trigger the
> implementation to go into different modes. With our current
> implementation, this is the fast path, the slow path and the very slow
> path. So these functions are there to show how well the current
> implementation is running when it enters those modes. You can easily
> see if a code change or a compiler change improves or impacts
> performance. This is good for optimizing the implementation for
> performance in the traditional way.
> However, there are also certain inputs to functions which are known to
> be problematic or more difficult to round correctly than others and
> you must compute them out to N-digits to get correct rounding when
> using a particular implementation. The quality of implementation is in
> essence how often we hit those hard cases and how quickly we can deal
> with them. These benchtests that I added are more along those lines.
> For example, they include exp for the last subnormal and the first
> normal floating point number. Together these represent a test case
> which is known by the customer to identify quality of implementation
> issues. They have indicated to us this case comes up frequently enough
> that would like it to be tracked and Carlos suggested adding it to the
> When we change the implementation of exp, I still feel like keeping
> our eye on cases like this as well as the hard to round cases are
> interesting. We want to make sure things like that don't blow up. That
> was my intent with this.
Agreed. That's a better explanation than mine :-)