Release candidate 2

[Bill Hart]

Here is the link to release candidate 2 tarball:

http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz

and docs:

http://sage.math.washington.edu/home/wbhart/mpir.pdf

If no further bugs are found, this will become the final release.

Known Issues:

* MSYS and mingw32: --enable-fat build failure
* Cygwin32: make check fails if build path contained spaces
* X86 32 bit Apple gcc: no PIC support in assembly code
* Make tune will core dump with small probability on loaded machines
* Possible memory leak in t-locale
* Generic (without assembly support) build (--host=none) fails on
x86_64
* Berkeley MP functions temporarily unsupported in this release
* Fat binary x86_64 build will fail with old GNU and Sun assembler
versions
* 30/36 Yasm tests will fail on some Sun x86 and x86_64 systems
(harmless)

Bill.

[Jason Moxham]

On Monday 16 March 2009 00:38:00 Bill Hart wrote:
> Here is the link to release candidate 2 tarball:
>
> http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz
>
> and docs:
>
> http://sage.math.washington.edu/home/wbhart/mpir.pdf
>
> If no further bugs are found, this will become the final release.
>
> Known Issues:
>
> * MSYS and mingw32: --enable-fat build failure
> * Cygwin32: make check fails if build path contained spaces
> * X86 32 bit Apple gcc: no PIC support in assembly code
> * Make tune will core dump with small probability on loaded machines
> * Possible memory leak in t-locale
> * Generic (without assembly support) build (--host=none) fails on
> x86_64

This works OK as far as I can tell , do we have more details

[Bill Hart]

details?

2009/3/16 Jason Moxham <ja...@njkfrudils.plus.com>:

[Jason Moxham]

These all pass on i7

./configure --host=none && make -j 8 && make -j 8 check && make distclean

./configure --host=none-unknown-linux-gnu && make -j 8 && make -j 8 check &&
make distclean

./configure --build=none-unknown-linux-gnu && make -j 8 && make -j 8 check
&& make distclean

[Bill Hart]

Do you mean details of these issues? If so, there are trac tickets for
each of them. Below the red ones.

Bill.

2009/3/16 Jason Moxham <ja...@njkfrudils.plus.com>:

[Jason Moxham]

Ticket 110
A generic build (no assembly, i.e. host=none) fails on x86_64 machines. This
is a problem in configure.

this is all it says , unless I'm using it wrong

[Bill Hart]

Nope, you are using it right. It doesn't tell you more than we know.
Besides, you were the one who reported it.

[Bill Hart]

I've updated the website http://www.mpir.org/ . Let me know of any
errors or omissions.

I'll now post to various lists.

Bill.

2009/3/16 Bill Hart <goodwi...@googlemail.com>:

[Bill Hart]

Done.

2009/3/16 Bill Hart <goodwi...@googlemail.com>:

[Jason Moxham]

On Monday 16 March 2009 01:56:28 Bill Hart wrote:
> Nope, you are using it right. It doesn't tell you more than we know.
> Besides, you were the one who reported it.

The closest one I could find is this from thread "trunk distclean broken" from
29/12/08 , this has been fixed for a while

after doing
./configure --build=none && make && make check

make distclean fails with
rm -f *.lo
rm -f *.tab.c
test -z "" || rm -f
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f Makefile
make[1]: Leaving directory `/root/mpir/mpir/mpir/trunk/mpz'
Making distclean in mpn
make[1]: Entering directory `/root/mpir/mpir/mpir/trunk/mpn'
rm -rf .libs _libs
test -z "libmpn.la" || rm -f libmpn.la
rm -f "./so_locations"
rm -f *.o
test "" = "" || rm -f *_.c
rm -f *.lo
rm -f *.tab.c
test -z "" || rm -f
rm -f libtool
rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
rm -f Makefile
make[1]: Leaving directory `/root/mpir/mpir/mpir/trunk/mpn'
Making distclean in yasmbuild
make[1]: Entering directory `/root/mpir/mpir/mpir/trunk/yasmbuild'
cd ../yasm; make distclean
make[2]: Entering directory `/root/mpir/mpir/mpir/trunk/yasm'
make[2]: *** No rule to make target `distclean'. Stop.
make[2]: Leaving directory `/root/mpir/mpir/mpir/trunk/yasm'
make[1]: *** [distclean] Error 2
make[1]: Leaving directory `/root/mpir/mpir/mpir/trunk/yasmbuild'
make: *** [distclean-recursive] Error 1

