2009/10/2 Antony Vennard <antony.venn...@gmail.com>: > > Hi All, > > I'm the new guy on the mailing list (Antony). I'm here after a > discussion with Bill about some research he published. Basically I'm an > ex-student (long story) and self taught programmer (not one of those > .net types (sorry .net types) but the sort who have a copy of Kernighan > & Ritchie's The C Programming Language) with an interest in things like > parallel programming and CUDA. Bill suggested I might like to get > involved and help out, so I thought I'd give it a try when I get the time.
Welcome aboard. > > Anyway, that's my introduction over with, I have a few questions: > > * This latest set of code, I assume that's available in the trunk (as > asked previously)? Yes, in trunk, though the mpir-mt stuff is not in there yet. It will be in a couple of days if I get my act together. > * I pulled the trunk about a week ago and the version reported is > v1.3.0something, I assume this is reflects the big changes discussed > previously too? Just making sure I'm reading up to date(ish) code. Yeah, this will be 1.3.0. > * Are there any plans to move to git or mercurial or something like > that? If not, not a problem, I've just never bothered learning > subversion (except for "co") (but can do if needed). > The plan is to move to git. I hope that will happen this month, but it will be after the release probably. I have the machine set up for this and have been getting some experience with using GitWeb, which is great. > Bill has given me a good description of how the library works, so next > question is, > * how are you attacking parallelism / cuda etc or is this still an open > discussion? That's definitely still a very open question. If you get access to the list archives you'll find a very long discussion which was had about CUDA. In particular there was a meeting at which some of this was discussed and we posted our (random) thoughts to a wiki. But that's about all the planning we've done for CUDA. For parallelism we are going to go down two or three paths simultaneously I think. One path will be OpenMP, a second will be CUDA with NVIDIA assembly language too eventually, I think. There's also the new Intel thing, is it still called Larrabee, for which we'll have assembly code. So just as lots of different architectures are supported at the CPU level, so different kinds of hardware will be supported at the parallel level too, whether they be GPU's, combined CPU/GPU's or even just multicore CPU's. Whatever we do it is going to be an uphill battle. The big issue is that many basic multiprecision operations take less time that starting a thread and often one has to get all the data into the cores and back out again, which can take more time than the actual computation. All we can really do is see what is possible and release any code which we can get to work efficiently. Bill. > > I can be reached on this e-mail which I use for all things remotely > public or at a.nto!ny at venn!ard dot or.g do.t uk (w/o punctuation) if > you prefer, I don't mind which. GPG keys at OpenPGP Key: > http://vennard.org.uk/keys/arv_gmail.asc and OpenPGP Key: > http://vennard.org.uk/keys/arv_vouk.asc > > Thanks, and hoping to be able to help, > > Antony > > Cactus wrote: >> >> On Oct 2, 7:38 pm, Bill Hart <goodwillh...@googlemail.com> wrote: >>> I know I've been saying it for a while now, but the next version of >>> MPIR is coming *soon*. Two major pieces of code still need to be >>> written: >>> >>> 1) A new mpn_tdiv_qr function, using David Harvey's new divide and >>> conquer division code (which I now have working fully in MPIR). >>> >>> 2) A configure option --enable-mt for multithreaded mode which will >>> switch in some multithreaded multiplication routines designed by Marc >>> Glisse and myself. >>> >>> Jason Moxham is also finishing off some new assembly code, and then >>> Brian Gladman will probably convert it for Windows. >>> >>> The new release of MPIR is *massive*. The amount of new code and >>> number of speedups is pretty staggering. We definitely should have >>> done a number of smaller releases, however, for various reasons a >>> couple of the very major new features which we promised took a very >>> long time to get done and during that time all these other features >>> got added, many of which are major in their own right. >>> >>> Anyhow, I definitely think we are working towards releasing well >>> before Oct 15. That means if you are interested in testing it in Sage >>> before that Sage release it should be possible. Jason and Brian can >>> you let us know whether you are happy with what I propose below. >>> >>> A rough timetable might be as follows. Jason and I might aim to get >>> our new code working over this coming weekend (weekends always include >>> part of Monday for me if necessary). Brian may be able to do any final >>> conversions for Windows which are necessary for the next release over >>> the coming week. We'll begin testing on Linux during next week with a >>> release by Oct 12th. Perhaps a preliminary *nix release might be >>> available for Sage to try out by about 10th Oct. I guess Sage Windows >>> releases are not timed to coincide with the Sage *nix release so >>> hopefully that poses no problems. If all goes well with final testing >>> that should actually be the final release of MPIR for *nix. Final MPIR >>> release for all platforms can then be done before or on the 12th. >>> >>> MPIR will of course have been tested against its own test suite on >>> piles and piles of different architectures (almost 30). We hope for a >>> clean result when tested against Sage's test suite, but with such an >>> enormous amount of new code, we obviously have to prepare for the >>> possibility that our test suite has missed something. For Sage that >>> should be easy, just back it out again and put the old spkg back in >>> and try again on another release cycle. >>> >>> Bill. >>> >>> 2009/10/2 William Stein <wst...@gmail.com>: >>> >>> >>> >>>> Hi, >>>> Sage-4.1.3 should be a new thread. >>>> Some of my personal interests include: >>>> * getting as many of the Solaris, Cygwin, and FreeBSD fixes in as >>>> possible. >>>> * Making it so "SAGE_FAT_BINARY" actually works, i.e., so Sage >>>> binaries work on old machines with fancy "ssse3", etc. (Which means >>>> fixing ATLAS and MPIR). >>>> Also, making sure that sage-4.1.3 happens in a timely manner, e.g., >>>> around October 15-20 (say). >>>> -- William >>>> -- >>>> William Stein >>>> Associate Professor of Mathematics >>>> University of Washington >>>> http://wstein.org >> >> I am up to date on the Windows assembler conversions except for >> Jason's mod_1_<n> code where I am waiting for Jason's signal that it >> bis stable enough for conversion. >> >> The changes to the Windows builds have however been significant so I >> would appreciate assistance from Jeff Gilchrist and any other Windows >> users in the testing of the SVN trunk version. The OpenMP stuff >> needs building and testing on Windows - is this in trunk? >> >> Brian >> >> > >> > > > -- > Antony Vennard > > Web Address: http://vennard.org.uk/ > OpenPGP Key: http://vennard.org.uk/keys/arv_gmail.asc > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-devel@googlegroups.com To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en -~----------~----~----~----~------~----~------~--~---
