Hi Case, Thanks for those figures. Can you let me know what you mean by "digits"? Do you mean limbs or decimal digits?
The 32 bit multiply times are a surprise to me. I can think of no good reason for the comparison to be that differentiated. The assembly code should be very similar, if not the same, and the compilers should be roughly equally optimised. I will run some timings with the TCC version of MPIR that I produced and some MinGW timings (using gcc) and compare. That will give a rough idea of how bad the TCC compiler is compared to gcc. I expect it to be worse than both gcc and MSVC, but given the comparisons you have posted, I won't rule out an unexpected surprise. I note you have an rc1 based on our rc3. That implies we should pull our finger out and get a release out. Still no progress on rewriting the dc_divappr_q_n.c file. I think I am just going to do this myself. It won't be an independent implementation, but at least it will be different, and the original author will not get blamed for bugs. I have a very slightly improved algorithm, with sketch of proof, that I can use. We also need to fix the next_prime issue on 32 bit machines, the bug in the /x86/k7/mmx/diveby3.asm file and check that no further tickets have been opened which urgently need fixing. Then we can do an rc4. There's also some documentation, giving credit to various individual, which must be completed as soon as possible. Bill. 2009/12/3 Case Vanhorsen <[email protected]>: > On Wed, Dec 2, 2009 at 9:23 AM, Bill Hart <[email protected]> wrote: >> I fully agree with this perspective. Most users do still seem to be >> using 32 bit Windows. But those who are concerned about performance >> have access to 64 bit machines. The main thing is for performance not >> to suck so badly on 32 bit Windows that development is difficult to >> do. >> >> I actually don't think we have that problem though. Performance is >> really not too bad. I estimate a factor of 4 behind 64 bit linux, for >> the worst cases. The average case is probably a lot closer to 2, which >> is quite respectable. > I made some measurements when I released gmpy 1.11rc1 with > mpir-1.3.0rc3. I timed multiplying and adding 2000 digit numbers. > > 32-bit Windows, compiled using MS SDK > multiply: 51 usec add: .8 usec > > 32-bit Windows, compiled using MinGW > multiply: 34 usec add: .7 usec > > 64-bit Windows, compiled using MS SDK > multiply: 13.7 usec add: .3 usec > > 64-Linux > multiply: 11.8 usec add: .18 usec > > The MinGW build can take advantage of the --enable-fat but the compile > time is measured in hours. The MS SDK compile time is only a minute or > two. > > casevh >> >> One thing which is probably really killing us is tuning, which seems >> hard to do in general, let alone on Windows. There does seem to be >> millisecond timing available through the OS. I haven't really made any >> serious attempt at getting 32 bit cycle timing working though. I'm not >> even sure if my machine has a cycle counter. >> >> At any rate, the current FFT code is particularly difficult to tune >> regardless of how it is done. That makes me want to replace it with >> something which can be tuned more easily. Of course that is not a >> simple overnight project though. >> >> BTW, I did some timings of the FLINT FFT on Windows (which is easy to >> tune). I can only build FLINT with TCC, not MSVC at present, so that >> is what I am comparing. The FLINT FFT is up to twice as fast as the >> MPIR one, but sometimes it falls just slightly behind the MPIR one. At >> present I could probably effectively tune the FLINT FFT, but not the >> MPIR one on Windows. >> >> Bill. >> >> 2009/12/2 Jeff Gilchrist <[email protected]>: >>> On Wed, Dec 2, 2009 at 7:57 AM, Cactus <[email protected]> wrote: >>> >>>> In order to reduce the complexity of the Windows build projects, I am >>>> now inclined to split the mpir Windows build solution into two >>>> separate build solutions, the first for 32-bit builds and the second >>>> for 64-bit builds. I would be interested to hear people's views on >>>> this. >>> >>> That makes a lot of sense to me. It is easy enough for people to >>> choose with solution to load as long as it is clearly marked as 32bit >>> vs 64bit and then the solution itself is a lot easier to maintain. >>> Then within the 64bit solution for example, you perhaps could have >>> separate build parameters with things like Release-K8, Release-K10, >>> Release-Core2, Release-i7 or whatever if there are different >>> assembler files or configuration options people can easily select >>> which platform they want to build for. >>> >>>> If there is still a strong interest in 32-bit performance, we need >>>> volunteers to maintain and develop this apsect of MPIR on Windows as I >>>> don't have the time (or the inclination) to do it. Is 32-bit >>>> performance on Windows still important and, if it is, is anyone >>>> willing to volunteer to take on the work involved? >>> >>> Based on what I have seen, the majority of systems out there are still >>> running 32bit operating systems so a lot of people are still using >>> 32bit code for stuff that 64bit makes more sense. So yes I think >>> 32bit performance is still important, but I do not have the time to >>> maintain or develop the 32bit Windows side either. People who are >>> really concerned about performance will have a 64bit OS these days so >>> while 32bit performance is important and is what the majority of >>> people still use, I don't think anyone needs to kill themselves trying >>> to push the 32bit code as far as it can go. >>> >>> Jeff. >>> >>> -- >>> >>> You received this message because you are subscribed to the Google Groups >>> "mpir-devel" group. >>> To post to this group, send email to [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
