2009/5/1 Marc <marc.gli...@gmail.com>: > > Hello, > > On Apr 27, 9:47 am, Bill Hart <goodwillh...@googlemail.com> wrote: >> The current major pushes in MPIR development are: >> >> * Faster assembly code on a variety of platforms > > (vote for making a mul_1 that uses the new sparc64 VII integer addmul > instruction, if you can get your hands on the hardware)
Yes, that sounds great! > >> * Support for parallel processing (e.g. multithreaded code) and GPU's > > This is the part I am curious about: what are your plans there? In > particular, at what level do you place the parallelism? The code is > already thread-safe. Do you want to port it so it runs on the GPU, and > each GPU core can do a separate operation (the parallelism is still at > the level of the application)? No, that's not the plan at this stage. I doubt it would be very useful. > Or do you want to put the parallelism > at a lower level so the many cores of the GPU are used for a single > mpn operation? Yes, this is the plan at least. > For multi-threading, there are some easy possibilities > in mpq (not so much in mpz, except for things like the Miller-Rabin > test) and inside mpn, for instance in the fft and toom codes (a couple > openmp pragmas and a second thread are enough to reduce the runtime of > a large multiplication by 25%), assuming applications are unable to > get enough parallelism on their own. That's pretty much what we have in mind. However we are looking at writing GPU assembly routines directly too. > > I was surprised to see you decided to drop the nails support. A nails > support extended to have a non-unique representation of numbers allows > a locality of operations that can help both for parallelism and vector > architectures, which seem to be 2 of your goals. But I guess there are > other ways... For the time being, nails just became an extra headache for developers to maintain, with no real benefits (at present). Getting lots of developers is a greater priority at this point in the project. I suspect that (as you indicate), nails would have to be modified to make it useful. I personally haven't thought about its implications for parallel processing. If you have some ideas, it would be interesting to hear them. > >> * Writing a new mpir_n layer (similar to mpn, but more robust) > > What is "more robust"? At present the mpn layer has a kind of inconsistent interface. It is difficult for end users to make use of. Some functions require inputs to be restricted in certain ways, and aliasing is sometimes allowed, other times, not, etc. Bill. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