[Bill Hart]

That would be it. I'll close the ticket and update the website.

[Bill Hart]

Probably tickets 87 and 95 no longer apply too, but we should check I guess.

Bill.

2009/3/16 Bill Hart <goodwi...@googlemail.com>:

[Jason Moxham]

On Monday 16 March 2009 02:56:46 Bill Hart wrote:
> Probably tickets 87 and 95 no longer apply too, but we should check I
> guess.

#95 is definitely dead , mpir configure runs yasm configure so all make target
are there on all machines

[Jason Moxham]

#16 is not applicable anymore as this refered to the old AMD sqr-basecase
#10 is done , for k10 ,core2 , no advantage for k8
#2 doesn't apply for the current code as we dont jump into loops
#45 looks like you fixed , but I'm not sure
#63 is way out of date , we done it
#14 is mostly done

On Monday 16 March 2009 02:56:46 Bill Hart wrote:

[Jason Moxham]

New ticket

tests/devel/try.c doesn't test all possible overlaps for functions with 3 or
more source operands.

[Jason Moxham]

#43 Currently yasm builds unconditionally, whether it is needed or not.

This is not true , so we could kill this ticket , unless we want mpir
configure's and use a system wide yasm.

[Emmanuel Thomé]

On Mar 16, 1:38 am, Bill Hart <goodwillh...@googlemail.com> wrote:
> Here is the link to release candidate 2 tarball:
>
> http://sage.math.washington.edu/home/wbhart/mpir-1.0.tar.gz

config.guess has executable bit unset in this tarball, which seems
weird. Not too much of a problem, since install gets it right anyway.

svn propset svn:executable t config*guess config*sub ?

E.

[Bill Hart]

Hi Emmanuel,

I'm sure we've turned it on numerous times before. I think our svn is
broken wrt that feature.

Probably we should have make dist chmod it. Perhaps Jason can arrange that.

Bill.

2009/3/16 Emmanuel Thomé <Emmanue...@gmail.com>:

[Bill Hart]

I've killed most of these and the others you mentioned.

We could probably write assembly code for Athlon 64 and nocona and
have separate directories for them, but we can add a ticket should we
decide to do this.

[Jason Moxham]

On Monday 16 March 2009 14:23:31 Bill Hart wrote:
> Hi Emmanuel,
>
> I'm sure we've turned it on numerous times before. I think our svn is
> broken wrt that feature.
>
> Probably we should have make dist chmod it. Perhaps Jason can arrange that.
>

can do , but I think I know how to fix

delete config.guess and commit it
create config.guess with chmod 755 and commit it

this looks like it fixes it , a files permission are stuck at what ever they
were when you first commited that file.

[Bill Hart]

I don't think that is right. svn does not preserve file permissions.

I've again tried to set the relevant flags in svn and updated the
tarball. No idea whether it worked. But given that we've done this
before, I think the make dist is the safest option.

Bill.

2009/3/16 Jason Moxham <ja...@njkfrudils.plus.com>:
>

[Jason Moxham]

On Monday 16 March 2009 15:01:58 Bill Hart wrote:
> I don't think that is right. svn does not preserve file permissions.
>
> I've again tried to set the relevant flags in svn and updated the
> tarball. No idea whether it worked. But given that we've done this
> before, I think the make dist is the safest option.
>
> Bill.
>

done

[Bill Hart]

I checked the latest tarball and it seems ok now.

Should also apply to the mpir-1.0 branch so that this change makes it
into the service releases.

Bill.

[Jason Moxham]

On Monday 16 March 2009 15:17:48 Bill Hart wrote:
> I checked the latest tarball and it seems ok now.
>
> Should also apply to the mpir-1.0 branch so that this change makes it
> into the service releases.
>
> Bill.
>

[Jeff Gilchrist]

Looks so far for me. I did some Itanium2 tests, core2 tests. Windows
builds are looking good, all the tests are there and working after
that last commit Brian did. I forgot how out of date Itanium
processors are now that 64bit x86 have hit the scene.

