This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Convert mantissa storage in mp_no to int
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Thu, 20 Dec 2012 20:41:41 +0000
- Subject: Re: [PATCH] Convert mantissa storage in mp_no to int
- References: <20121220191320.GD26426@spoyarek.pnq.redhat.com>
On Fri, 21 Dec 2012, Siddhesh Poyarekar wrote:
> The side-effect of the storage being double is that the generated code
> is all fp arithmetic, which is a lost opportunity for optimization.
> Attached patch converts this double array to int and adjusts mp code
> accordingly. This patch is not exhaustive in terms of converting all
> possible fp operations to integer operations, but it ensures that
> correctness of operations is maintained. I'll be following up with
> patches for individual functions to tighten them up and eliminate fp
> operations wherever possible.
It would be interesting to compare the performance of this code with the
GMP-based code used in strtod and printf (which, for example, supports
Karatsuba multiplication, although maybe the threshold involved means that
isn't actually relevant for the cases used in libm).
(Making cpowl give good results will need intermediate calculations to
over 16000 bits in some cases.)
> I have verified that the testsuite runs clean after this change. Like
For both 32-bit and 64-bit systems that use this code?
> + long tmp = Z[k];
> + for (i=i1,j=i2-1; i<i2; i++,j--) tmp += (long) X[i]*Y[j];
This doesn't look right for systems with 32-bit long. I don't know if
there are similar problems elsewhere in this code.
--
Joseph S. Myers
joseph@codesourcery.com