This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2] Convert mantissa storage in mp_no to int
- From: Siddhesh Poyarekar <siddhesh at redhat dot com>
- To: "Carlos O'Donell" <carlos at systemhalted dot org>
- Cc: "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Mon, 4 Feb 2013 10:49:59 +0530
- Subject: Re: [PATCH v2] Convert mantissa storage in mp_no to int
- References: <20121220191320.GD26426@spoyarek.pnq.redhat.com><Pine.LNX.4.64.1212202034170.24913@digraph.polyomino.org.uk><20121221021737.GF26426@spoyarek.pnq.redhat.com><20121221024840.GA9870@spoyarek.pnq.redhat.com><5106C9F9.4090505@systemhalted.org>
On Mon, Jan 28, 2013 at 01:56:57PM -0500, Carlos O'Donell wrote:
> This looks good to me.
>
> Is Power using this code?
>
> What does the performance look like there?
>
Thanks for the review, but this does affect Power performance
adversely as I had found later (and hence not pinged the patch again
since). I'm still convinced on the utility of using integer math for
mpa on x86, but I'll have to come up with a way to accomodate Power in
the change.
> I'm getting more nervous of these kinds of micro-optimizations
> in isolation without a global view of our libm performance.
>
> I'd really like to see more progress on a libm micro-benchmark
> that we can use to see how these changes impact *ALL* of the
> functions in libm. At a minimum we need to test the inputs
> identified in the current testsuite.
Isn't [1] a good enough starting point? Tulio has added some tweaks
to get it working on Power[2] and if you think it's good enough, I can
merge it into trunk and start adding numbers for various functions.
As Ryan and Steven have mentioned in the first thread, we can live
with the indeterminate syscall time for clock_gettime() if the inputs
have enough iterations so that the syscall time is just a fraction of
the total time. I also intend to experiment with clock(3) to see if I
get better/consistent numbers.
Siddhesh
[1] http://sourceware.org/ml/libc-alpha/2013-01/msg00703.html
[2] http://sourceware.org/ml/libc-alpha/2013-01/msg00995.html