Oh my, I never noticed this! I'd been looking for mpfr_addmul in line with GMP!! I see it is slightly different in that it doesn't do a = a + b*c.
I can actually speed some code up with this!! Bill. On 21 May, 10:39, Fredrik Johansson <fredrik.johans...@gmail.com> wrote: > On Fri, May 21, 2010 at 11:17 AM, Sergey Bochkanov < > > > > > > sergey.bochka...@alglib.net> wrote: > > correction to my previous message: > > > > It leads to unnecessary allocation of temporaries and some > > > performance penalty (about 25-30% for 128-bit precision). > > > Sorry, I made a mistake when estimating MPLAKACK performance. "25-30%" > > are ALGLIB's, not MPLAPACK's. > > > I've never measured MPLAPACK performance directly, but looking at its > > RGEMM code and measuring allocation penalty for code like this: > > > > mpfr_t tmp1, tmp2; > > > mpfr_init2(tmp1, Precision); > > > mpfr_init2(tmp2, Precision); > > > mpfr_mul(tmp1, mp_b, mp_c, GMP_RNDN); > > > mpfr_add(tmp2, mp_a, mp_tmp, GMP_RNDN); > > > mpfr_set(mp_d, tmp1, GMP_RNDN); > > > mpfr_clear(tmp1); > > > mpfr_clear(tmp2); > > > (which reproduces allocations done by MPLAPACK during "a=a+b*c" update > > in the RGEMM call) and comparing it with > > > > mpfr_mul(mp_tmp, mp_b, mp_c, GMP_RNDN); > > > mpfr_add(mp_d, mp_a, mp_tmp, GMP_RNDN); > > > which does the same thing, but more efficiently, I can conclude that > > MPLAPACK allocation penalty will be 100% for 128-bit precision code > > (i.e. it will run twice longer), 50% for 256-bit precision. > > > As for ALGLIB, it really has 25-30% allocation penalty for 128-bit > > code. The reason behind such difference from MPLAPACK is that ALGLIB > > tries to allocate new multiple precision variables from internal > > cache, but still relies on OOP, which slows it down. > > > So when I said that "ALGLIB ... suffers from the same OOP drawbacks", > > I was a bit incorrect - it suffers from OOP drawbacks, but from > > _other_ drawbacks. > > > -- > > With best regards, > > Sergey mailto:sergey.bochka...@alglib.net > > MPFR has a fused multiply-add function, so d = a+b*c can be written > mpfr_fma(d,a,b,c, MPFR_RNDN). This is almost certainly what you'd want to > base MPFR linear algebra around. > > Fredrik > > -- > To post to this group, send an email to sage-devel@googlegroups.com > To unsubscribe from this group, send an email to > sage-devel+unsubscr...@googlegroups.com > For more options, visit this group athttp://groups.google.com/group/sage-devel > URL:http://www.sagemath.org -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