Intel Core2 Q9550 @ 3.4GHz (45nm, Family 6, Model 7, Stepping 7)
83338 bits (25088 digits)
Library Time1 Time2
------------------------- --------- ---------
MPIR 1.0.0 (MSVC 64bit) 1m45.267s 1m45.240s
MPIR SVN1728 (gcc 64bit) 1m45.864s 1m45.722s
MPIR SVN1728 (MSVC 64bit) 1m47.063s 1m47.095s
GMP 4.2.4 (MSVC 64bit) 1m53.472s 1m53.505s
MPIR 0.9.0 (MSVC 64bit) 1m53.709s 1m53.709s
MPIR 0.9.0 (gcc 64bit) 2m04.794s 2m04.859s
GMP 4.2.4 (gcc 64bit) 3m19.200s 3m19.089s

125002 bits (37630 digits)
Library Time1 Time2
------------------------- --------- ---------
MPIR SVN1728 (gcc 64bit) 4m51.502s 4m51.395s
MPIR 1.0.0 (MSVC 64bit) 4m53.591s 4m53.810s
MPIR SVN1728 (MSVC 64bit) 4m57.288s 4m57.345s
MPIR 0.9.0 (MSVC 64bit) 5m14.861s 5m15.095s
GMP 4.2.4 (MSVC 64bit) 5m17.398s 5m17.237s
MPIR 0.9.0 (gcc 64bit) 5m49.962s 5m49.823s
GMP 4.2.4 (gcc 64bit) 9m23.591s 9m23.568s

Intel Itanium2 @ 1.6GHz (Family 32, Model 0, Revision 7)
83338 bits (25088 digits)
Library Time1 Time2
------------------------- --------- ---------
GMP 4.2.4 (gcc 64bit) 6m05.653s 6m05.642s
MPIR 0.9.0 (gcc 64bit) 6m05.668s 6m05.650s
MPIR 1.0.0 (gcc 64bit) 6m08.908s 6m08.909s

125002 bits (37630 digits)
Library Time1 Time2
------------------------- --------- ---------
GMP 4.2.4 (gcc 64bit) 16m46.918s 16m46.935s
MPIR 0.9.0 (gcc 64bit) 16m46.912s 16m46.917s
MPIR 1.0.0 (gcc 64bit) 16m56.734s 16m56.565s

[Jeff Gilchrist]

Just wondering what the status of 1.0.0 is. Are the changes people
have been talking about recently going to be rolled into 1.0.0 so we
will have an rc3 or will rc2 stay the same and become the official
1.0.0?

Jeff.

[Bill Hart]

There's been no word on the result of further testing in Sage, at this point.

I strongly suspect there will be no further candidates and this will
be final, but it seems logical to have the Sage developers test it as
part of their release cycle as the number of systems that it then gets
tested on is much larger than what we can manage ourselves.

I understand Mariah has also done some testing, so things are looking good.

Bill.

2009/3/25 Jeff Gilchrist <jeff.gi...@gmail.com>:

[Jeff Gilchrist]

I just tried compiling it on a brand new MacBook Pro (Core2) and it
works fine (make + make check) but I did see this in the output:

checking for inline... inline
configure: WARNING: mpir.h doesnt recognise compiler "inline", inlines
will be unavailable

So I'm not sure if that is a problem, will the reduce the performance
because it is not going to use any inline assembler?

This is with: gcc version 4.0.1 (Apple Inc. build 5490)
Darwin Kernel Version 9.6.2

Jeff.

[Bill Hart]

The short answer is I don't know whether it causes a performance
deficit. I also don't have a workaround at present.

However this is a long standing issue, for which we have a ticket.
Obviously we've focused very much on the low hanging fruit performance
wise.

*If* it makes any difference, you would notice it on the first two
multiplication tests in mpirbench (as compared with a machine with the
same architecture but different gcc for which the warning is not
issued).

Bill.

2009/3/25 Jeff Gilchrist <jeff.gi...@gmail.com>:
>

[Bill Hart]

Actually, perhaps you wouldn't notice it on the bench at all. You
might notice it for things like mpz_get_ui which are inlined in gmp.h.

Bill.

2009/3/25 Bill Hart <goodwi...@googlemail.com>: