Hello, On Apr 27, 9:47 am, Bill Hart <[email protected]> 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) > * 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)? 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? 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. 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... > * Writing a new mpir_n layer (similar to mpn, but more robust) What is "more robust"? -- Marc Glisse --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
