Good questions where do we stop. I think as you that the fma with guarantees is a good new feature. But if this is made available, people will want to use it for speed. Some people won't like to use another library or dependency. They won't like to have random speed up or slow down. So why not add the ma and fma and trace the line to the operation implemented on the CPU that have an fused version? That will make a sensible limit I think.
Anyway, we won't use it directly. This is just my taught. Do you know if those instruction are automatically used by gcc if we use the good architecture parameter? Fred On Thu, Jan 9, 2014 at 12:07 PM, Nathaniel Smith <n...@pobox.com> wrote: > On Thu, Jan 9, 2014 at 3:30 PM, Julian Taylor > <jtaylor.deb...@googlemail.com> wrote: >> On Thu, Jan 9, 2014 at 3:50 PM, Frédéric Bastien <no...@nouiz.org> wrote: >>> How hard would it be to provide the choise to the user? We could >>> provide 2 functions like: fma_fast() fma_prec() (for precision)? Or >>> this could be a parameter or a user configuration option like for the >>> overflow/underflow error. >> >> I like Freddie Witherden proposal to name the function madd which does not >> guarantee one rounding operation. This leaves the namespace open for a >> special fma function with that guarantee. It can use the libc fma function >> which is very slow sometimes but platform independent. This is assuming >> apple did not again take shortcuts like they did with their libc hypot >> implementation, can someone disassemble apple libc to check what they are >> doing for C99 fma? >> And it leaves users the possibility to use the faster madd function if they >> do not need the precision guarantee. > > If madd doesn't provide any rounding guarantees, then its only reason > for existence is that it provides a fused a*b+c loop that better > utilizes memory bandwidth, right? I'm guessing that speed-wise it > doesn't really matter whether you use the fancy AVX instructions or > not, since even the naive implementation is memory bound -- the > advantage is just in the fusion? > > Lack of loop fusion is obviously a major limitation of numpy, but it's > a very general problem. I'm sceptical about whether we want to get > into the business of adding functions whose only purpose is to provide > pre-fused loops. After madd, what other operations should we provide > like this? msub (a*b-c)? add3 (a+b+c)? maddm (a*b+c*d)? mult3 (a*b*c)? > How do we decide? Surely it's better to direct people who are hitting > memory bottlenecks to much more powerful and general solutions to this > problem, like numexpr/cython/numba/theano? > > (OTOH the verison that gives rounding guarantees is obviously a unique > new feature.) > > -n > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
