On Dec 3, 4:15 pm, 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?
>
> 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
> >>> athttp://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
> >> athttp://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
> > athttp://groups.google.com/group/mpir-devel?hl=en.- Hide quoted text -
>
> - Show quoted text -
I have now added a Windows build for nehalem so the 64-bit targets
supported on WIndows are now k8, k10, core2 and nehalem.
Brian
--
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.
