[Beowulf] Optimized math routines/transcendentals
Peter St. John
peter.st.john at gmail.com
Sat Apr 30 13:53:23 PDT 2016
Just one physical oceanographer might need very different precision for a
3-day forecast of currents than for a one-day forecast. I suspect that
precision needs will vary even within a lab, much less within a field much
less between fields. In the cryptography example, precision is proportional
to security needs, and that always depends on specific applications. I
don't want to waste bandwidth using HTTPS to connect to Facebook, myself,
but I might have to use 4096-bit PGP to administer my secret Cayman Islands
money-laundering account that the IRS doesn't know about. Oops.
Peter
On Sat, Apr 30, 2016 at 3:37 PM, C Bergström <cbergstrom at pathscale.com>
wrote:
> I assume, possibly incorrectly, that scientists know what level of
> tolerance/accuracy they need. While we can all dream about the futures
> or past - the present day needs are useful to know. In general a
> certain field may need A and another field will tolerate B...
>
> I guess this is a NaN... if(signal/noise>0)
>
>
> On Sun, May 1, 2016 at 3:29 AM, Peter St. John <peter.st.john at gmail.com>
> wrote:
> > I'm betting the answer to that will be "any" (i.e. "it depends").
> >
> > In cryptography, we used to think of 128 bits for a PGP key as a lot, but
> > some folks have started using 4096 bits. Of course in exact arithmetic
> it's
> > much easier to deal with arbitrary precision than in quantitative
> analysis
> > of measurements with error intervals.
> >
> > Peter
> >
> > On Sat, Apr 30, 2016 at 3:09 PM, C Bergström <cbergstrom at pathscale.com>
> > wrote:
> >>
> >> I was hoping for feedback, from scientists, about what level of
> >> accuracy their codes or fields of study typically require. Maybe the
> >> weekend wasn't the best time to post.. hmm..
> >>
> >> On Sun, May 1, 2016 at 1:31 AM, Peter St. John <peter.st.john at gmail.com
> >
> >> wrote:
> >> > A bit off the wall, and not much help for what you are doing now, but
> >> > sooner
> >> > or later we won't be hand-crating ruthlessly optimal code; we'll be
> >> > training
> >> > neural nets. You could do this now if you wanted: the objective
> function
> >> > is
> >> > just accurate answers (which you get from sub-optimal but
> mathematically
> >> > correct existing code) and the wall clock (faster is better), and you
> >> > train
> >> > with the target hardware. So in principle it's easy, and if you look
> at
> >> > how
> >> > fast Deep Mind trained AlphaGo it begins to sound feasible to train
> for
> >> > fast
> >> > fourier transforms or whatever.
> >> > Peter
> >> >
> >> > On Fri, Apr 29, 2016 at 9:06 PM, William Johnson
> >> > <meatheadmerlin at gmail.com>
> >> > wrote:
> >> >>
> >> >> Due to the finite nature of number representation on computers,
> >> >> any answer will be an approximation to some degree.
> >> >> To me, it looks to be a non-issue to some 15 significant digits.
> >> >> I would say it depends how accurate you need.
> >> >> You could do long-hand general calculations that track percent error,
> >> >> and see how it gets compounded in a particular series of
> calculations.
> >> >>
> >> >> If you got right into the nuts and bolts of writing optimized
> >> >> functions,
> >> >> there are many clever ways to calculate common functions
> >> >> that you can find in certain math or algorithms & data structures
> >> >> texts.
> >> >> You would also need intimate knowledge of the target chipset.
> >> >> But it seems that would be way too much time in
> >> >> research and development to reinvent the wheel.
> >> >>
> >> >>
> >> >> On Fri, Apr 29, 2016 at 7:28 PM, Greg Lindahl <lindahl at pbm.com>
> wrote:
> >> >>>
> >> >>> On Sat, Apr 30, 2016 at 02:23:31AM +0800, C Bergström wrote:
> >> >>>
> >> >>> > Surprisingly, glibc does a pretty respectable job in terms of
> >> >>> > accuracy, but alas it's certainly not the fastest.
> >> >>>
> >> >>> If you go look in the source comments I believe it says which
> paper's
> >> >>> algorithm it is using... doing range reduction for sin(6e5) is
> >> >>> expensive to do accurately. Which is why the x86 sin() hardware
> >> >>> instruction does it inaccurately but quickly, and most people/codes
> >> >>> don't care.
> >> >>>
> >> >>> -- greg
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin
> >> >>> Computing
> >> >>> To change your subscription (digest mode or unsubscribe) visit
> >> >>> http://www.beowulf.org/mailman/listinfo/beowulf
> >> >>
> >> >>
> >> >>
> >> >> _______________________________________________
> >> >> Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin
> >> >> Computing
> >> >> To change your subscription (digest mode or unsubscribe) visit
> >> >> http://www.beowulf.org/mailman/listinfo/beowulf
> >> >>
> >> >
> >> >
> >> > _______________________________________________
> >> > Beowulf mailing list, Beowulf at beowulf.org sponsored by Penguin
> Computing
> >> > To change your subscription (digest mode or unsubscribe) visit
> >> > http://www.beowulf.org/mailman/listinfo/beowulf
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.beowulf.org/pipermail/beowulf/attachments/20160430/6ba5b36c/attachment-0001.html>
More information about the Beowulf
mailing list