This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Speedup tanf range reduction

From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
To: Tulio Magno Quites Machado Filho <tuliom at ascii dot art dot br>, Joseph Myers <joseph at codesourcery dot com>
Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, nd <nd at arm dot com>
Date: Thu, 23 Aug 2018 11:46:31 +0000
Subject: Re: [PATCH] Speedup tanf range reduction
References: <HE1PR08MB10357845B62EA7A4DFCD927783300@HE1PR08MB1035.eurprd08.prod.outlook.com> <alpine.DEB.2.21.1808221231420.19290@digraph.polyomino.org.uk> <HE1PR08MB103555974BE551C979EFD28883300@HE1PR08MB1035.eurprd08.prod.outlook.com>,<871saqc60b.fsf@linux.ibm.com>

Tulio Magno Quites Machado Filho wrote:

> LGTM too.

Thanks, I've committed it.

> If we were to have a benchtest for tanf with drand48 inputs, should we group
> the entries according to __kernel_tanf() ? e.g.
>
>  * |x|>=0.6744 - fast path for __kernel_tanf
>  * |x|<=0.6744

Having a real trace would be best, and randomized inputs for commonly used
input ranges are useful. I'm not sure whether a better algorithm would have the
same slow/fast paths as the current code (sinf/cosf are now 4x faster...), but
if you're planning to post a benchtest then testing those ranges would be fine.

Cheers,
Wilco

References:
- [PATCH] Speedup tanf range reduction
  - From: Wilco Dijkstra
- Re: [PATCH] Speedup tanf range reduction
  - From: Joseph Myers
- Re: [PATCH] Speedup tanf range reduction
  - From: Wilco Dijkstra
- Re: [PATCH] Speedup tanf range reduction
  - From: Tulio Magno Quites Machado Filho

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]