----- Original Message -----
From: "Bill Hart" <goodwillh...@googlemail.com>
To: <mpir-devel@googlegroups.com>
Sent: Tuesday, November 09, 2010 8:10 PM
Subject: Re: [mpir-devel] MPIR-2.2.0-rc1 released
On 9 November 2010 19:09, Jason <ja...@njkfrudils.plus.com> wrote:
On Tuesday 09 November 2010 17:58:39 Bill Hart wrote:
Hi Jason,
This is great!
So far:
On selmer (k102-unknown-linux-gnu) everything passes.
On my 48 core AMD Magny Cours it misconfigures as
x86_64-unknown-linux-gnu (should be k102):
vendor_id : AuthenticAMD
cpu family : 16
model : 9
model name : AMD Opteron(tm) Processor 6174
stepping : 1
I'll add that in a minute to the svn , thanks , I wish AMD would document
what
model numbers they use , same for Intel . I know why they dont , they want
you
to rely on checking the feature bits from cpuid , Agner Fog has also
suggested
this on the GMP mailing list. The problem is , it's useless , all it tells
you
is that the code will not crash. We need to know if it is faster. eg K8
supports SSE2 , so what its no faster than MMX on the K8 , and you have to
worry about alignment , ie it needs more cases for the unaligned bit. OK
the
code size is smaller , but I have not come across a case when code size
was
the bottle neck , plus with the extra unaligned case the overall code
would be
quite a bit bigger. Plus of course the real main difference is the
scheduling
algorithm used by the cpu , we DEPEND on it , and you can infer nothing
about
it from the cpuid feature bits . We MUST have the micro-architecture
family/model/stepping number to make an informed choice.
We could make a guess ie that family 16 are all K8-like , but they dont
have
any logic to the numbering and I feel sure this would bite us in the arse
in
the future.
Yes, I agree, it is not enough to rely on feature bits.
However make -j48 works (in 13s :-)).
nice , I'm jealous.
On sage.math (penryn-unknown-linux-gnu) everything passes.
On redhawk (k102-unknown-linux-gnu) everything passes. However, there
was this when running make check:
memory.c: In function ātests_reallocateā:
memory.c:111: warning: format ā%uā expects type āunsigned intā, but
argument 2 has type āsize_tā
memory.c:111: warning: format ā%uā expects type āunsigned intā, but
argument 3 has type āsize_tā
memory.c: In function ātests_freeā:
memory.c:153: warning: format ā%uā expects type āunsigned intā, but
argument 2 has type āsize_tā
memory.c:153: warning: format ā%uā expects type āunsigned intā, but
argument 3 has type āsize_tā
Yeah , I seen this before on cuda.tarbox , do we have access to it at the
mo?
No, I believe that machine has been taken offline. Redhawk is
William's machine. I think some sage devels have access. Maybe he can
arrange an account for you to fix this. Best to email him if he
doesn't see this.
I fairly sure I can access redhawk , if it uses the same credentials as
sage/mod/T2 etc
There are similar warnings for various other files, e.g. io.c.
On todd (pentium4-pc-linux-gnu) everything passes.
On a turion-64 laptop with Windows "I'm so bloody slow" Vista, with
the latest Cygwin (k8-pc-cygwin) everything passes (after installing
gcc, g++, gnu make, m4).
You got cygwin to pass???
Only a standard build. I didn't try with any configure options at all.
I've just wiped and downloaded it again (on Win32) and it appears OK ,
weird... , perhaps they fixed something! One thing I did do was to download
and install just the minimal , and then do another selection of gcc make ,
and I didn't explictly select the mingw parts (although they get selected as
requirements)
I'll try this on win64 when I finished with mingw32 and cygwin32 and msvc32
I use latest cygwin gcc gcc-core gcc-g++ gcc-mingw gcc-mingw-core
gcc-mingw-
g++ make mingw-runtime subversion joe m4 unzip
and I got those errors , perhaps I try a more cut down approach
I only have MSVC 2010 on this machine, and it
is so slow it brings my laptop to a halt if I even run it, so I can't
test this.
I tried to build on t2, but it just says there is no working compiler,
which sounds about right. I guess compilers are a "gnu thing" and not
available on solaris (or more likely I have some environment vars set
incorrectly, but can't be bothered figuring it out).
They were set correctly over the summer (both 32 and 64bit) , as I used T2
a
few times , better let David know.
It might be something in my .bashrc.
They dont work for me at the mo , same for fulvia and varro
I only did a standard build and make check in each case, nothing fancy.
The new set of supported arches looks much more realistic but still
quite comprehensive of what people actually use, and the cleaning up
is making things look much more maintainable. I hope this encourages
people that they can contribute to MPIR now, given that it is becoming
much simpler to do so.
There's plenty more clean-ups to do.
I'm thinking for v2.3 what I plan to do is
assembler code(plus some associated C code)
command line builds for MSVC
more clean-ups
and all the usual other bits...
I thought I'll leave out doing any C code , as advanced algoritms should
prove attractive for other people , real reason is that I dont want to learn
any new math :)
Congratulations on getting full assembly support in MinGW 64! That is
a really significant achievement for MPIR!! I think the MinGW 64
project would surely like to hear about this.
Bill.
On 9 November 2010 14:55, Jason <ja...@njkfrudils.plus.com> wrote:
> Hi
>
> MPIR-2.2.0-rc1 is released for testing here
>
> http://www.mpir.org/mpir-2.2.0-rc1.tar.gz
>
> Changes are:
>
> Explicit support for ancient cpu's and OS's has been removed
>
> Demo programs have been removed from the library
>
> Upgrade to the latest Yasm,autotools,gnulib
>
> Removal of the pre-build stages
>
> Testing of DLL builds for MSVC now work
>
> General simplification and tidying up of the code
>
> make check tests now can run in parallel
>
> Full assembler support for MinGW64 (known as *-w64-mingw32)
>
> On x86/x64 with GCC the library is now built with noexecstack , a
> security feature for SELinux (ie Fedora 12/13)
>
> Known problems:
>
> Cygwin builds fail , although this appears to be a problem with Cygwin
> itself and not MPIR as the previous MPIR now fails , whereas it did
> work
> before.
>
> The batch builds (ie ./configure ,make ,make check) for MSVC have not
> been updated for the new file layout and so make clean does not
> clean-up
> properly and make check does not work for DLL builds. NOTE: The
> underlying MSVC projects are fine , it's just the batch builds which
> call them. The batch builds have been depreciated in favor of a command
> line type build which is slated for the next major release.
>
> Reports of the results of any testing done (whether pass or fail) are
> greatly appreciated. Please do and try a few combinations of options ie
> --enable-shared
> --enable-static
> --enable-fat
> --enable-assert
> --enable-cxx
>
> and please report the output of ./config.guess
>
> Thanks
> Jason
>
> --
> You received this message because you are subscribed to the Google
> Groups
> "mpir-devel" group. To post to this group, send email to
> mpir-de...@googlegroups.com. To unsubscribe from this group, send email
> to mpir-devel+unsubscr...@googlegroups.com. For more options, visit
> this
> group at http://groups.google.com/group/mpir-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-de...@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
