[MPFR] GMP+MPFR to GPU?

David Defour david.defour at univ-perp.fr
Wed Dec 1 10:02:09 CET 2010


This is not related to GMP or MPFR but you will find an OpenCl implementation of multiprecision operations at http://www.bealto.com/mp-opencl.html. Discussions about expected performance and limitations are described at http://www.bealto.com/mp-opencl.html http://www.bealto.com/gpu-benchmarks.html.

Best regards,
David Defour.



Le 1 déc. 2010 à 09:46, Niels Möller a écrit :

> "Rick C. Hodgin" <foxmuldrster at yahoo.com> writes:
> 
>> Is there a developer's manual about the internal structure of the GMP
>> and/or MPFR code?  Or is there a #irc channel where I could ask
>> questions?
> 
> Start by reading the section about the mpn interface in the GMP manual.
> Questions can be asked on this list.
> 
> To see if GPU support is promising, you may want to start by
> implementing the mpn_addmul_1 function for the GPU, and see what
> performance you get. Or if you have some particular application in
> mind, profile it to see which of the low-level mpn_* functions is most
> important to you. I suspect mpn_addmul_1 (or mpn_addmul_2, if
> implemented) is the main workhorse for most GMP applications.
> 
> I don't know anything about how access to the GPU works; if it's
> available for ordinary users, if some operating system support is
> needed, etc. I imagine integration can be a bit tricky. A short summary
> about how it works would be nice.
> 
> The current thinking about parallell processing is that dividing up the
> work for parallell processing is usually best done at some level a bit
> above the low-level arithmetic. It should be better to do several large
> operations in parallell than, e.g., let the low-level Toom-2/Karatsuba
> algorithm spawn subproblems to multiple cpu:s.
> 
> For a SIMD architecture (GPUs are usually like this, right?)
> optimization considerations may be a bit different than for the usual
> GMP architectures. It might make some sense to try to implement
> mpn_addmul_k for some unusually large k, letting each cpu compute A *
> b_j where A is a bignum shared by all cpu:s, and b_j is a single word
> with different value for each cpu.
> 
> Regards,
> /Niels
> 
> -- 
> Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
> Internet email is subject to wholesale government surveillance.
> 
> -- 
> Ce message a été vérifié par MailScanner
> pour des virus ou des polluriels et rien de
> suspect n'a été trouvé.
> CRI UPVD http://www.univ-perp.fr
> 


David DEFOUR, (ELIAUS),			tel: + 33 (0) 4 30 19 23 06
Université de Perpignan,				fax: + 33 (0) 4 68 66 22 87
52, av. Paul Alduy
66860 Perpignan Cedex, France
http://perso.univ-perp.fr/david.defour/ David.Defour at univ-perp.fr 




More information about the gmp-devel mailing list