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