On Thu, Jun 02, 2011 at 03:53:18PM +0100, Garth N. Wells wrote: > > > On 02/06/11 15:52, Anders Logg wrote: > > On Thu, Jun 02, 2011 at 03:31:31PM +0100, Garth N. Wells wrote: > >> > >> > >> On 02/06/11 15:21, Benjamin Kehlet wrote: > >>> On 2 June 2011 14:59, Garth N. Wells <[email protected]> wrote: > >>>> > >>>> > >>>> On 02/06/11 12:10, Benjamin Kehlet wrote: > >>>>> On 2 June 2011 11:51, Anders Logg <[email protected]> wrote: > >>>>>> On Thu, Jun 02, 2011 at 10:46:29AM +0100, Garth N. Wells wrote: > >>>>>>> > >>>>>>> > >>>>>>> On 02/06/11 10:26, Anders Logg wrote: > >>>>>>>> On Thu, Jun 02, 2011 at 10:07:59AM +0100, Garth N. Wells wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 01/06/11 23:46, Anders Logg wrote: > >>>>>>>>>> Have you checked that there is no performance penalty? > >>>>>>>>> > >>>>>>>>> I just have - evaluating a Legendgre polynomial 10k times at the > >>>>>>>>> same > >>>>>>>>> point is just noise with both methods (of the order 10^-5 - 10^-4 > >>>>>>>>> s). > >>>>>>>> > >>>>>>>> It may be noise for some applications, but not for others. I'm not > >>>>>>>> sure this is a bottle-neck for the ODE code (Benjamin will know) but > >>>>>>>> we need to evaluate Legendre polynomials of degree > 100 many times > >>>>>>>> and then it may not be noise. > >>>>>>>> > >>>>>>> > >>>>>>> For very high degree (e.g. 200) Boost is marginally faster. > >>>>>> > >>>>>> Sounds promising then. > >>>>>> > >>>>>>>>> The Boost code is slightly slower because it doesn't cache the > >>>>>>>>> values > >>>>>>>>> (which is nice not to do), but may be faster if the call is inlined. > >>>>>>>>> It's not possible to inline it at the moment because of clashes > >>>>>>>>> between > >>>>>>>>> tr1:tuple and boost::tuple (Boost bug, I suspect). Old and new are > >>>>>>>>> the > >>>>>>>>> same when evaluating at different points. > >>>>>>>> > >>>>>>>> Let's wait for Benjamin to comment. > >>>>>>>> > >>>>>>> > >>>>>>> The speed is about the same (with scope to improve the speed for > >>>>>>> Boost) > >>>>>>> for unique values. The caller should be responsible for caching, if > >>>>>>> desired, since it can lead to memory blow out. > >>>>>>> > >>>>>>> Legendre does not appear in the ode code. It only appears in the > >>>>>>> computation of quadrature schemes. > >>>>>> > >>>>>> True, but the quadrature schemes are used in the ode code. > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Garth > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>> Garth > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> Benjamin has > >>>>>>>>>> worked quite hard on optimizing some of the basic math routines (in > >>>>>>>>>> some cases by many many orders of magnitude). > >>>>>>>>>> > >>>>>>>>>> Benjamin, can you take a look that it still works? > >>>>> > >>>>> Yes, the performance seems to be about the same, but I'm unable to > >>>>> compile it with support for GMP. > >>>>> > >>>>> /usr/include/boost/math/special_functions/legendre.hpp:178: > >>>>> instantiated from ‘typename boost::math::tools::promote_args<RT, > >>>>> float, float, float, float, float>::type boost::math::legendre_p(int, > >>>>> int, T, const Policy&) [with T = __gmp_expr<__mpf_struct [1], > >>>>> __mpf_struct [1]>, Policy = > >>>>> boost::math::policies::policy<boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy, > >>>>> boost::math::policies::default_policy>]’ > >>>>> /usr/include/boost/math/special_functions/legendre.hpp:185: > >>>>> instantiated from ‘typename boost::math::tools::promote_args<RT, > >>>>> float, float, float, float, float>::type boost::math::legendre_p(int, > >>>>> int, T) [with T = __gmp_expr<__mpf_struct [1], __mpf_struct [1]>]’ > >>>>> /home/benjamik/fenics/dolfin-wells_gmp/dolfin/math/Legendre.cpp:42: > >>>>> instantiated from here > >>>>> /usr/include/boost/math/special_functions/legendre.hpp:167: error: no > >>>>> matching function for call to ‘pow(__gmp_expr<__mpf_struct [1], > >>>>> __gmp_binary_expr<long int, __gmp_expr<__mpf_struct [1], > >>>>> __gmp_binary_expr<__gmp_expr<__mpf_struct [1], __mpf_struct [1]>, > >>>>> __gmp_expr<__mpf_struct [1], __mpf_struct [1]>, > >>>>> __gmp_binary_multiplies> >, __gmp_binary_minus> >, > >>>>> __gmp_expr<__mpf_struct [1], __gmp_binary_expr<__gmp_expr<__mpf_struct > >>>>> [1], __mpf_struct [1]>, long int, __gmp_binary_divides> >)’ > >>>>> /usr/include/bits/mathcalls.h:154: note: candidates are: double > >>>>> pow(double, double) > >>>>> /usr/include/c++/4.4/cmath:358: note: float > >>>>> std::pow(float, float) > >>>>> /usr/include/c++/4.4/cmath:362: note: long double > >>>>> std::pow(long double, long double) > >>>>> /usr/include/c++/4.4/cmath:369: note: double > >>>>> std::pow(double, int) > >>>>> /usr/include/c++/4.4/cmath:373: note: float > >>>>> std::pow(float, int) > >>>>> /usr/include/c++/4.4/cmath:377: note: long double > >>>>> std::pow(long double, int) > >>>>> [...] > >>>>> > >>>>> boost::math::legendre seems to rely on std::pow which is not > >>>>> templated, only implemented with the most common types. > >>>>> > >>>> > >>>> Looks like some tweaks are required to work with GMP: > >>>> > >>>> http://www.boost.org/doc/libs/1_43_0/libs/math/doc/sf_and_dist/html/math_toolkit/using_udt/use_mpfr.html > >>> > >>> That's not a bad solution, but it requires changing the > >>> multi-precision type from mpf (provided by GMP) to mpfr (which is a > >>> library that extends the floating point functionality in GMP). For > >>> floating-point arithmetic MPFR is much better than pure GMP. I think > >>> CGAL depends on MPFR, so it wouldn't even introduce new dependencies. > >>> The problem is that MPFR doesn't ship with a C++-wrapper (as opposed > >>> to GMP). Although several independent wrappers exists, none of them > >>> are avalilable in Debian/Ubuntu through apt. The one Boost requires is > >>> not updated since 2008 (MPFR has gone from version 2.3 to 3.0.1 since > >>> then). > >>> > >> > >> I've just plonked a copy of gmpfrxx in the DOLFIN dirs to test - it's > >> licensed under GPL. > > > > That won't work. We need LGPL. > > > > I meant LPGL.
Good. Does it have the "or any later version"? Otherwise it's still a problem. -- Anders > Garth > > >>> (Another option would be to take the same approach as Boost ourself: > >>> Implement the few functions that are required (pow() plus possibly a > >>> few more) and place it in the global namespace before including > >>> boost::mat::legendre), but GMP does not provide pow() when the > >>> exponent is a floating point number, so this is not straight forward > >>> without switching to MPFR). > >>> > >>> So I guess the question is whether we want to switch to MPFR now, to > >>> get rid of the few lines of code in Legendre.cpp (which performs > >>> reasonably well), when the code is likely to be thrown out pretty soon > >>> anyway. I vote for "no", but I have no problems with moving the entire > >>> ODE solvers to a separate project, then adding it back (without > >>> supporting extended precision) later in the form of code generation > >>> for time dependent problems. > >>> > >> > >> There are a few issues here - even if the ODE code is moved out, I think > >> that we should retain the polynomial and quadrature code in DOLFIN. > >> > >> Garth > >> > >>> Benjamin > >>> > >>>> > >>>> Garth > >>>> > >>>> > >>>>> Benjamin > >>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> Mailing list: https://launchpad.net/~dolfin > >>>>>>>>> Post to : [email protected] > >>>>>>>>> Unsubscribe : https://launchpad.net/~dolfin > >>>>>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Mailing list: https://launchpad.net/~dolfin > >>>>>> Post to : [email protected] > >>>>>> Unsubscribe : https://launchpad.net/~dolfin > >>>>>> More help : https://help.launchpad.net/ListHelp > >>>>>> > >>>> > >>>> > >> > _______________________________________________ Mailing list: https://launchpad.net/~dolfin Post to : [email protected] Unsubscribe : https://launchpad.net/~dolfin More help : https://help.launchpad.net/ListHelp
