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. >> 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 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. > >> >> 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... > >> 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.
