Hi All, I have some queries related with boost.math library as ststed below: a) Is it possible to write many of the functions in the boost.math library (like beta and gamma functions) so that they can be parallelized irrespective of the "way of parallelization"(such as using OpenMP, MPI, etc...) and the "environment" (like multicore or a cluster)? b) What is the possibility of extending boost.math libraries (particularly beta and gamma functions) to generic libraries using generic programming process? -- Regards, Anup Mandvariya +919985330660 "Truth Must Have No Compromise"
Anup Mandvariya wrote:
Hi All, I have some queries related with boost.math library as ststed below:
a) Is it possible to write many of the functions in the boost.math library (like beta and gamma functions) so that they can be parallelized irrespective of the "way of parallelization"(such as using OpenMP, MPI, etc...) and the "environment" (like multicore or a cluster)?
I don't know, you would need to devise an parrallelisation API that's independent of the underlying mechanism, given that OpenMP uses #pragmas and MPI code I'm not sure that's really feasable. The alternative would be lot's of #if..#else logic I guess :-(
b) What is the possibility of extending boost.math libraries (particularly beta and gamma functions) to generic libraries using generic programming process?
I'm not sure I understand what you mean - they are intended to be generic already - and work with any type that satisfies the requirements here http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/math_too... So for example I already use them with NTL::RR and also have experimental versions which work with Boost.Interval and/or mpfr_class. Is this what you meant? HTH, John.
On 4/14/08, John Maddock <john@johnmaddock.co.uk> wrote:
Anup Mandvariya wrote:
Hi All, I have some queries related with boost.math library as ststed below:
a) Is it possible to write many of the functions in the boost.math library (like beta and gamma functions) so that they can be parallelized irrespective of the "way of parallelization"(such as using OpenMP, MPI, etc...) and the "environment" (like multicore or a cluster)?
I don't know, you would need to devise an parrallelisation API that's independent of the underlying mechanism, given that OpenMP uses #pragmas and MPI code I'm not sure that's really feasable. The alternative would be lot's of #if..#else logic I guess :-(
b) What is the possibility of extending boost.math libraries (particularly beta and gamma functions) to generic libraries using generic programming process?
I'm not sure I understand what you mean - they are intended to be generic already - and work with any type that satisfies the requirements here
http://svn.boost.org/svn/boost/trunk/libs/math/doc/sf_and_dist/html/math_too...
So for example I already use them with NTL::RR and also have experimental versions which work with Boost.Interval and/or mpfr_class.
Is this what you meant?
HTH, John.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Thanks John, My second query was, If is it possible to generalize these libraries so that they can be parallelize both for shared-memory as well as distributed-distributed memory? -- Regards, Anup Mandvariya +919985330660 "Truth Must Have No Compromise"
Anup Mandvariya wrote:
Thanks John, My second query was, If is it possible to generalize these libraries so that they can be parallelize both for shared-memory as well as distributed-distributed memory?
OK, understood: many of the opportunities for parrellelising that I know about are task-oriented, and so would work rather well on a distributed memory system from a theoretical point of view. However, my gut feeling (with no data to back it up!) is that the overhead from say an MPI implementation would be prohibitively high for this to be at all useful. There are also some opportunities for vectorisation: for example by evaluating polynomials via a second-order Horner scheme and using SSE (or similar) instructions. And finally... there's whatever else the SOC student may spot while examamining the source code! :-) HTH, John.
Anup Mandvariya wrote:
Hi All, I have some queries related with boost.math library as ststed below:
a) Is it possible to write many of the functions in the boost.math library (like beta and gamma functions) so that they can be parallelized irrespective of the "way of parallelization"(such as using OpenMP, MPI, etc...) and the "environment" (like multicore or a cluster)?
What do you mean by parallelizing the beta function? The task of evaluating the beta function for a single value is not parallelizable. The task of evaluating the beta function for each value in a container is of course parallelizable. But doing that requires parallelized STL algorithms, and has nothing to do with the Boost.Math library. --Johan Råde
The task of evaluating the beta function for each value in a container is of course parallelizable. But doing that requires parallelized STL algorithms, and has nothing to do with the Boost.Math library.
Doing vectorized math fast often requires that the per-value calculation be explicitly coded to help the compiler with software pipelining or even manually pipelined. That issue is indeed orthogonal to multithreading which requires only reentrancy on the part of the function implementations. On processors with deep pipelines, multiple execution units and plentiful registers the difference between monolithic loop body and one that can be software pipelined can easily be 2:1. I'm not contradicting the point quoted, just saying that if you want the container-oriented interfaces to the math functions to be fast it will require cooperation from the function implementations on most compilers. Parallelizing the calls to black-box functions will exploit multiple cores at low cost but you'll be leaving a lot of performance on the table.
Johan Råde wrote:
a) Is it possible to write many of the functions in the boost.math library (like beta and gamma functions) so that they can be parallelized irrespective of the "way of parallelization"(such as using OpenMP, MPI, etc...) and the "environment" (like multicore or a cluster)?
What do you mean by parallelizing the beta function?
The task of evaluating the beta function for a single value is not parallelizable.
The task of evaluating the beta function for each value in a container is of course parallelizable. But doing that requires parallelized STL algorithms, and has nothing to do with the Boost.Math library.
I was more interested in the incomplete beta, which can be split into separate components which can be independently evaluated and then combined to give the result - actually one could do the same for the beta function itself, but I doubt very much that it would worth the effort, or the overhead imposed by the parrallelisation. John.
participants (4)
-
Anup Mandvariya -
Johan Råde -
John Maddock -
Stephen Nuchia