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.
