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 -- 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
