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