RE: [PATCH] Add math-inline benchmark

["Wilco Dijkstra" <wdijkstr at arm dot com>]

> OndÅej BÃlka wrote: 
> On Mon, Jul 13, 2015 at 12:02:51PM +0100, Wilco Dijkstra wrote:
> > > OndÅej BÃlka wrote:
> > > On Fri, Jul 10, 2015 at 05:09:16PM +0100, Wilco Dijkstra wrote:
> > > > > OndÅej BÃlka wrote:
> > > > > On Mon, Jul 06, 2015 at 03:50:11PM +0100, Wilco Dijkstra wrote:
> > > > > >

> > We don't have applications that uses these, but we can say without any
> > doubt that they will show huge speedups if they do use these functions
> > frequently or any math functions that use them a lot. Remainder() for
> > example shows ~7% gain with the new inlines.
> >
> No, this is just microbenchmark as I and Joseph are telling you ten
> times. There are lot factors that could change performance like need of
> constants which you don't measure as you inline remainder. So your
> speedup could be only illusory.

Of course it is a microbenchmark, that's how I wrote it. And because the new 
inlines show huge speedups it proves they will improve performance everywhere.
Note the remainder functions are explicitly not inlined.

> Also which gcc are you using? There is problem that recent gcc started
> optimize better libc inlines but not builtins.

I always use latest trunk.
 
> > > > >From this it seems that __isinf_inl is slightly better than the builtin, but
> > > > it does not show up as a regression when combined with sin or in the remainder
> > > > test.
> > > >
> > > That doesn't hold generaly as remainder test it could be just caused by
> > > isnan being slower than isinf.
> >
> > No, the new isinf/isnan are both faster than the previous versions (some isinf
> > calls were inlined as __isinf_ns, but even that one is clearly slower than the
> > builtin in all the results). Remember once again this patch creates new inlines
> > that didn't exist before as well as replacing existing inlines in GLIBC with
> > even faster ones. The combination of these means it is simply an impossibility
> > that anything could become slower.
> >
> I got that isinf libc inline is faster so how do you explain it?

Why does it matter? My patch as it stands does not change that internal inline.
Again, my patch adds *new* inlines for functions which were previously not inlined.

> > > > Well I just confirmed the same gains apply to x64.
> > > >
> > > No, that doesn't confirm anything yet. You need to do more extensive
> > > testing to get somewhat reliable answer and still you won't be sure.
> >
> > No, this benchmark does give a very clear and reliable answer: everything
> > speeds up by a huge factor.
> >
> While that is true it isn't exactly what we asked. We asked what inline
> is best one. So you need accurate benchmark to also measure that, not
> rough one that could only tell that inlining helps.

No that's not what anyone asked, not what I agreed with Joseph and most 
definitely not what I intended. I posted a patch to speedup these functions
as they are currently not inlined and thus extremely slow, plus a benchmark
to prove that my patch makes a huge difference to performance.

There is no doubt it is possible to improve the GCC built-ins further, so I 
created a bug to do so (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66462). 
However that is beyond the scope of this patch and is likely microarchitecture
specific, so each target has to decide what code they generate for each builtin.

Wilco