On Thu, Dec 3, 2009 at 8:15 AM, Bill Hart <[email protected]> wrote: > Hi Case, > > Thanks for those figures. Can you let me know what you mean by > "digits"? Do you mean limbs or decimal digits?
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. The MS-SDK compiler selected p3 as the CPU type. But the actual CPU is a Core2 Duo. The CPU type is correctly detected when I do a 64-bit build. > > 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. > > > -- 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.
