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] Inline C99 math functions


On Mon, 15 Jun 2015, Wilco Dijkstra wrote:

> > Where are the benchmarks for this?  Please put them in benchtests so
> > actual reproducible figures can be given.  That's the standard practice
> > for any change being justified on the basis of performance.
> 
> I'll add a benchmark in another patch - it's not trivial as benchtest is not
> suitable to accurately time very simple functions, especially when inlined...

Well, the benchmark should come first....

> > What are the effects on code size (especially for fpclassify)?  If code
> > becomes larger, conditioning on !defined __OPTIMIZE_SIZE__ should be
> > considered.
> 
> Codesize of what? Few applications use these functions... GLIBC mathlib is 

Size of any code calling these macros (for nonconstant arguments).

> Also I don't think having special inlines that are only used inside 
> GLIBC is a good approach - if the GCC built-ins are not fast enough then 
> we should fix them.

Yes, we should improve the built-in functions, but first we should 
understand the effects on performance of glibc libm functions (I don't 
know if the existing benchtests cover cases where __finite / __isnan / 
__isinf_ns inlines were used) to see if this cleanup patch indeed doesn't 
significantly harm performance of affected libm functions (and possibly 
improves performance through the changes in cases that wouldn't previously 
have been inlined at all).

-- 
Joseph S. Myers
joseph@codesourcery.com


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