Hi Bill, Thank you very much for your reply. It is really helpful. If fat binary is slower then I will simply switch to normal build. The ABI issue is already explained so I will not go into that.
In case it helps, here is my application scenario. The whole computation relies heavily on MPIR, but it only uses integers at most a bit more than 128 bit and mostly basic operations. Since when compiling with mingw64, the generic x86_64 is picked for CPU tuning, I will try later with an appropriate option to see if it will get better timing on my machine. Cheers, fwjmath. 在 2014年2月27日星期四UTC+1下午2时31分44秒,Bill Hart写道: > > Hi fwjmath, > > > > > On 27 February 2014 14:19, fwjmath <fwj...@gmail.com <javascript:>> wrote: > >> Hi all, >> >> I am cooperating with a volunteer computing project (yoyo@home, if anyone >> knows it), and I need MPIR to build a performance-crucial application on >> Windows that will be run on heterogenous CPU. The last version I built also >> uses MPIR, and I am really grateful of all your work. >> >> This time, since the performance of the arbitrary-precision arithmetic is >> extremely important, a fat binary is needed. I downloaded the master branch >> from Git, and I used mingw64 on msys as build environment, with the >> following option for configure >> >> ./configure --disable-fft --disable-shared --enable-fat >> >> The "make" and "make check" were successful, but when compiling the >> application, mingw64-g++ hinted that there are duplicated symbols, namely >> g?mpn_k8_redc_1 in mpn/bobcat/redc_1.asm and ?mpn_core2_redc_1 in >> mpn/sandybridge/redc_1.asm. I did a renaming to get rid of this problem, >> and the application compiles. >> > > Thanks for the report. We will look into this one before the release. > > >> >> But then when I tested it against another build with the following option >> >> ./configure --disable-fft --disable-shared >> >> the fat binary is slower by about 10%. > > > The fat binary should be slower. The fat binary uses a runtime lookup > table of functions for a variety of processors which slows many things down. > > >> Furthermore, comparing to GMP on cygwin64, there is also a large >> slowdown. Here are some rough timing: >> >> msys-mpir-fat ~60min >> msys-mpir-nofat ~55min >> cygwin64-gmp-nofat ~40min >> > > Cygwin uses a different ABI to msys. So I expect the times to be different. > > I'm not saying that for your particular application GMP won't be faster. > That's possible, as we haven't finished with performance improvements for > this release yet (and sometimes they are faster than us and vice versa even > when we do make a release). > > >> >> I was not able to build MPIR on cygwin, it was more or less stucked when >> building libmpn.la with libtool. I have used the --with-system-yasm >> option (or else it complains on cygwin-style symbolic links). >> > > Thanks again for the report. Obviously the master branch is not ready for > a release yet! > > >> >> The build environment: >> CPU: i7 3720QM (Ivy Bridge) >> Memory: 8GB >> MPIR version: 2014-02-26 >> Mingw64 version: gcc-4.8.2 >> Msys version: 2011-11-23 >> >> I would deeply appreciate any useful suggestion. Thank you in advance! >> >> Cheers, >> fwjmath. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "mpir-devel" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mpir-devel+...@googlegroups.com <javascript:>. >> To post to this group, send email to mpir-...@googlegroups.com<javascript:> >> . >> Visit this group at http://groups.google.com/group/mpir-devel. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.